8 Reasons Enterprise Architecture Programs Fail

Google's 10 Best Gags, Pranks And Easter Eggs

"If you want to build a ship, don’t drum up people to collect wood and don’t assign them tasks and work, but rather teach them to long for the endless immensity of the sea." -- Antoine de Saint-Exupery

Enterprise architecture was conceived some 25 years ago to address the increasing complexity of IT systems and their poor alignment with business goals. The same problems still exist today, amplified by the accelerating pace of technology change.

Why is it that EA programs are more likely to fail than succeed? Here are eight typical failure modes, followed by recommendations on how to avoid them.

1. Lack Of Sponsorship.

Your architects need three tools to do a good job: access, leverage and goodies.

[ Change your life or career or both with better decisions. Read 7 Ways To Improve Your Decision Making. ]

Access means the ability to interact with the appropriate stakeholders, often at the C-level.

Leverage includes the right place in the reporting chain, involvement in governance, ability to influence the technology budget, and authority to stop inappropriate technology implementations. Sometimes even the seemingly small change of a title from technical architect to chief enterprise architect can make a significant difference.

Goodies include the ability to give out new technologies for testing, "lend" technology experts to struggling projects, and get access to exclusive information that can be traded for favors.

Global CIOs: A Site Just For YouVisit InformationWeek's Global CIO -- our online community and information resource for CIOs operating in the global economy.

Well-sponsored architects will be able to build trust by consistently delivering meaningful results. Lack of sponsorship will destine even the best architects to fail.

2. Hiring Or Promoting The Wrong Person.

The skills that earn someone the EA position don't necessarily make the person a strong EA. Often the most technical people get promoted when they lack other important skills. These include interest in the business, the ability to translate technology into simple business outcomes, and the ability to listen, communicate, present and market infectious enthusiasm for new technologies.

3. Building An Ivory Tower.

Some EA programs hire a bunch of brilliant architects who retreat for a long time and return with sophisticated frameworks. They then present them to key members of the leadership and the organization, most of whom will have no clue what the architects are talking about, so their complex reference architectures will be ignored.

Ivory towers tend to increase the complexity and upset the stakeholders. The new CIO will gain immediate recognition among his business partners by firing the EA team, with the result that enterprise architecture becomes a "bad word" deeply embedded in the institutional memory. Roger Sessions wrote a great white paper on driving simplicity through connected enterprise architecture.

4. Policing And Insensitivity To Culture.

I have seen a project manager burst into tears in the crossfire of enterprise architects' questions during a technical design review. I have been on a 2 a.m. call struggling to comply with unreasonable and obsolete technology standards just to get the chief architect's signature and meet the budget deadline.

In that particular case, the turning of enterprise architecture into a policing function resulted in its failure. It takes a lot of effort to convince, and regularly re-convince, your business and IT partners of the value of enterprise architecture. A gentle approach makes the function more likely to succeed. The best architects I've known spoke softly and carried a really big carrot. They followed Exupery's advice.

5. Maintaining The EA Artifact Factory.

Some EA teams keep busy documenting as-is states. They have an incredible array of diagrams at their disposal to represent the various aspects of everything. The world of diagrams is addictive, and perfect is the enemy of good when it comes to diagrams.

Instead, these teams should focus on producing frequent, meaningful and measureable business outcomes.

It isn't easy to come up with good KPIs to measure enterprise architecture. This GAO report clearly shows the challenges of defining good EA metrics in the government sector.

6. Clinging To A Particular Framework Or Tool.

There are more than 80 EA frameworks, and you'll find no silver bullets among them. The best approach is to read all of the major frameworks, discard most of what you have learned, and blend the remaining 10% in a way that fits your organization's culture, maturity and business goals. As an example, here's a lightweight, blended approach for tree huggers. When it comes to tools, go fancy if you have the money. But most of the time fancy isn't necessary. Visio, Excel, Word, FreeMind, Prezi and a collaboration team site works well. Limit the time spent on selecting tools and frameworks and instead focus on using them.

7. Thinking Enterprise Architecture Equals Technology Architecture.

Most EA programs are initiated by IT and never progress beyond the technology domain. Although technology standards, technology roadmaps and solid engineering practices will produce simpler, cheaper, portable, reusable and more supportable solutions, they don't align your IT investments with business goals and won't power your business with technology innovation.

8. Taking The "Enterprise" Word Literally.

"Enterprise" does notnecessarily mean the entire enterprise. It means stepping back and taking a look at the higher-level context before making a decision. Moving architecture to the real enterprise level requires a mature and committed organization. If you try to push the enterprise aspect too far too early, you'll crash and burn. Mike Rollings of the Burton Group has a great article on this subject

Recommendations:

-- For the sponsor of the EA function: Make sure that your organization is ready for an architecture-driven approach and that the EA function is well sponsored. When you interview EA candidates, ask about the failure modes of the function. Keep looking if the person doesn't know the usual failure modes by heart.

--For the EA: When you interview for a new position, make sure you have what it takes to do a good job. Take into account your own abilities, the company culture, the level of organizational maturity and the level of sponsorship. If you're uncertain, walk away. Life is too short to spend years making no difference.

Two tech experts square off. A CIO compares working without IT standards to anarchy, while a CTO claims that standardization stalls creativity. Also in the new, all-digital The Standardization Debate issue of Network Computing: Next-gen data centers and the politics of standards. (Free registration required.)