Oct 172007

In the one corner stands the fire breathing reptile, Enterprise Architecture and in the other corner we see pacing restlessly an 8,000 pound gorilla known as Agile Development. Eternally opposed to each other, these two ways of looking at the world fight it out year after year.

Enterprise architects like a command and control, autocratic and hierarchical organizational approach. Agile development prefers an egalitarian, participatory and collaborative approach. Architects like to tell agilists what to do and agilists are borderline anarchists who like to say no. Agilists have suggested they do not need to adapt, at least significantly to the needs of enterprise architects. Architects don’t appreciate change as much as agilists. Agislists find documentation wasteful and architects love it. Agilists focus mercilessly on quality and by inference architects don’t. Architects are about controlling architecture variation (which is bad) and agilists are about creating architecture variation (which is good). Agilists and architects have different philosophies. Architects need to interact with agilists in different ways to be successful.

As Scott Ambler put it (in his “Agile Strategies for Enterprise Architects” in Enterprise Architecture Trends 2007, Cutter Consortium Executive Report, Vol. 10, No. 1), “In my experience, the surest way to failure is to have the enterprise architecture tail wag the development dog.”

Are agilists and enterprise architects at two ends of a spectrum?

Agile is such a loose concept, but a useful one. I like to formally define agile as an organizational capability that lets firms execute larger maneuvers more quickly and accurately then competitors. I also position both agile development methodologies and enterprise architecture methodologies as both subservient to this higher order notion of agile. I also note that firms may decidedly chose to not be agile and for good strategic reasons.

Now let’s tackle a few of the concepts that get roped up in this debate.

Authoritative governance. I don’t believe either team differs that much in this. Good architects and good agilists share similar perspectives on the need for collaboration. As a CIO, I do remind everyone that from time to time that shareholders and courts do not always look kindly at diffuse decision structures. Individual accountability remains a persistent theme in all human organizations. In addition, if command and control structures might actually produce more agility than a more collaborative structure, I may choose to adopt one. In most cases, this is not in order.

Documentation. It is utter nonsense to blame documentation for being useless. Blame those who create it. Agilists rely on tacit knowledge held in their heads and expressed as short-hand verbal communication because their problem is cognitively smaller than the enterprise architecture problem. Architects create documents to communicate critical architecture information. It is foolish to do otherwise. Architects should always communicate critical architecture information in the manner that helps the decision maker. In enterprise architecture, we have created the concept of views specifically for this reason.

Variation. Variation is a variable. Agility implies some amount of variation in excess of what is needed to be able to adapt to novel circumstances. Both architects and agilists should seek a certain amount of variance. Architects tend to be somewhat more skeptical of variation because of their broader perspective. Agilists, because of their narrower scope, would see things differently. Who would I trust? In the end, I rely on the architects to help establish the appropriate level of variation in architectures, wherever they are employed. The surest path to failure is to have the agile tail wag the enterprise architecture dog.

To hell with alignment between business and IT! IT needs to get alignment between agilists and architects!

I suspect there is more smoke than fire in this clipped and polarized discussion. Agilists and architects may be more blood brothers than distant relatives.


  3 Responses to “Godzilla vs. King Kong”

  1. Yo Vince, you trying to stoke the flames? At least that’s what I thought when I read the first paragraph. Of course, after reading the entire post I see that it was just to illustrate the misconceptions about each. It’s too bad that these stereotypes persist because it makes real progress more difficult.

    To explain the differences, it helps to understand the different perspectives, because Agile and EA are trying to solve different problems in very different scopes. Agile is mostly concerned with developing an individual project. We adopt the technique because we have learned that predicting requirements up front is a flawed approach, and that we need to factor what we learn during development into the rest of the design and development. This relates to the variability that Vince mentioned. But not everything on a project is unknown or variable.

    EA on the other hand is about achieving consistency of applications and infrastructure across an entire enterprise, and aligning the entire set with business goals. One of the jobs of EA is to specify the parts of applications that are NOT variable, such as security policies or standard platforms. For example, imagine that an application has a requirement for 99.999% reliability. This requires a very specialized infrastructure. Specific combinations of web servers, load balancers, firewalls, application servers, data bases, data replication, hot standby, disaster recovery, business continuity plans, operational policies and procedures, and trained staffs must be developed, tested and deployed across multiple data center sites. In addition, some specific development techniques may be required (for example around data mirroring) that will affect the way some aspects of code are written. It might cost $1M or more to develop this platform. Maybe it was even done by an Agile project team. The next time an application needs 99.999% reliability, its just plain stupid not to use the same platform for another project.

    So here is where EA and Agile meet, at the project level. The enterprise, represented by EA has a legitimate requirement for using this very specific infrastructure to achieve reliability. This necessarily places some constraints on the project. One point of view might be that it frees the project team from having to worry about the infrastructure and lets them concentrate on providing business value. Of course, not everyone on the team will necessarily see it that way. It’s only when you understand the broader requirements that this make sense. In other words, when agile and EA understand each other’s perspectives.

    One the other hand, there are often cases where architects try to dictate far too much to a project team, leading to the stereotype depicted by Vince. This is equally as wrong headed as thinking that architecture has no place on a project. Just as projects need to understand that they are part of a larger enterprise, architects need to understand that some things are important to specify at the enterprise level, and many other things are not. So rather than waste energy arguing, let’s move on and figure out how to work together….please.

  2. avatar


    Yes! I am in violent agreement! But what you described about agile is exactly what one can claim enterprise architecture is about. Consider the following slight rewording of your two sentences.

    ‘Enterprise architecture lets you create a document if a document is required. It doesn’t mandate it, even if its completely redundant, just because it’s step 31.2 of a process model.’

    ‘Enterprise Architecture is about saying “isn’t it better to have the people on a project sitting around talking and understanding what they are meant to be doing rather than spending days, weeks, even months generating a possibly incomplete, and probably out-of-date ‘view’ on paper?”‘

    Both of these sentences read equally well with the term EA thrown in.

    You are comparing agile development to a caricature of enterprise architecture. I can easily compare EA to a caricature of agile development, for which I and others have seen plenty. The comparison would be equally polarized in perspective! FYI, in my role of CIO, I am pushing both agile methods and EA at the same time and cross-breeding practices across these two domains. Why? Examining their work in a more abstract way, I believe they are actually doing very very similar knowledge work.

    It is exactly this use of language that I am critiquing. I keep reading both sides creating strawmen of the other.

    Good agilists and good enterprise architects are much closer in spirit and in practice.

    Put in a bad architect or a bad agilist in the equation and you get Godzilla vs. King Kong. Put bad agilists with bad architects and you get, well…

    I’ll let readers envision the results themselves.

  3. avatar

    “It is utter nonsense to blame documentation for being useless”.

    Yes, I guess it is: a document is an inanimate object – it didn’t do anything. However, Agile Development is not about saying documentation is useless, it’s about putting its value into perspective against the value of actual software. it’s about saying that isn’t it better to have the people on a project sitting around talking and understanding what they are meant to be doing rather than spending days, weeks, even months generating a possibly incomplete, and probably out-of-date ‘view’ on paper?

    Clearly, where information needs to be stored and conveyed asynchronously, a document is useful. Agile let’s you create a document if a document is required. It doesn’t mandate it, even if its completely redundant, just because it’s step 31.2 of a process model.

 Leave a Reply

You may use these HTML tags and attributes: <a href="" title=""> <abbr title=""> <acronym title=""> <b> <blockquote cite=""> <cite> <code> <del datetime=""> <em> <i> <q cite=""> <s> <strike> <strong>