Eight to Late

Sensemaking and Analytics for Organizations

Six heresies for enterprise architecture

with 13 comments


In a recent article in Forbes, Jason Bloomberg asks if Enterprise Architecture (EA) is “completely broken”.  He reckons it is, and that EA frameworks, such as TOGAF and the Zachman Framework, are at least partly to blame.  Here’s what he has to say about frameworks:

EA generally centers on the use of a framework like The Open Group Architecture Framework (TOGAF), the Zachman Framework™, or one of a handful of others. Yet while the use of such frameworks can successfully lead to business value, [they] tend to become self-referential… that [Enterprise Architects end up] spending all their effort working with the framework instead of solving real problems.

From experience, I’d have to agree: many architects are so absorbed by frameworks that they overlook their prime imperative, which is to deliver tangible value rather than pretty diagrams.

In this post I present six (possibly heretical!) practices that underpin an evolutionary or emergent approach to enterprise architecture. I believe that these will go some way towards addressing the issues that Bloomberg and others bemoan.

The heresies

Here are they are, in no particular order:

1. Use an incremental approach

As Bloomberg notes in the passage above, many enterprise architects spend a great deal of their time creating blueprints and plans based on frameworks.  The problem is,  this activity rarely leads to anything of genuine business value because blueprints or plans are necessarily:

  1. Incomplete – they are high-level abstractions that omit messy, ground-level details. Put another way, they are maps that should not be confused with the territory.
  2. Static – they are based on snapshots of an organization and its IT infrastructure at a point in time. Even roadmaps that are intended to describe how organisations’ processes and technologies will evolve in time are, in reality, extrapolations from information available at a point in time.

The straightforward way to address this is to shun big architectures upfront and embrace an iterative and incremental approach instead. The Agile movement has shown the way forward for software development.  There are many convincing real-life demonstrations of the use of agile approaches to enterprise-scale initiatives (Ralph Hughes’ approach to Agile data warehousing, for example).  Such examples suggest that the principles behind agile software development can be fruitfully adapted to the practice of enterprise architecture.

The key principle is to start as small as possible and scale-up from there.  Such an approach would enable architects to learn along the way, giving them a better chance of getting their heads around those messy but important details that get overlooked when one considers the entire enterprise upfront. Another benefit is that it would give them adequate time to develop an awareness of the factors that are prone to change frequently and those that will remain relatively static. Most important, though, is that it would offer several opportunities to correct errors and fine tune things at little extra cost.

2. Understand the unique features of your organisation

Enterprise architects tend to be people with a wide experience in technology. As a result they are often treated (and see themselves) as experts. The danger of this attitude is that it can lead them to believe that they have privileged insights into the ills of their organizations.   A familiarity with frameworks tends to reinforce this view because frameworks, with their focus on standardization, tend to emphasise the common features of organisations.  However, I believe that instead of focusing on similarities an enterprise architect would be better served by focusing on differences – the things that make his or her organisation unique. Only when one develops an understanding of differences can one start to build an architecture that actually supports the organization.

To be sure, there are structures and processes that are common to many organisations (for example, functions such as 1st level support or expense reimbursement processes) and these could potentially benefit from the implementation of standardized designs / practices. However, the identification of such commonalities should be an outcome of research rather than an upfront assumption. And this requires ongoing, open dialogue with key stakeholders in the business (more on that later)

3. Form your own opinions about what works and what doesn’t

The surfeit of standardized “best practice” approaches to EA tends to make enterprise architects intellectually lazy.  This is actually a symptom of a wider malaise in IT: I have noticed that professionals in the upper echelons of IT are happy to “outsource their thinking” by following someone else’s advice or procedures without much thought.  The problem with this attitude, penalty clauses notwithstanding, is that one cannot “outsource the blame” when things go wrong.

I therefore believe one of the key attributes of a good architect is to develop a critical attitude towards frameworks,  “best practices” and even consulting advice (especially if it comes from a Big 4 consultancy or guru).  If you’re really as experienced as you claim to be, you need to develop your own opinions of what works and what doesn’t and be willing to subject those opinions to scrutiny by others.

4. Understand your organisation’s constraints

Humans tend to be over-optimistic when it comes to planning: witness the developer who blithely tells his boss that it will take a week to do a certain task…and then takes a month because of problems he had not anticipated. Similarly, many architects create designs that look great on paper but are not realistic because they have overlooked potential organizational constraints.  Examples of such constraints include:

  1. Top-down reporting structures in which all decisions have to be made or approved by top management.
  2. Rigid organizational hierarchies that discourage cross-functional communication and collaboration.

Although constraints can also be technical (such as the limitations of a particular technology), the above examples illustrate that organizational constraints are considerably harder to address, primarily because they involve changing behaviour of influential people within the organization.

Architects lack the positional authority to do anything about such constraints directly. However, they need to develop an understanding of the main constraints so that they can bring them to the attention of those who can do something about them.

5. Focus on problem finding rather than problem solving

In his book, Management in Small Doses, Russell Ackoff wrote that in the real world problems are seldom given; they must be taken. This is good advice for enterprise architects to live by.  Indeed, one of the shortcomings of frameworks is that they tend to present the architect with ready-made problems – specifically, any process or technology that does not comply with the framework is seen as a problem. Consequently, many architects spend considerable effort in fixing such “deviations”.  However, non-conforming processes or technologies are seldom the most pressing problems that the organization faces.  Instead, an enterprise architect will be better served by of finding problems that actually need fixing.

6. Understand the social implications of enterprise architecture

Enterprise architecture is seen as a primarily technical undertaking. As a result architects often overlook the social implications of their designs. Here are a couple of common ways in which this happens:

  1. Enterprise architecture invariably involves trade-offs. When evaluating these, architects typically focus on economic variables such as cost, productivity, efficiency, throughput etc., ignoring human factors such as ease of use and user preferences.
  2. Any design choice will (usually) benefit certain stakeholders while disadvantaging others.

Architects need to remember that their plans and designs are going to change the way people work. Nobody likes change without consultation, so it critical to seek as wide a spectrum of opinions as possible before making important design decisions. One can never satisfy everyone, but one has a better chance of making sensible compromises if one knows where all the stakeholders stand.

In closing

To summarise: enterprise architects need to take an emergent approach to design. Such an approach proceeds in an incremental fashion, pays due attention to the unique features and constraints of an organization, focuses on real rather than imagined problems…and, above all, acknowledges that the success or failure of enterprise architecture rests neither on frameworks nor technology, but on people.  My (admittedly limited) experience suggests that such an approach would be more fruitful than the framework-driven approaches that have come to dominate the profession.

Written by K

October 8, 2014 at 9:04 pm

13 Responses

Subscribe to comments with RSS.

    • Dead-on observations. Enterprise Architects have too often succumbed to the siren call of abstraction rather than the chaotic cacophony of reality. They look at cars, planes and ships and say, “Well, aren’t they all just instances of transportive elements?” And then they wonder why no one understands what they’re talking about. Also, architectures must be timed-based, since information systems and business processes are frequently changing. It’s crucial for project managers and developers to know what the target environment will be when they implement, not what the ideal environment would be if everything worked perfectly.

      Another worrisome sign about the state of Enterprise Architecture: Google “Enterprise Architecture” and “System Engineering” and see how few hits come up. These are highly interrelated disciplines, folks–or, at least, they should be.


      Brad Bigelow

      October 10, 2014 at 3:29 am

      • Hi Brad,

        Thanks for reading and commenting – much appreciated! I like the way you put it, “the siren song of abstraction vs the chaotic cacophony of reality.”

        Your comment about the lack of a systems perspective within EA practice is absolutely spot on.This is true in other, related areas as well – project management, for instance. I wrote a post a while ago on how most diagnoses of project failure are incorrect, they are merely symptoms of a deeper, systemic issue. I reckon there’s a similar point to be made regarding the failure of EA.

        Thanks again for taking the time to read and comment.





        October 10, 2014 at 9:14 am

      • laughed out loud at ‘They look at cars, planes and ships and say, “Well, aren’t they all just instances of transportive elements?” And then they wonder why no one understands what they’re talking about’


        Paul Culmsee

        October 10, 2014 at 9:25 am

  1. Too low-level (classes, instances), not enough abstraction – from conceptual modeling cars, planes and ships that carry goods are “elements of material flow”🙂



    October 10, 2014 at 1:16 pm

  2. Reblogged this on Voytek The EA and commented:
    Excellent post, which further reinforces my beliefs that architecture frameworks are way oversold. Iterative, value-based approach to EA, without religious devotion to a given framework is what I have been preaching too. Great post Kailash!


    Voytek Janisz

    October 11, 2014 at 9:16 pm

    • Hi Voytek,

      It is immensely gratifying to get feedback from a practising EA who shares my sentiments. Thanks so much for reading and commenting, I truly appreciate it!





      October 12, 2014 at 8:39 pm

  3. Excellent post – in my world I try hard to keep up with real problems that needs solutions and take that experience back to strategy work for the whole enterprise. Frameworks are not on top in the tool-box. Observation, communication and try-fail-try again-… works quite well. To be proactive – well, ask questions and let all your tools help you and put the answers on an open table – perhaps new questions arise.


    Peo Ekström

    October 22, 2014 at 3:39 am

  4. […] Customer Relationship Management platforms, but also to design and process-driven IT functions like architecture and service […]


  5. Don’t frameworks always seem to lead to a top-down approach? They afford a scaffold on which top level managers and consultants can try to understand the entire enterprise and fix its processes. But, that is a fools errand. The people in those processes certainly have a grasp on their problems. They just need leadership and freedom to join a bottom-up and emergent approach. Top managers are responsible for the enterprise system as a whole, its appropriate culture and noble goals. Absent those, the descent into chaos is well documented.


    Rick Bollinger

    November 12, 2014 at 12:03 am

  6. […] said TOGAF is (almost) entirely silent on the following question which I addressed in a post late last […]


  7. […] I’ve published a number of posts in which the term emergent design makes a cameo appearance (see this article or this interview for example). Some readers may have noticed that although the term is […]


  8. […] I have ranted about the current state of enterprise architecture – the first article is about EA in general and the other about the TOGAF framework. If you have a quick skim through, you’ll see that […]


Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s

%d bloggers like this: