4 years, 10 months ago

Moving Towards a Theory of 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.

5 years, 7 months ago

Assessing Business Architecture’s Value Contribution

I have been working on a business architecture practice dashboard to help BA leaders manage and grow their practice. The dashboard contains three basic metric types: impact, value, and activity. Each type provides valuable insight into business architecture’s performance and organizational impact. In this post, I focus on value contribution metrics. Value contribution metrics report […]

6 years, 5 months ago

Rational Rationalization – Part the First

With the upheaval of the economic downturn came a spate of mergers, acquisitions, divestitures, splits and buy-outs. The ensuing chaos of the resulting technology portfolios cannot really be overstated. Many surviving companies are just a mess. In norm…

6 years, 8 months ago

Requisite-fuzziness

How should we respond to inherent-uncertainty in qualitative-requirements, for enterprise-architecture and the like? Yes, we can reduce every qualitative-requirement to some sort of metric, but is that always a wise thing to do? And if not, how can we tell whether

6 years, 8 months ago

Metrics for qualitative requirements

Just how should we handle qualitative requirements in system-design and enterprise-architecture? Should we, for example, reframe them into quantitative terms, as metrics – because it’s a lot easier to keep track of ‘measurable things’? Over the past couple of days

6 years, 10 months ago

Rumination on the concept of “best practice”

I heard some very interesting talks today from Len Fehskens and Jeff Scott at the Open Group conference.  One thing that I picked up in a meeting yesterday was the notion that TOGAF 9.1 is built on “best practices.”  Today, as Jeff spoke about the transformation of a technical architect into a business architect, and as Len spoke about the challenges of communicating complex ideas, the notion of a “best practice” kept bothering me, and I cross-pollinated my concerns with the concepts that they were sharing.

I agree that the intent of the people who shared their practices with the Open Group was to provide practices that can be taught and followed.  I even agree that the people on the TOGAF committees that accepted the content felt that the practices represented the best that the industry had to offer at the time.  But I wonder if any of the work done in framework committees of any stripe (not to pick on the Open Group) can be held to the standard of being a “best practice.”

Are the practices in the TOGAF framework truly “best��� practices?  Are these practices the best ones that the EA field has to offer? 

I guess I would have to follow the EA rabbit hole and ask “what criteria do we use to judge if a practice is the best one?”

After all, when Jeff Scott talks about business architecture using capability modeling, he believes that the practice of capability modeling is the best one to use for the results he is trying to achieve.  (I nearly always agree with Jeff, BTW.  We sometimes differ in language, but nearly never in approach).  That said, as much as Jeff and I agree, our agreement does not mean that the practice should be considered a “best” practice.  Who are we to say?  We are practitioners.  While that is good, it is not enough in my mind to qualify the practice as “best.”

To be a best practice, in my opinion, a method or approach has to meet a higher bar.  There has to be evidence that it is, in fact, better than just a “good practice.” 

I think a best practice should have:

  • Some measurement (evidence) that demonstrates that it is an effective practice, and that the measurement shows that it is at least as effective as other practices,
  • A clear understanding of the results of the practice and the context in which it is to be performed (think “Pattern Language” criteria),
  • Some analysis to show that it meets other criteria like broad applicability and simplicity, and
  • We should demonstrate the ability for that practice to be understood and performed by people who are currently in the role (e.g. can we teach it, and if we teach it, can others do it?).

 

I wonder if we went through most of our frameworks and highlighted the text that is able to meet a higher bar, like the one I describe, how much of the text would we cover?  2%?  10%? 

Is 10% coverage enough to say that a framework is based on best practices?