• Blog
  • About
  • Archives

elemental links

brenda michelson's technology advisory practice

A couple of thoughts on ‘Why Enterprise Architecture is a Joke’

June 12, 2008 By brenda michelson

A couple of weeks ago, Jeff Schneider wrote a post entitled Why Enterprise Architecture is a Joke.  Jeff’s point wasn’t to ‘pick a fight’ but rather to point out some troubling issues associated with the practice of enterprise architecture:

1. Zachman pioneered, than stagnated. I believe that the single largest reason that EA is a joke can be linked back to the pioneer. This pains me to say, but many in our industry were patiently waiting for better stuff to come from Zachman and it just didn’t happen.

2. Bad Application Architects got promoted to be bad Enterprise Architects. Although this isn’t a universal truth, I’ve witnessed my fair share of it. Those who can’t architect do PowerPoint.

3. Silo Organizations promote Silo Funding. Many EA’s never had a chance. They live in organizations that fund everything according to business silo’s. Then, the EA is expected to bridge the silos with nickle and dime funding. Their inability to perform Herculean change (multi-channel, master data, cross-organizational BPM, master SOA services) has many of them designated as cops with no gun, just a good flashlight.

4. The Tooling Sucks. Modern EA tooling is complete pile of crap. It is designed and written by a generation who is out of touch with the needs of modern I.T. groups.

5. Unconnected Models. Expanding on #4, our models (and tools) do not sufficiently flow from one model to the next. Software development is often explained as a series of model transformations from concept to design to construction, where each stage adds additional fidelity. We currently have a huge hole between EA and the downstream constituents.

In the intended (non-combative) spirit of Jeff’s post, I’m going to add my 2 cents.

EA Frameworks

Similar to James’ response, I don’t often run into enterprise architects in commercial organizations that use Zachman.  Certainly, almost all EAs are aware of Zachman, and appreciate his foundational work.  But, many have come to the conclusion that Jeff has, the Zachman framework isn’t enough.  It does provide a good frame to orient thinking, but producing and classifying documents does not make for an enterprise architecture.

Of course, this isn’t just an issue with Zachman, most enterprise architecture frameworks are artifact centric.  As if producing the right documents and policies alone will result in a high performing, low technical debt, business aligned IT organization.

If you want an actionable enterprise architecture, you must go beyond artifacts.  You need to create the environment (business capability to architecture strategy matches, architecture platform, portfolio planning & management, governance, talent development, etc) and relationships (business, IT leadership, delivery teams, operations teams) that directly contribute to the delivery of business capability.  As I’ve said before, a sure way to failure is to view your architecture as an end, rather than a means.

Conflicting Measurement

Another I problem I see, that relates to Jeff’s “cops with no gun, just a good flashlight” metaphor is the disconnect between EA Governance and IT Leadership.  EA teams are charged with policing delivery projects for compliance to the architecture.  Among other things, compliance to the architecture should result in risk mitigation, investment productivity over time, business flexibility, reduced technical debt and skills optimization.  However, many IT organizations (and their leaders) are measured on shorter term, operational aspects, such as on-time, on-budget, up-time, risk mitigation, etc.  Given that people perform in accordance to how they are measured, regardless of the bigger implications, IT Management often trumps EA Governance to ‘get the thing in’.

These, seemingly arbitrary, bypasses of the enterprise architecture contribute to the ‘EA has no teeth/backing’ (is a joke) perception.  While there are valid business reasons to give some projects a pass, it needs to be handled in a structured manner, as a waiver, accompanied by a plan to bring the assets into compliance, limit their proliferation and/or schedule their disposal.

While the waiver provides a formal acknowledgement that the project is out-of-compliance, enterprise architects can’t stop there. EAs need to educate IT management, delivery and operations teams on the value of enterprise architecture. And, during those conversations, EAs must listen to the needs of their constituents, in order to create a relevant, actionable enterprise architecture.

Share this:

  • Click to share on Twitter (Opens in new window)
  • Click to share on Facebook (Opens in new window)
  • Click to share on LinkedIn (Opens in new window)
  • Click to email this to a friend (Opens in new window)

Filed Under: business-driven architecture, enterprise architecture

Brenda M. Michelson

Brenda Michelson

Technology Architect.

Trusted Advisor.

(BIO)

  • Email
  • LinkedIn
  • RSS
  • Twitter

Recent Posts

  • Experts Sketch
  • PEW Research: Tech Saturation, Well-Being and (my) Remedies
  • technology knowledge premise
  • The Curse of Knowledge
  • better problems and technology knowledge transfer

Recent Tweets

  • Harshest editorial feedback I ever received “stultified and like death”… (wildly popular paper, as it turned out):… https://t.co/qWNwBCOS5i February 28, 2023 2:16 pm
  • “…where the process of drawing itself can take us. We can follow a suggestion, a squiggle, shadow, or smudge, and s… https://t.co/oRg0x2LoXG November 30, 2022 5:05 pm
  • On the waiting list for Post, join me (on the waitlist) via https://t.co/U8wYK707f6 November 24, 2022 4:17 pm
© 2004-2022 Elemental Links, Inc.
loading Cancel
Post was not sent - check your email addresses!
Email check failed, please try again
Sorry, your blog cannot share posts by email.