Aggregated enterprise architecture wisdom
QualiWare Center of Excellence has Booth 1 at the annual Danish Government Digitalization Conference (#offdig) in Aarhus on 24-25 March. Rune Brodersen and John Gøtze will be available at the booth both days, so feel free to drop by for a chat. Or for a demo of some of our new offerings: Archimate OIOEA Capability models Business Model […]
There is academic debate regarding whether big data helps or hurts strategy. In our research at MIT CISR, we’ve identified some important advantages to viewing big data as a strategic opportunity. In particular, companies can use big data to greatly improve and innovate their business model—and to extend their strategy toolboxes. Improving the Business Model […]
When it comes to optimizing digital business models, there are three sources of competitive advantage: content, customer experience, and platform. However, very few businesses excel in all three areas. Just think about Trip Advisor. Is it known for amazing customer experience or a stellar platform? Neither—it’s largely known for its content. What about USAA? It’s […]
As more business becomes digital, customers are expecting the ability to interact with companies anywhere and anytime. A recent survey showed that 72% of customers would replace some traditional channels with mobile apps if given the opportunity. This means that companies need to get serious about their digital business models if they are going to […]
I was taken by surprise the other day when I looked at my calendar and saw that we are well into August; and before you know it summer will be over and autumn will be upon us. Immediately I started thinking about the ritual year-end strategic planning session that generally looms around now. I’m sure many of you know of what I speak.
Historically strategic planning has centered around regular sessions that evaluate business performance and goals over established periods of time. Some organizations even remain attached to the yearly planning cycle. But, with the introduction of digital business and disruptive business models, has this approach become broken, merely sending businesses into a pro-longed process of planning and budget allocating that is outdated before its executed?
I think it probably has, which means we have to start thinking about how to change our planning processes. Earlier this year we started dialogue on the very idea of how change is changing and how it affects the planning process. Our post, Beyond Technology: How Enterprise Intelligence Supports Business Strategy and Change, looked at how enterprise intelligence (EI) makes it possible for the C-suite to make necessary strategic business decisions at the drop of a hat:
The insights produced by EI tools allow Chief Strategy Officers to quickly and methodically maneuver the business as the market changes by delivering enterprise transparency that shows the cost, impact and benefits of change across the connected enterprise.
But, how does it work?
Good question. Let’s start by looking at real-time strategy. In this context ‘real-time’ means you get an immediate view of any given part of a business. The idea behind enterprise intelligence is to provide executives with a real-time, continuous strategic planning view that enables an assessment of the entire connected enterprise. Forbes talked about this recently in the article, Is Enterprise Architecture Completely Broken?:
Those EAs who truly embrace change – who work directly with business stakeholders to move their organizations to an increasingly agile state of continuous business transformation – will more likely find themselves adding real value to their enterprises.
Using enterprise intelligence to immediately understand how a specific strategy will impact all the various parts of the business means informed decisions can be made efficiently in order to mitigate risk or capitalize on an opportunity.
Is that really possible?
At Troux, we help our clients do this everyday. As a result, the planning cycle is real-time and actionable.
The Troux mind map has become a popular tool that helps companies understand the types of outcomes they can achieve with real-time strategic planning. These outcomes generally come from finding answers to key questions, such as:
The mind map visually illustrates the answers to the questions that drive the desired business outcomes. These answers communicate strategy and impacts to the enterprise regardless of technical prowess or business acumen, putting stakeholders on the same page on how everything works together.
The more things change…
I do enjoy that annual opportunity to check-in with my peers and superiors for a state-of-the-union assessment, but I’m not sure it needs to be categorized as “the one” strategic planning session anymore. The world of EI allows us to understand our market position every day and make decisions and changes accordingly. Since we have the data and information at our fingers tips real-time strategy is a reality. We can transform our annual planning sessions a daily dialogue that ensures we taking advantage of changes in the market. How long have businesses lamented that there is never enough time for strategic planning? Well, I think EI has helped us find it.
Organizations do not work, in real life, like they work on paper. On paper, there are departments (all shaped like a neat rectangle) and business processes with neat inflows and outflows of responsibility and information. On paper, you improve things by modeling things on paper, and then moving things around, on paper, then teaching people to follow the process that your neat paper diagrams represent.
In real life, there are human beings and the tools that they use. Sometimes the tools move information from one person to another. Sometimes, they just aid in communication. People meet and get to know other people, and they learn to trust some, and distrust others. Some folks have different measures and motivations and just “pass by” one another. Some subset of these people will have shared cultural values and expectations. There may be many cultures in an organization: both because the organization is in multiple places, and because people from multiple places join an organization. Also, “business culture” arises as leaders achieve successes and people learn to use certain “cultural expectations” to get things done efficiently.
Reality is a lot messier than pretty rectangles.
Enterprise Architects apply science and engineering and aesthetics to the challenge of organizational change. We are unique in that most other “change artists” are not focused on engineering and some even ignore science. (see Daniel Pink’s TED Talk on the Surprising Science of Motivation). Few even know how to spell aesthetics. Yet, when you are dealing with systems that contain and include people, you have to use aesthetics, and you are ill prepared for success if you ignore science. Engineering is a mindset as much as a class of methods. It involves applying the things that science has discovered and using that understanding to build great (and sometimes terrible) things. Engineers build on ideas and use them, often experimenting on systems that are too complex and intertwined for “pure science” to get arms around.
As Enterprise Architecture is such a young science, we have relied to heavily on the “boxes and lines” model of enterprises, and not enough on the messy but important sociocultural view of an enterprise. We find it easier to document, and model, and even simulate, processes as though people were interchangeable and their relationships didn’t matter.
That is just lazy.
It is time to get up off our collective butts and start working out ways to understand sociocultural influences, relationships, and architectures. We have to build ways to detect, measure, and consider these structures when we measure capabilities, or improve processes, or suggest automations, or evaluate business models, or any of the two dozen things that EA’s do.
The value of EA often comes to an executive in the form of a reasoned opinion that is based on data that no one else is looking at. Let’s consider the possibility that examining sociocultural influences can provide interesting opinions that an executive will find valuable.
We should consider sociocultural information if:
Think about it. Do you believe that any of those statements are false? I can find ample examples for each one. So if sociocultural interactions matter, why are we not tracking them, learning from them, using them to make decisions?
It’s only hard because we haven’t tried.
(This post inspired by the many similar pleas shared by J.D. Beckingham in social media).
Once upon a time, a long, long time ago, well some 20 years actually, some clever folk figured out a way of structuring work that was quite revolutionary. So revolutionary in fact that most people didn’t understand it. Now a few folk in a parallel world worked hard over the years to make this method work, and they invented more ideas, frameworks and tools. And every day they are constantly improving their productivity and quality; and many of them also use Agile methods, as they are entirely complementary to the revolutionary method. The method – Design by Contract.
However the mainstream of the market seems to be fixated on Agile methods, as being the metaphorical silver bullet. Yet we all can’t help noticing that Agile Land is not such a happy place. There is continuing debate about the difficulties of making the methods work in the enterprise; the fragmentation of the original Agile principles and the outbreak of religious wars. And I am minded to comment, again, that the root problem with Agile methods is that they are one-dimensional – solely focused on people and process to the exclusion of all the other opportunities to create agile businesses.
At the heart of the conundrum is the need to focus on some different questions. Such as:
– How can we reduce the amount of work that has to be done?
– How can we structure the outcomes (deliverables) so they are inherently agile?
– How can we structure the work so that there is real traceability between the intrinsic business model and the delivered systems and services?
– How can we ensure that overall technical debt is always reducing faster than new functionality is being delivered?
– . . .
You get the idea.
So back to my parallel world. In Design by Contract the business problem, typically the Use Case, Services and Operations are attributed with Pre-conditions, Post-conditions and Invariants (rules that must remain constant). These artifacts provide us with functional and design level specifications that can be produced in an Agile, iterative manner, that
a) Deliver implementation independent service specifications (descriptions if you prefer)
b) And therefore also for publishing API specifications
c) Form the basis for structuring the code that is fully traceable to the business model
d) Create inherently agile systems and service structures
e) Create the structure (stubs) for Unit, Integration, Functional and Regression testing
(e.g all conditions and rules within a given test scope must be tested)
f) Depending on the technology employed to define the conditions and invariants, (rules engines, pseudo languages etc) both code and test cases can be produced automatically.
I was prompted to write this blog because I happened to read Rob Marvin’s useful blog on testing, and his very interesting ideas for improving test productivity to keep up with Agile projects. In his piece he talks about automation, but actually seems to miss the opportunity to auto-generate the test cases. Even more important, he seems to believe that the current state of Agile projects is his benchmark that he has to keep up with. I would comment that state of the art Design by Contract projects together with model driven frameworks are delivering order of magnitude greater productivity with exceptional quality, and this ought to be the where testers should set the bar.
Sometimes it seems to me that the Agile methods community is rather in the situation of hoping a Fairy Godmother will appear, wave a magic wand and all will be well. Everyone will use Scrum like they ought to; enterprises will waive their awkward little requirements for inter-project coordination and all will be well. But while the Agile community continue to ignore the broader scope of agile enablers this day won’t come.
If you are interested in an example of Design by Contract at work take a look at the Agile Service Factory.
Once upon a time, a long, long time ago, well some 20 years actually, some clever folk figured out a way of structuring work that was quite revolutionary. So revolutionary in fact that most people didn’t understand it. Now a few folk in a parallel world worked hard over the years to make this method work, and they invented more ideas, frameworks and tools. And every day they are constantly improving their productivity and quality; and many of them also use Agile methods, as they are entirely complementary to the revolutionary method. The method – Design by Contract.
However the mainstream of the market seems to be fixated on Agile methods, as being the metaphorical silver bullet. Yet we all can’t help noticing that Agile Land is not such a happy place. There is continuing debate about the difficulties of making the methods work in the enterprise; the fragmentation of the original Agile principles and the outbreak of religious wars. And I am minded to comment, again, that the root problem with Agile methods is that they are one-dimensional – solely focused on people and process to the exclusion of all the other opportunities to create agile businesses.
At the heart of the conundrum is the need to focus on some different questions. Such as:
– How can we reduce the amount of work that has to be done?
– How can we structure the outcomes (deliverables) so they are inherently agile?
– How can we structure the work so that there is real traceability between the intrinsic business model and the delivered systems and services?
– How can we ensure that overall technical debt is always reducing faster than new functionality is being delivered?
– . . .
You get the idea.
So back to my parallel world. In Design by Contract the business problem, typically the Use Case, Services and Operations are attributed with Pre-conditions, Post-conditions and Invariants (rules that must remain constant). These artifacts provide us with functional and design level specifications that can be produced in an Agile, iterative manner, that
a) Deliver implementation independent service specifications (descriptions if you prefer)
b) And therefore also for publishing API specifications
c) Form the basis for structuring the code that is fully traceable to the business model
d) Create inherently agile systems and service structures
e) Create the structure (stubs) for Unit, Integration, Functional and Regression testing
(e.g all conditions and rules within a given test scope must be tested)
f) Depending on the technology employed to define the conditions and invariants, (rules engines, pseudo languages etc) both code and test cases can be produced automatically.
I was prompted to write this blog because I happened to read Rob Marvin’s useful blog on testing, and his very interesting ideas for improving test productivity to keep up with Agile projects. In his piece he talks about automation, but actually seems to miss the opportunity to auto-generate the test cases. Even more important, he seems to believe that the current state of Agile projects is his benchmark that he has to keep up with. I would comment that state of the art Design by Contract projects together with model driven frameworks are delivering order of magnitude greater productivity with exceptional quality, and this ought to be the where testers should set the bar.
Sometimes it seems to me that the Agile methods community is rather in the situation of hoping a Fairy Godmother will appear, wave a magic wand and all will be well. Everyone will use Scrum like they ought to; enterprises will waive their awkward little requirements for inter-project coordination and all will be well. But while the Agile community continue to ignore the broader scope of agile enablers this day won’t come.
If you are interested in an example of Design by Contract at work take a look at the Agile Service Factory.
.jpg)
In our last blog post, The Next Chapter of Enterprise Architecture: Self-Service, we examined the change in mind-set that seems to be occurring in all corners of the enterprise when it comes to EA. We wrote about EA tools as a catalyst to empower stakeholders all across the enterprise with quality decision-making information available whenever needed:
“With digital and technological disruptors firmly rooted in our world there is a massive mind shift at play in how we interact with technology as well as how we expect to get things done.”
In this post we will further explore why the timing now seems right for EA to go through this renaissance.
To start, EA has evolved. It is no longer an IT-centric discipline focused on creating a set of artifacts in the form of complex maps and models only understood by a few with limited ‘actionability’ in terms of driving measurable business outcomes. To serve the evolving needs of decision-makers EA has evolved as well. With the rise of digital business and the rapid pace of change in the market it is more important than ever for decision-makers to not only know exactly where to invest in their business, but to also better understand the impacts of those investment decisions.
“While many biz & IT execs are aware of disruptive innovations in IT (such as the nexus of forces and digital business), they often struggle to identify the impact and implications of these innovations to their business model.” – Gartner
With the most comprehensive understanding of how every piece of an organization is connected, enterprise architects are poised to take the lead in how the enterprise responds to disruptive forces and change, whatever their origin.
When we talk about disruptive forces we mean consumer expectations, digital business, new technologies, regulatory demands, social media and more. EA in a leadership role helps organizations navigates these disruptors while staying focused on its strategic goals and vision.
In this new era enterprise architects still have to maintain their knowledge of IT, but they have to move beyond those contributions and activities, introducing themselves as strategic advisors who communicate EA’s value to all parts of the business. Today, enterprise architects are also looked to for strategic budget decisions. They must be able to vet how a new investment will support corporate outcomes and transform the business. Further, they must assimilate the integration costs and process to assure the company realizes the value.
This renaissance of EA has only just begun, but some big wins are already in the marketplace. Read how Troux customer HSBC is undertaking a massive program to simplify operations through EA. Find the complete article on Computer Weekly, HSBC makes executives responsible for application consolidation.
We all know that Google lost a landmark legal case recently. As of now, a citizen of Europe has the “right to be forgotten” on the Internet. As of now, a citizen of Europe can ask Google to “forget” them, so that a search of their identity will not return embarrassing information from the past. This allows a person to live past a mistake. Your college indiscretion, and that time you were fired for photocopying your butt, or the time you got drunk and drove your car into a swamp and had to be rescued… all of that can “go away.”
However, this becomes much more difficult when we consider the emerging Internet of Things (IoT). In the Internet of Things, the “stuff” that you own can generate streams of data that do not remain within your control. That data is called “Information Property.” It is the information that YOU generate, in the things that you do. I believe that if YOU create a bit of information property, you should own it.
That information property, thousands of tiny bits of data about you or your activities, will wander out of your house, or your car, or your phone, to companies and governments running cloud-based data centers. That swarm of data surrounds you, and be used to profile you, track you, predict your actions, influence your choices, and limit your abilities to get “outside” the system. Most folks will not have any problem with this cloud of data. At least not at first.
Where we will first feel the pain of this cloud of data: when you want to be forgotten.
We have been dealing with “data about you” for a while. When you apply for a loan or a credit card, the information you submit becomes the property of your creditor, and they share that data with credit reporting agencies, along with your payment history, employment history, residential history, status of property ownership, and basically any other factor that finance companies feel would influence your likelihood to pay your debts. The US Federal Government has placed some controls on this data, but not many. Europe has placed entirely different controls. You have no right to be forgotten, but you do have the right to limit their memory to a decade. That allows you to “get past” a mistake or series of mistakes. But you are always “known.” However, a mistake can be forgotten.
This is a model we can use. Here is data, about you, outside your control, that get’s “forgotten” on a regular basis as it gets old. There is a possibility in the credit reporting world for being “forgotten” because the data is tied to you, personally. It is ALL personal data.
This is not (yet) true in the Internet of Things. If your car sends data to a smart roadway system, there is a great deal of information about where you go, and when, but under most circumstances, your identity is not tied to that data. It’s the identity of the CAR that is sent, but not the identity of the driver or passenger. That can be seen as an advantage, because it is tough to link that data to you, but it is possible, and therefore it will occur. You will be found. And when it does occur, you no longer have any easy mechanism to PROVE that the data from your car relates to you. This means that if any government creates a policy to allow you to be forgotten, the car data will not go away. You can’t CLAIM that data because it is not directly linked to you. You don’t own it.
Think this is a minor problem? After all, your city doesn’t have a smart roadway yet, and your car doesn’t send data, so this problem is a long way off, right? Wrong. If we don’t think of this now, privacy will be sacrificed, possibly for decades.
The environment of regulations sets the platform by which companies create their business models. If we create a world where you cannot claim your data, and you cannot manage your data, other people will start claiming your data, and making money. Once that happens, new regulations amount to government “taking money” from a company. The typical government response is to “grandfather” existing practices (or to protect them outright). No chance to change beyond a snail’s pace at that time.
I propose a simple mechanism. Every time you purchase a device on the IoT, you insert an ID into the device. This ID is a globally unique ID (my tech friends call this a GUID) which is essentially a very large random number. You can pick up as many as you want over your lifetime, but I’d suggest getting a new one every month. A simple app can create the GUID and manage them. Every item you purchase during that month gets the ID for that month.
Every bit of data (or Information property) sent by the device to the swarm of companies that will collect and work with this data will get your GUID.
Note that your GUID allows those companies to link your data across devices (your phone, your car, your refrigerator, your ATM card, your medical record, etc). Is this allowed? Perhaps one government or another will say “no” but that control will be easily worked around, so let’s assume that you cannot control this. The thing I want to point out is that this kind of linkage is POSSIBLE now, it’s just more difficult. But difficulty is being overcome at a huge rate with the number of computing devices growing geometrically. Let’s assume that folks can do this NOW and that you will NEVER be able to control it.
Therefore inserting an ID is not giving up control. You don’t have it now.
But it is possible, with the ID, to TAKE control. You will be able to submit a request to a regulated data management company (a category that doesn’t yet exist, but it is possible), then those systems can identify all the data records with your ID, and delete them. Only if you can claim your data can you delete it. By inserting a GUID into your Internet-of-things, you have gained a right… the right to claim your data, and therefore delete it.
It will no longer be a choice of sending a single message to a single search firm like Google. The request to delete will have to go to a broker that will distribute the request, over time, to a swarm of data management companies, to remove data tagged with these IDs.
Now, before anyone complains that a company, once they have data, will never let it go, I would submit that is nonsense. 90% of the value of information comes from samples of that data of less than 2% of the population. In fact, the vast majority of data will be useless, and plenty of companies will be looking for excuses to toss data into the virtual trash bin. If a customer asks to delete data, it costs a micro-cent to do it, but that data is probably clogging things up anyway.
Getting a company to spend the money will probably require regulations from large players like the EU, the USA, China, Japan, Brazil, and India.
Now is the time to ask for these regulations, as the Internet of Things is just getting started. Companies that understand the ability to create and manage these IDs, and respond to the request to delete information, will have a leg up on their competition. Customers will trust these companies more, and the data will be more accurate for consumers of these data services.
You cannot delete “information property” until you can claim it. The ID is the claim.
In my last post Oh No! We need another Practice Framework, I developed the earlier theme commenced in “Beware the New Silos”. I argued that the widely used frameworks are narrowly discipline centric and actually inhibit cross discipline working. I described how my own firm’s experiences have led to the development of a de facto framework, (we call it SOAM) and illustrated how this is essentially a value chain commencing with customer demand and finishing with value add to some enterprise.
I ended by sketching some basic principles concluding that we need a new framework that is goal driven and incorporates the entire value chain of capabilities, which of course may selectively reuse some parts of existing frameworks. In this post, I suggest a strawman that covers a) principles and b) capability model.
Before diving into principles, it will be useful to declare some scope. Our framework has developed from working with larger enterprises, both commercial and government in the area of business service and solution delivery. All of these enterprises share common issues that they have extensive legacy application assets that act as a serious inhibitor to business change, and successive, narrowly scoped solution projects over many years have often resulted in great complexity and technical debt. It is also common in my experience that enterprise architecture functions are routinely bypassed or ignored; that Agile methods have been attempted and found useful on narrow focused projects, but because of the constrained focus, tend to increase overall complexity of the ongoing application asset base; that consistent customer experiences are commonly compromised by narrow focused projects; and line of business managers in large enterprises are frequently dissatisfied with IT application service support.
– describe practices relevant to service and solution delivery in the digital business environment
– achieve a balance between short term goals and longer term objectives
– support progressive transformation to an enterprise comprised of independent business capabilities
– facilitate continuous, short cycle time evolution of business capability
– progressively and continuously resolve legacy portfolio complexities
– enable rapid delivery at low cost without compromise in quality
Principles should be enduring and lead to both excellent policy communication and policy interpretation in everyday situations. I also find it useful to classify principles by subject.
In business architecture the capability model has become ubiquitous. And in thinking organizations I observe delivery of highly independent service and solution components that reduce dependencies and the impact of change, as well as mirroring the IT architecture on the business organization. Why wouldn’t we use the same approach in defining a set of activities to deliver services and solutions?
If you are uncertain about the capability concept, it’s important to appreciate that the optimum business capability is one that enables:
– maximum cohesion of internal functional capability, plus consistency of life cycle, strategic class (core, context, innovating . . . ), business partition (global, local, LoB . . ), standardization, customizability, stability, metrics and drivers
– defined, stable dependencies that are implemented as services
[Further reading on capability optimization ]
In the capability dependency model below, the arrows are dependencies. For example, Demand Shaping is dependent upon Conceptual Business Modeling and Portfolio Management. So this is not a flow diagram, rather all the capabilities should be regarded as iterative, I will come back and discuss how Lean principles operate in a framework like this, and as discussed above, highly independent.
In my last post Oh No! We need another Practice Framework, I developed the earlier theme commenced in “Beware the New Silos”. I argued that the widely used frameworks are narrowly discipline centric and actually inhibit cross discipline working. I described how my own firm’s experiences have led to the development of a de facto framework, (we call it SOAM) and illustrated how this is essentially a value chain commencing with customer demand and finishing with value add to some enterprise.
I ended by sketching some basic principles concluding that we need a new framework that is goal driven and incorporates the entire value chain of capabilities, which of course may selectively reuse some parts of existing frameworks. In this post, I suggest a strawman that covers a) principles and b) capability model.
Before diving into principles, it will be useful to declare some scope. Our framework has developed from working with larger enterprises, both commercial and government in the area of business service and solution delivery. All of these enterprises share common issues that they have extensive legacy application assets that act as a serious inhibitor to business change, and successive, narrowly scoped solution projects over many years have often resulted in great complexity and technical debt. It is also common in my experience that enterprise architecture functions are routinely bypassed or ignored; that Agile methods have been attempted and found useful on narrow focused projects, but because of the constrained focus, tend to increase overall complexity of the ongoing application asset base; that consistent customer experiences are commonly compromised by narrow focused projects; and line of business managers in large enterprises are frequently dissatisfied with IT application service support.
– describe practices relevant to service and solution delivery in the digital business environment
– achieve a balance between short term goals and longer term objectives
– support progressive transformation to an enterprise comprised of independent business capabilities
– facilitate continuous, short cycle time evolution of business capability
– progressively and continuously resolve legacy portfolio complexities
– enable rapid delivery at low cost without compromise in quality
Principles should be enduring and lead to both excellent policy communication and policy interpretation in everyday situations. I also find it useful to classify principles by subject.
In business architecture the capability model has become ubiquitous. And in thinking organizations I observe delivery of highly independent service and solution components that reduce dependencies and the impact of change, as well as mirroring the IT architecture on the business organization. Why wouldn’t we use the same approach in defining a set of activities to deliver services and solutions?
If you are uncertain about the capability concept, it’s important to appreciate that the optimum business capability is one that enables:
– maximum cohesion of internal functional capability, plus consistency of life cycle, strategic class (core, context, innovating . . . ), business partition (global, local, LoB . . ), standardization, customizability, stability, metrics and drivers
– defined, stable dependencies that are implemented as services
[Further reading on capability optimization ]
In the capability dependency model below, the arrows are dependencies. For example, Demand Shaping is dependent upon Conceptual Business Modeling and Portfolio Management. So this is not a flow diagram, rather all the capabilities should be regarded as iterative, I will come back and discuss how Lean principles operate in a framework like this, and as discussed above, highly independent.