Should We Continue to Invest in Enterprise Architecture?

You're Fired Dave Linthicum attempts to address this question in a recent blog post on his Real World SOA | David Linthicum blog. See the article here:

Check out this post as it is a good read to at the very least give a sanity check on your EA efforts. I also find being the "Devil's Advocate" at times is also healthy. Always hanging out on the band wagon for too long can cause of a lot of damage.



Here is a snippet from Dave's post:

Truth-be-told most enterprises are not spending that much on enterprise architecture. Indeed, for most of the Global 2000 there is a lone architect, with a couple of staffers, that has no budgetary nor referential authority, thus no results. You can't "influence" your way to success, you have to have some kind of hammer drop on somebody's head if they don't follow the core architectural principles…it's called governance.

To take a step back I really like articles that challenge the ideals of a practice. For me there are some themes in the article that make a lot of sense. These include:

  • EA Viability - If EA is broken evaluate if you should really continue it?  Sometimes the answer is yes, sometimes the answer is tweak, augment, enhance, etc.
  • Architecture Governance- There needs to be "teeth" in architecture development processes. I can't emphasize that enough. However, what I do disagree with is the "traffic cop EA" or "dropping the hammer". That isn't productive and ultimately pushes teams away from EA. Let the auditors and compliance guys do that.
  • EA Authority - EA's have no budgetary or referential authority thus no results. I agree with the first bit but not the second. I can speak from experience that I was able to effectively change the organization by not having direct reports nor a budget. I was a trusted partner and a technology enabler. From a senior management perspective my job was to keep the company out of the Wallstreet Journal. This was attractive to LOB CIOs and above. But the common architect working on SOA activities valued EA's because they could help validate their thinking, mitigate risk and help with the design.
  • Validate the need for EA - "Perhaps it's time to send a message, and pull the plug [on enterprise architecture]. At least that will drive some change." I wanted to highlight this message because I think if EA isn't working for you, try living with out it for awhile. See if you revert back to that thinking or if there are business or technical drivers lead you back.


One last comment that I will make is that architecture in general is maturing. This is in the definition of what architecture is, the process in which we derive to an architecture and the role of an architect. With standards bodies such as the OpenGroup  we are seeing a 230 percent increase in certifications and 50 percent of permanent IT jobs in the U.K. include TOGAF as a required skill set. This was a survey done by ITJobsWatch this year.

So even though I feel that EA is a great practice to have it's not for every organization.  EA is a hard thing to do and most organizations iterate through several different models before they get it right. There is nothing wrong with that. At the end of the day you are tailoring it to your business needs. And if you do not need EA do not do it for the sake of doing EA. This is true of other processes like Six Sigma, ITIL, etc.

Thanks David for asking the hard questions and for your candid observations. Great stuff!


Tags: Enterprise Architecture

Comments (4)

  1. natty gur says:

    I think that one of the biggest issues around EA is the learning curve. it simply takes a lot of time to learn how to do this kind of job (it doesn’t matter from which background you’re coming, you always need to learn new skill set) and it takes a lot of time until you have solid holistic view of the enterprise. Based on this knowledge you can contribute a lot (like changing the way the enterprise organize it data, which brings to huge business success. You can imagine what the perception of EA is after such success) but it simply takes too long to reach it. the problem is that there aren’t any shortcuts here.

  2. MSDN Archive says:

    Hi Natty,

    Yes skill set is  a big part of it as well. As a practicing EA I always would run into folks that wanted to be an EA or an architect in general. Many times we say you must know how to fill in these templates or know this domain of knowledge. I think think that approach may be flawed. We should be looking at both experience + skill set. Taking more of a competency approach I feel is much better.

    The issue I see is that we should have a standard curriculum for architects (like with any other field). It’s still the "Wild West" in IT.

    to be the devil’s advocate here, I think that there isn’t one major issue it a combination of several issues. The what is EA and how should I do it is a big concern. But if you know how to do it and you organization is buying in to it, that is a completely separate issue.

    Great points and thanks for commenting Natty.


  3. natty gur says:

    Hi Mike,

    I agree about standards and from my own point of view they are part of the skill sets that I talked about. Although I think that standard might be useful I don’t think they are mandatory for success. let’s face it the success of each and any project is depend on the personality of the guy who runs it. even if we’ll have standards and same skill sets part us will manage to run successful project and part of us will fail (the same as any other standardized industry).

    I guess that the point that tried to emphasize is "we need to invest in people (the who) to get enterprise architecture (the what)"

    For your last point, what is EA and how should I do it is really big concern. But I guess that what is EA, impact the complexity of what you have to do.

    I would start from agreement on the term architecture, since I already saw that different people have different perception of this term. After having agreement on this term I would move forward to "enterprise architecture".

    I see architecture and set of principles, constraints and blueprints that define "what, when, where, why, who and how a given work should be done.  

    let’s observe those two legitimate EA definitions: "holistic view of systems architecture from enterprise point of view" or "holistic view of business, information, systems and technology (taming the BIST)". it’s clear that the first definition of EA require less (Knowledge, experience, skill set, soft skills, standards, etc’) then the second definition. This should impact the way that we implement each one of t hose definition. For example, I would be much more concerned from agility in the way that I’m going to implement the second definition (without the ability to do it in agile way and to show benefit out of this work quickly and  repeatedly, it will be simply doomed to be stopped by management)

    so if there is diversity in the term of EA and in the way that we’re doing it, should we really concentrated on those issue. Isn’t it better to focus on toolsets (including standards) that will help our community to do the work that each enterprise expects (differently) from us?

Skip to main content