Is Enterprise Architecture even worthwhile?

Give me the elevator pitch
Someone once told me that if it takes you more than a minute to explain what you do, then you must be a consultant or a liar. Or both.

I think in the EA space there is often a lack of clarity around some of the things we do. And it isn’t just our customers that don’t get it.

There was a LinkedIn group discussion that asked those commenting to explain what EA was in 160 characters or less.  Many results were predictably vague and consultantese-y. Some were more spot on and concise. But the question I asked myself at the time was why do we need to define this? We don’t have similar challenges to define Application Development. Why is that?

Quite honestly, it is because everyone knows what appdev does. They understand the value appdev provides. Even folks in EA sometimes struggle to articulate what they do, what the value is that they provide. Consulting firms make millions helping folks with strategies to describe, highlight and demonstrate that value. How can it be that years and years into the maturation of Enterprise Architecture we still have problems telling the business why they need us?

You need data, man
I don’t think we measure enough. Of course that statement would have killed me to say a couple years ago when the notion of perpetual measurement bureaucracy gave me palpitations. But the fact remains, we don’t measure the right things, with sufficient frequency to give us a picture we can use to show how valuable EA really is.

So how does a fledgling EA group (or one on the ropes) gather that data and generate their value proposition in a clear, concise manner? What, exactly, should they be measuring to demonstrate the benefits of their trade?

You could always Google the question and find a plethora of information. I happen to think this presentation is the best on offer regarding the subject. But if I were to boil down what I have seen and experienced, and this isn’t rocket science, it would come down to this:

Compare programs that follow EA processes to those that don’t and measure the differences. Metrics would include:

• Cost based on resource utilization (hardware, software, human)
• Time/labor cost benefits
• Project failure rates
• Defect rates
• Time-to-market
• Architectural risk
• Customer satisfaction with solution
• Alignment with corporate strategy, vision and goals
• Alignment with program’s business requirements
• Artifact reuse rate

If you lack the means to identify, gather and report these metrics, odds are your EA program is going to fail. The reason is that nobody knows what we do and can’t point to any concrete (i.e. dollar denominated) benefit. Sure the CIO/CTO knows he needs to ‘do EA’ because he reads about it all the time and his competitors are doing it. Most of them, however, would kill for a mechanism to demonstrate to the business that IT isn’t just a giant black hole sucking up all available revenue (well, not the EA part of IT at least).

These are tough times. Hope you last
Folks in charge are looking at ways to save money, streamline operations and enhance the value derived from the various segments. Gather your data. Analyze it. Put it in a live web-based dashboard. Market the hell out of it. Suddenly EA is recognizable to everyone as the money-saving strategic operation it really is (even if they STILL can’t really explain what you do).

Disagree? Too simplistic? Too obvious? Argue with me! I love it!