/Tag: Business Architecture

Design Thinking in Business Capability Modeling

By |2018-04-13T18:57:57+00:00April 13th, 2018|Enterprise Architecture|

One of the most interesting and difficult challenges of Business Architecture is creating the capability model for an enterprise. In this article, I’ll explore how to use the practices of Design Thinking to support the difficult and sometimes contentious process of creating a business capability model for an enterprise. First, let’s understand the problem a little.

For an enterprise that doesn’t have a capability model, developing the first one can be tough. Fortunately, the efforts of the Business Architecture Guild have started to produce value in the form of Reference Models. Even with a reference model, the challenges can be substantial. That is because a capability model is not a foregone conclusion. There are many ways to frame the capabilities of an organization in a capability taxonomy and that framing is important. Framing the capabilities in a particular way can drive conversations (both good and bad). For example, if we describe different capability groups for Marketing, Sales, and Customer Services, in which group do we put “Customer Record Management”? Getting this right may be important in getting key executives to step up to their responsibilities in the organization.

A capability model is supposed to be independent of the politics and processes and structure of an organization, but to be honest, the most effective capability models reflect the needs, ownership, and strategy of the organization in subtle ways. I’ve seen capability models with dependency connections, with ownership groupings, and with budgetary groupings, all as “overlays” that are both useful to the planning efforts, and which influence the capability model itself. It’s a complex problem but one that we can solve with Design Thinking.

Design Thinking is an interesting technique that can be used to approach complex problems. Design thinking makes some basic assumptions: (a) We start without actually knowing what the destination is, (b) we center our solutions around deep empathy for the customer, and (c) we create a new design, a new thing, or a new way of interacting with something through rapid prototyping and iteration. Design Thinking can be used to design a bicycle, a space ship, a house, a business process, a software package, a vacation, and yes, a Business Capability Model.

In many ways, the techniques of design thinking are well suited for the task of generating a capability model. In most of the situations I’ve been aware of, stakeholders for a capability model have never seen one before and have no idea how to use one. It’s tough to assist in designing something that you’ve never used before. Consider: if you had never taken an airplane trip and someone asks you to design the perfect passenger cabin for an airplane… how well would you do? Design thinking does not assume that you have experience with the solution before you start. As a result, you can be comfortable that your “novice-developed airplane cabin” will at least be a reasonable one, even before you take your first flight.

With design thinking, there are five phases: Empathy, Problem Definition, Ideation, Prototype, and Test (with the last two in a quickly spinning cycle). So let’s apply these five stages to Capability Model Development.

design-thinking-amalik-1

Empathize — The foremost value of the empathize stage is to put the customer at the center of your work, and remove yourself from it. Your preconceived notions of the “right way” to build something, or “what something should look like according to Expert X” just gets in the way. Your customer will describe their “conceptual space” in their own way, and different people will do it differently. To truly empathize, you have to make sure you are representing the right stakeholders, and that you are actually listening to their issues and concerns.

One thing that I find, often, is that most people have “typical” problems. If someone has typical problems, their concerns will be well understood. But there are always outliers — people who seem to always have unusual problems. These folks can provide greater insight when you are building your understanding of the problem space, because their problems challenge the status quo. They don’t fit neatly into the box. Look for these people. Listen to them.

Empathy in capability modeling means, in my experience, to listen to how a team describes themselves and to capture it their way. Do they discuss processes and procedures? Do they discuss assets? Locations? Events? Information? Documents? Workflows? Your capability model will need to reflect a wide array of stakeholders, so as you move between those stakeholders, don’t begin by forcing them into your box. Step into theirs.

Sketch (literally, with pencil) a simple non-structured diagram that represents their way of thinking of their space. Yes, eventually you will build a capability model, but don’t start with the strict definition of capabilities. Empathize with where your customers actually live, and what they actually live with.

I wouldn’t expect it to be any more “sensible” than something like the following diagram.

design-thinking-amalik-2

Problem Definition — How many times, when we get to the end of our efforts, do we look back and say “We should have asked better questions?” Design Thinking puts this problem right up front. We believe we understand the stakeholders through our empathy, but before we put the capability model onto paper and start hashing it out, let’s be clear about what problem we are trying to solve.

Capability models, in my experience, are excellent tools for planning. We can manage a portfolio and plan for changes. We can observe processes and plan for improvements. We can evaluate readiness and plan for training. We can find overlaps in application functionality and plan for consolidation. It’s planning. But not every organization plans the same way, and few organizations have a mature planning process. So as you build your capability model, think about who will own specific capabilities, how those owners will use their parts of the model to develop those plans, and how those plans will roll together. Think about the inputs to planning: trends, strategies, changes in the ecosystem, changes in the competition, problems with existing systems, and technical debt.

Your result needs to be a question that frames the problem you are trying to solve. As you pose this question to your stakeholders, their reaction will tell you if your question was effective. Don’t be afraid to drop your attachment to specific terms or processes or methods. Let things flow a little. Phrase the question in terms of the customer’s needs. One good technique is to use the phrase “How can we …” in your problem statement.

“How can we frame all the abilities needed by our business model so that we can best plan and coordinate our forward march?”

Please don’t use my example as anything more than an example. The problem statement you create should “feel” like it evolves out of the language, terminology, and culture of the organization itself.

Ideation — A capability model created by a business architect and thrust upon the organization will be dead on arrival. That is not a prediction. That is a foregone conclusion. How do I know? I’ve done it. School of hard knocks. Let the stakeholders build their capability model a series of collaborative sessions. Ideation is the first step in that process.

The ideation step can use any of a number of techniques to open the stakeholders up to different ways to frame the capability model. At this stage, you are creating capabilities, so we are applying the first series of constraints on the process. There are a dozen different ways to frame ideas that do NOT end up with a capability model, but for the sake of this exercise, we will write them down and not pursue them. We need our end result to be constrained to capabilities. Other stuff will fall out.

If the company has a process model that they actively use, you can start there.  If they don’t have one (or don’t actually use the one they have), consider using one of the capability reference models from the Business Architecture Guild (businessarchitectureguild.org) as a starting point. This is far quicker than starting from scratch. However, it is only a source of ideas. Let the team reword, rename, join, split, and shred the starting “thing” any way they want.

To keep ideation from becoming a long involved process, I suggest a series of simple exercises to expand the number of possibilities, and then consolidate that list to the most feasible ones. Then expand again, and consolidate again. Each iteration, considering a different aspect of your thinking or understanding.

An excellent technique is the SCAMPER method, which pushes participants through seven different ways of thinking about the “starting” product to create a new “ending” product. Those seven ways of thinking are: Substitute, Combine, Adapt, Modify, Put to another use, Eliminate, and Reverse. There are a number of online resources available if you want to go deeper on using SCAMPER. Other methods may include brainstorming, worst possible idea, paint by numbers, and many more. All of these are designed to get creative juices flowing, especially for a group of people, while keeping the results controlled.

Prototype and Test — Capability models are a unique bird because they represent the abilities needed by an enterprise to achieve a purpose. For all intents and purposes, you are creating a list. That list of abilities often exceeds the organization’s internal capabilities. This is why we talk about the capabilities of an “enterprise” and not the capabilities of a “business”. An enterprise may involve many businesses, suppliers, partners, regulators, and even customers in providing the required list of capabilities.

Creating a prototype capability model is a process that is complex if done by hand (without a capability modeling tool). This is because you may have twenty stakeholders, and most of them do NOT want to see the entire organization in the capability model! They want to see THEIR PART represented in gory detail and want to see everyone else minimized. For this reason, you need the ability to prototype a complete model (for the enterprise) but to review segment-level capability models with the stakeholders. Without a tool of some kind, this can create a great deal of manual effort. (This is not a problem unique to Design Thinking… this happens with all capability model generation).

I’ve found that the prototype effort actually begins during ideation. Since we are building a knowledge product, and not a physical product or even a software product, the first prototype is actually developed in the collaborative session to some extent. It is the synthesis of that prototype with the work done by other stakeholders, in their own ideation processes, that creates the enterprise model.

Resist the temptation to go dark, work for a while, and spring an enterprise model on the organization. Work your way up from stakeholders who buy in, showing them models that are domain specific. Put four or five of the domain specific models onto paper and get feedback before attempting to create the first synthesized model. Otherwise, one domain will have undue influence over the entire structure of the capability model.

With each prototype, you are producing a new enterprise capability model and a complete refresh of domain-specific models. Run them past key stakeholders for quick responses. Remember their needs: this is a planning framework. Can they use the capability model to develop their plans? Keep asking the core question.

When you have sufficient representation across the enterprise to have created the enterprise wide model, you can circulate that model with the core planning teams in your organization: these teams may go by names like Strategy Development, Organizational Development, PMO, Enterprise Architecture, Finance, and Strategy Execution.

Conclusion

Design thinking is certainly not the only way to design a product, and it is relatively novel in specific areas of organizational and strategic planning. However, as this example illustrates, design thinking can be applied to purely knowledge based products like a capability model in a manner that hopefully builds better buy-in for the final result.

And who couldn’t use a little more buy in?

Useful links

Business Architecture, Setting the Record Straight – William Ulrich and Whynde Kuehn — http://www.businessarchitectureguild.org/resource/resmgr/BusinessArchitectureSettingt.pdf

Design Thinking Blog – Tim Brown, Ideo – https://designthinking.ideo.com/

Design Thinking and the Enterprise – Pramod Prakash Panda, AVP, Infosys https://www.infosys.com/insights/human-potential/pages/design-thinking.aspx

Design Thinking, What is that? – Fast Company, 20 March 2006 https://www.fastcompany.com/919258/design-thinking-what

A guide to the SCAMPER technique for Creative Thinking – Rafiq Elmansy, Designorate http://www.designorate.com/a-guide-to-the-scamper-technique-for-creative-thinking/

Note that this article was first published on the Infosys Enterprise Architecture blog.  I created this  article in my role as an Enterprise Architect for Infosys.  I strongly encourage my readers to check out the Infosys Enterprise Architecture blog for excellent articles on EA, EITA, and trends in technology.

http://www.infosysblogs.com/enterprise-architecture/2018/04/design_thinking_capability_modeling.html

The Capability Instance – can capabilities be realized?

By |2017-10-12T04:52:29+00:00February 24th, 2017|Enterprise Architecture|

Bizbok 5.5 from the Business Architecture Guild mentions an interesting concept that I’d like to discuss here: the capability instance.  I’d like to caution that this description is a concept rife with conflicts.  I’ll explain in a moment.

(more…)

Translating business capability maps into business impact

By |2016-12-15T08:53:36+00:00December 15th, 2016|Newsletter|

Creating a business capability map is just part of the challenge businesses and chief information offices face. Taking the information in the map and making it work and translate into real, tangible business impact can often present far more obstacles than the development of the map itself but without this crucial step the benefits of undertaking the task of creating a business capability map are generally lost. (more…)

Disruption – why you need business architecture

By |2016-11-30T04:34:11+00:00November 30th, 2016|Enterprise Architecture|

Business Architecture is, on occasion, a difficult sell.  In many companies, it can be tough to get senior leaders to give you to remit to use the tools and techniques of business architecture.  This is especially true in organizations that think of Enterprise Architecture as an IT function.  The following video answers the question “Why do we need Business Architecture?”

Your feedback is encouraged.

 

The human element to strategy

By |2016-07-15T23:03:43+00:00July 15th, 2016|Enterprise Architecture|

There is no shortage of business thinkers and authors who will tell us this statement is true:

Anyone can create a good strategy.  The most frequent failure is in execution.

Unfortunately, this underestimates the difficulty in creating a “good strategy.”  While the statement above is absolutely true, it is not unusual to find companies that don’t have a formal strategy at all, or who fail to share their divisional strategies with all of their employees (a key measurement of strategy adoption in a company is “how many of your employees can recite your company strategy”).

One of the obstacles I’ve come to recognize in Enterprise Architecture is unique to companies that either don’t have a formal strategy or who do not share their strategy with their staff — you cannot align efforts to strategy if there is no consistent understanding of strategy across divisions.

I always knew this was true.  I’ve become more and more convinced that it is a hard-and-fast rule.  In other words, if you want to be successful as an EA in a company that doesn’t share strategy, this becomes your First Order Problem — how to develop a consistent strategy that everyone at the senior level agrees with and that they are willing to share with their staff.

That’s it in a nutshell.  To be successful, your organization must develop a consistent strategy that everyone at the senior level agrees with and that they are willing to share with their staff.

First order problem — In other words, focus on this.  Make progress on this.  Measure yourself by your progress on this.  Associate yourself with the people who “should” own this, and align yourself with the people who actually do own this (rarely the same person). Find ways to be involved.  Find ways to contribute. Volunteer.  Make things happen.  Find ways to support incremental progress, while recognizing that the increment may not be good enough in the long run.  For EA to become known for “doing successful Enterprise Architecture,” a clear and communicated company strategy is ground zero.

 

Welcoming Archimate to Enterprise Architecture

By |2016-10-21T09:38:17+00:00June 28th, 2016|Enterprise Architecture|

I’m going to get some heat for that title… I’m sure of it.  Archimate has been a diagramming standard for some elements of Enterprise Technical Architecture for a couple of years now.  However, with the new release of Archimate 3.0, this interesting visual language is now directly useful to Enterprise Architecture from the perspective of a Vanguard EA.

(more…)

Alternatives to the EPSC Model

By |2016-07-10T00:45:26+00:00February 16th, 2015|Enterprise Architecture|

The Enterprise Partner Supplier Customer (EPSC) Model sits as a core concept of Enterprise Architecture.  It is so much at the core of everything we do that we seldom question it.  Is that healthy?  This post will discuss the core idea behind the EPSC model (differentiation by control) and alternative ways to think about enterprise boundaries.

First off, we only name things when we want to differentiate them.  As the old expression goes, “the fish discovers water last.”  In EA, we tend not to discuss the fact that we assume a particular model of enterprise identification and enumeration on a regular basis.  That’s because the model is built in to the things we say and do.  It’s built in to our business models and our service models.  It’s built in to the way enterprises create policies and budgets and govern efforts.  It’s so deeply ingrained that we rarely question it.  Well, it’s time for this fish to discuss the nature of water.  And to do that, we have to name it.  I’m naming it the EPSC model, which is an acronym for “”Enterprise Partner Supplier Customer”.  It looks like this:

image

The view that an enterprise is a bounded thing, with suppliers feeding in, customers getting the benefits, and partners in a peer-to-peer relationship… that’s the EPSC model.

The underlying assumption of EPSC is control.  In this model, there is typically OWNERSHIP CONTROL over the enterprise.  “Ownership control” means the same people OWN an influential number of shares in each of the organizations inside the box.  That is not necessarily controlling interest.  It is sufficient interest to ensure that the all the businesses inside the box get along well with each other.  It works because employees do what their bosses tell them to do.  Take that fundamental notion and expand it to the enterprise level and you get the assumption of ownership control.

Another form of control is ECONOMIC CONTROL which is typically the case when there is a huge size disparity between the suppliers and the enterprise itself with respect to the end customers.  This happens in retail a great deal. Walmart is a textbook example of “economic control” since their supply chain requirements can drive massive costs into their suppliers without any substantial backlash.  The fundamental model above is the same so I’m not going to redraw it.  It’s still EPSC.  Just with a really big “E”.

Why do we need alternative models?

The Internet has introduced some things we expected, and some things we didn’t.  We expected the introduction of easy communication and easy transmission of data.  What we didn’t expect: the creation of the commercial ecosystem as a differentiating factor in strategy.  In other words, the creation of a product by one company that is combined with another product to be consumed by a customer dependent upon both to solve the needs of a customer that is totally unaware of either one.  This is common now in the mobile applications space.  A mobile app may be created from unique capabilities of four or more companies that are not just peers, they are collaborating peers, all focused on producing the mobile application.  Yet the customer is unaware of the grouping.

The EPSC model is completely broken for understanding this space.  It simply fails.  Because there is no boss telling you what to do.  There are only customer opportunities.  It is organic and bottom up in its very nature.

And the moment we examine the “more than one” condition, we have to open the door to the possibility that there are more than two or three or ten.  How many alternative models are there?  I do not know.  No one has enumerated them and drawn distinctions (hey, doctoral candidates… want a dissertation idea?  Enumerate these).

I will brainstorm a couple of alternatives.  This is not a thoughtful investigation of models.  It’s a brainstorm.  Take it with a grain of salt.  But I encourage you to use the ideas to expand your own thinking.

The Dynamic Collaboration Model

The dynamic collaboration model involves a series of companies that have no common ownership but who collaborate on a very frequent basis to create positive value for customers that is achievable through the combinations of their products.

image

The key to success in this model is to focus on that dynamic collaboration and to build excellent feedback mechanisms with the customer.  This kind of model can fall apart of the customer loses confidence in the collection of companies to meet their needs, and it is vulnerable to attack from alternative collaborative groupings that build better feedback mechanisms.

What other models exist?

My knowledge is not wide enough to suggest that I understand other possible models.  Perhaps recognizing more than collaborative self interest is necessary to even perceive them.  I know that there are more than one, and I’m guessing that there’s more than two.  These are the two that I can see.  Please post your own ideas and we can collaborate.

What does this matter?

Well, I’d suggest that the strategy of Microsoft under Bill Gates reflected the dynamic collaboration model, but that the strategy under Steve Ballmer reflects the EPSC model.  We can see the gradual deterioration of value and innovation during this period.  Microsoft under Satya Nadella has shown signs of moving back towards the dynamic collaboration model.  Time will tell.  He inherited a very weird beast.

But just as important as understanding Microsoft, what does this say about Google, Amazon, Force.com, IBM, Oracle, and the hundreds of other competitors (and open source initiatives) that fill the technology space?

  • Oracle seems to play in the EPSC model.  What does that say about the future of Oracle?
  • Amazon clearly plays in the Dynamic collaboration space?  Does that ensure a bright future?  How important are each initiative in Amazon when vi
    ewed in this context?  While delivery to the neighborhood is necessary, are the drones needed?  Or is that just good buzz?
  • Google… plays in both.  (Kind of like Microsoft).  The EPSC model drives their revenue, but there’s a lot of initiatives in the dynamic collaboration space.  Is this an intentional transition, or just opportunism?
  • Facebook is primarily an EPSC business, with a very large base of users.  (See economic control above).  Will they make moves toward dynamic collaboration?  Can they survive if they don’t?

This kind of differentiation is useful for making these kinds of observations.

 

Your thoughts?

How brand-thinking can kill you, and capability thinking can save you

By |2015-01-29T19:12:50+00:00January 29th, 2015|Enterprise Architecture|

I guess it shouldn’t surprise me that business strategy work is often about constrained thinking.  Thinking “inside the box” is nearly always rewarded well.  After all, the person giving the rewards lives in the same box.  One of the most pernicious kinds of constrained thinking is “brand thinking.”  That is the notion that the value of your existing brand is the starting point for all your products.  Living within the box of the brand is definitely constrained thinking.

Brand thinking says “everyone knows us for doing this one thing well, so let’s invest in variations on that thing.”  That’s great.  And it often works.  For example, the Dell computer company has a great reputation for building good (but not wildly innovative) personal computers for individuals.  So naturally, when they decided to diversify, they decided that they should build on that brand.  They decided to build server computers for businesses.  It worked fairly well.  As they tried to become more innovative, they had problems with the brand.  In some areas, Dell simply bought other brands (Alienware for gaming computers, for example).

On the other hand, brand-thinking also leads to a kind of situational blindness.  Essentially, we choose not to see the things we think are outside the brand, or even the market, that we are used to.  And in doing so, we nearly always miss opportunities.  At least, until our competition points them out to us.  Dell was good at electronics manufacturing to the home.  Had they looked outside their brand, and focused on their abilities, perhaps in the 1990s, they would have been successful competing with Sony or Sharp for personal electronics.  Brand thinking says “no.” They stuck to computing, moving into printers, laptops, and tablets.  All have suffered from the “commoditization” of their market. 

A strategist is a unique role.  To be a successful strategist, you have to do everything you can to resist the boundaries of constrained thinking.  But then your ideas have to be judged by people who are PAID based on constrained thinking.  And that’s a tough sell.

Capability Modeling

When we do business capability modeling, we are looking not at the products of a company, or it’s brand, but at what that company can do.  We look at what a company has the people to do, the processes to do, the information to do, and the tools or technologies to do.  We bring together this knowledge into a complex model of elements, and summarize it as a capability map. 

The value of doing this is typically revealed when creating initiatives for the execution of strategy.  If a company is doing incremental strategy, there may be one or two areas that have slowed or prevented the company from achieving its goals with respect to its competition.  But when a company is following an innovative strategy, there may be a dozen different capabilities that need attention.  Some may have to be created from scratch.  Capability modeling is a clearly valuable tool in this arena.

However, there is another use for capability modeling that is not often discussed, and that is the need for unconstrained thinking on the part of the strategist. 

Could Capability Modeling have saved Kodak?

If you are over the age of 30, and live in a western country, you’ve probably heard of Eastman Kodak.  Known for their near monopoly on film and film processing, Kodak was the undisputed king of photography for decades.  In 1990, they held 90% market share.  They were unbeatable.  Remember this logo?  It was a very successful brand.

Let’s assume Kodak had done a capability model back in 1990 and had actually paid attention to it.  They would not look at their brand or their existing products, but at the things that they do very well.  What would be on that list of “things they do well?”

  • R&D in chemical-based manufacturing
  • Manufacturing of plastic and chemical based products
  • Manufacturing of specially treated paper
  • Manufacturing of chemical processing equipment
  • Consumer-focused marketing
  • Motion-picture-industry marketing

Let’s be clear here. These capabilities were not just solid.  They were the best in the world. 

What’s not on here?  Electronics.  Electronics manufacturing.  Electronics R&D. Electronics Marketing.  Not on the list.

So when Kodak started to see the need to expand, they used brand thinking.  People see the brand “Kodak” and think photography.  So why not go into the manufacturing of digital cameras?

Do you see anything on that list of capabilities that deals with innovation and manufacturing of digital cameras? Heck, they didn’t make that many analog cameras (Nikon, Olympus, and Canon made most of the analog cameras).  They had no distribution network, no reputation, no capabilities, no core skills to make cameras of any kind, and certainly not digital cameras. 

Even though they were able to leverage their brand for a while, eventually their ability to sell digital cameras fell away and they lost money.  Huge sums. At the same time that their analog film business was also losing money.

Now, look at that list again.  What do you see?  Ignore the fact that this is a film company.  Do you see other things there?

The simplest capability to build is the ability to market to a new segment.  The hardest is the ability to do R&D and manufacturing well, so let’s drop the marketing for a moment. Not completely, but let’s focus on the hard stuff.  Could they have built products based on treated plastics and treated paper?  Almost certainly.  There’s an entire industry that makes sheets of plastic film for a wide array of different purposes from glass protection to window tinting.  What about chemistry based R&D?  Could they have created innovative consumer products to compete with companies like Clorox or Proctor and Gamble? Could they have leveraged their chops in chemistry to compete with companies like 3M?  Maybe.  But only if they had looked first at their core capabilities.

The important thing to note about these industries is that they have not been disrupted by technology the same way that camera film was.  While these industries are not easy to compete in, the ability to leverage existing world-class capabilities is more critical to success than the ability to leverage the brand. 

Eastman Kodak thought of themselves in the film and photography business.  And it was their downfall.  Unfortunately, it still is.

And now a challenge…

What about this brand?  What are their core capabilities?  And what can they be doing with those capabilities? 

Are they on the precipice of disruption?  You bet.

American Express logo

Moving Towards a Theory of Enterprise Architecture

By |2015-01-16T13:28:41+00:00January 16th, 2015|Enterprise Architecture|

I’ve been asked a number of times over the years if I can explain the theory of Enterprise Architecture.  I decided recently to reopen that idea.  It’s not a new discussion.  I refer to Tom Graves post on the Theory of EA from 2012 where he posits that the theory of EA, if one were to be described, cannot be used to prove the value of an EA design.  The not-so-subtle hint is that there is, therefore, no value in creating a theory at all.  I disagree.  I believe that there is value in developing a theory of enterprise architecture. 

Let me first recap my gentle readers on what I mean by a “theory of EA.” 

Typically, in science, we start with observations.  Observations are objectively real.  They should be mathematical and measurable.  They exist within a natural setting and may vary from one setting to another.  We may observe a relationship between those observations.  The goal is to explain those observations in a manner that is good enough to predict outcomes.  To do this, we suggest a hypothesis, which is simply a guess.  We then see if we can prove or disprove the hypothesis using data.  If we cannot disprove the hypothesis, we have passed our first test.  We use the hypothesis to predict new observations.  We then check to see if the predictions are correct.  If so, we have a useful theory

Underlying Observations

Theories are created to explain observations and help predict new ones.  So what kinds of observations would I include in the Theory of Enterprise Architecture?

  1. The rate at which companies can adapt to change varies widely from company to company. Let’s call this the “rate of potential change” (RPC) because it refers not to the actual rate of change, but the potential rate of change which will never be less than the actual rate, but may in fact be more.
     
  2. This rate is important to the survival and health of a company.  Companies can die very quickly when their marketplace is “shocked” by a big change in customer expectations or competitive offerings.  If the Rate of Potential Change (RPC) is high enough, then any shock to the marketplace can be absorbed by an enterprise by responding competitively.  The cost of response appears to increase exponentially as time from the shock increases.  For example, from the date Amazon announced their cloud platform to the date that Microsoft produced a product that was as good as the Amazon initial offering, the time that elapsed created a steep obstacle for Microsoft to overcome.  The cost of overcoming that obstacle is much higher than if Microsoft had been able to respond sooner. The faster you can respond, the more chance you have of survival.  RPC measures how fast you can respond.
  3. The Rate of Potential Change (RPC) appears to be correlated with observable factors like the amount of alignment between strategy and execution, the quality and testability of company strategies, and the measurable maturity of key capabilities for absorbing and coping with change.

These observations need to be measured, collected, and validated.  And we need more observations to be researched, shared, and enumerated.  We don’t know quite what EA explains just yet, and building out the list of observations gives us a place to start.

The EA Hypothesis

At the highest level, the basic premise of Enterprise Architecture is simple:

The EA Hypothesis: The structure of and both intentional and unintentional relationships among enterprise systems has a direct and measurable influence on the rate of potential change and organizational cost of operating and maintaining those systems.

That simple statement is quite powerful. 

The EA hypothesis demands that we create a definition for “enterprise system” and a method for describing the “structure” of an enterprise with respect to those systems and to describe the “relationships” between them.  Clearly an enterprise system has to include socio cultural systems, information technology systems, workflow systems, and governance systems.    

The EA hypothesis suggests that the relationships between these systems are important.  That the relationships themselves influence the rate of potential change. as well as the cost to own a system.

The EA hypothesis demands that we measure the rate of potential change, and that we describe “organizational cost.” To do the latter, we must develop a clear idea of what is involved in operating and maintaining each of the included systems. 

The hypothesis is also fairly unbounded.  It leaves us with important questions to answer.

  • Can we cleanly and concisely define what we mean by “system” so that two architects independently examining the same enterprise would develop the same list of systems?
  • What are the types of relationships among systems and how do we differentiate relationship?  What attributes do these relationships have?  What attributes make sense?
  • Does it apply to one system?  A subset of systems? or can it only be truly understood to apply to the complete system-of-systems that is, in effect, a complete description of the enterprise?
  • What standard methods can we develop for identifying ALL of the relevant systems of an enterprise quickly and effectively for the sake of understanding the architecture of the enterprise?

I’m intentionally not answering these questions here because it is rational to leave all of these questions open for scientific research.  It is entirely possible that the answers may help us separate useful EA models from useless ones.  It is simply too soon to tell.

Why the EA Hypothesis matters

The rationale for creating an EA hypothesis is the requirement, often expressed through strategy, placed on an enterprise by its senior leaders, to do one of two things:

  1. improve the quality and reduce the organizational cost* of performing existing enterprise capabilities, or
  2. creating or expanding capabilities in an enterprise through targeted, specific and managed changes to the network of systems

This matters because nearly all strategy hits one of these two buckets.  This goes from corporate strategy all the way down to personal improvement: either you are improving your production, or your production capacity.  Either you doing what you know how to do, or you are learning new things.  Either you are getting better at the normal stuff, or innovating to add new stuff. 

Enterprise architects are called upon to help in both ways.  We have to answer questions like: “what does “innovation X” do for us, and what does it do to us?” We also have to contribute to ongoing concerns like “how do I grow my business in “Market Segment Y” in an innovative and compelling way?” and “How do I cut the cost of our IT expenditures?” and “How do I improve the quality of my customer data?”  These questions fall under the category of “organizational cost”.

* Cost and quality come together to include a balance of monetary cost, effectiveness, customer satisfaction, efficiency, speed, security, reliability, and many other system quality attributes.

We need a clear theory of Enterprise Architecture because answering these questions is difficult to do well. We have operated without a theory because we were able to “guess and check.”  We would guess an the scope and value
of an initiative, undertake it, and check on its value later.  But we are not able to say, in advance, that “proposed initiative A” is foolish compared to “proposed initiative B” because we have no science here.  It’s all just “guess and check.”

The term “guess and check” is not new.  My kids learned to use the “guess and check” method in elementary school math class as a way of exploring a problem.  But that’s where the “guess and check” method belongs.  Elementary school.  Grown ups use proven science.

All except EA.  We still use “guess and check.”  It’s time to grow up.

Next steps

  • First off, we need a long list of valid observations that we are trying to explain and understand.  The naturalists of a hundred years ago started with detailed drawings and descriptions of plants and animals and the habitats that they inhabit.  Perhaps we should start with detailed drawings and descriptions of the structure of different enterprises and the niches that they operate in.  We also need a valid way to measure and observe the “Rate of Potential Change” in an organization.
  • Secondly, we need simple reusable methods for conducting research in the area.  A consistent way to count and categorize systems, for example, and an accepted methodology for measuring their cost and quality that can be applied across different types of systems and companies.
  • Lastly, we need evidence of the cause and effect of making changes.  We need a solidly understood and measured system to be captured in a snapshot, and then a series of changes results in another solidly understood and measured system.  That gives us evidence of the value of the changes. 

 

Moving forward from here requires research. More on that connection in another blog entry.