Government // Mobile & Wireless
Commentary
3/26/2013
10:55 AM
Imre Kabai
Imre Kabai
Commentary
Connect Directly
RSS
E-Mail
50%
50%
Repost This

8 Reasons Enterprise Architecture Programs Fail

Successful enterprise architecture programs marshal the right people, support structures and approaches -- and dispense with the distractions.

Google's 10 Best Gags, Pranks And Easter Eggs
Google's 10 Best Gags, Pranks And Easter Eggs
(click image for larger view and for slideshow)
"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 CIO
Global CIOs: A Site Just For You
Visit 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.)

Comment  | 
Print  | 
More Insights
Comments
Newest First  |  Oldest First  |  Threaded View
AdrianGrigoriu
50%
50%
AdrianGrigoriu,
User Rank: Apprentice
4/15/2014 | 9:40:43 PM
the 8 reasons can be reduced to one
The key reason is that the EA is not scoped properly as the enterprise wide rather than the IT architecture. All other failure reasons derive from this.

Because

EA is reporting into IT rather than high enough in the hierarchy to make an impact.

It is not sponsored by the business but by IT.

It works in an ivory tower with regard to business with little non-IT audience.

It employs an IT architect, who may not have the right range of skills, that is it employs the wrong person.

There are no proper enterprise wide EA approaches. Those that exist are either ontologies (Zachman) or development processes (TOGAF) rather than EA frameworks. Hence many cling to one of them in the hope that the outcome is an EA. It isn't.

The EA team is policing developments in IT, creating perhaps cultural issues, without generating the EA blueprint that would embedd the compliance in processes and make unnecessary the policing. But the team has no other method to get results, except if they invent their own.

www.enterprise-architecture-matters.co.uk
ChrisMurphy
50%
50%
ChrisMurphy,
User Rank: Author
3/27/2013 | 5:18:11 PM
re: 8 Reasons Enterprise Architecture Programs Fail
I've spoken with CIOs driving digital business initiatives who emphasize how important the enterprise architect role is in that change effort. The architect discipline translates directly to many of the needs in digital marketing initiatives, for example.
Register for InformationWeek Newsletters
White Papers
Current Issue
InformationWeek Government, May 2014
Protecting Critical Infrastructure: A New Approach NIST's cyber-security framework gives critical-infrastructure operators a new tool to assess readiness. But will operators put this voluntary framework to work?
Video
Slideshows
Twitter Feed
Audio Interviews
Archived Audio Interviews
GE is a leader in combining connected devices and advanced analytics in pursuit of practical goals like less downtime, lower operating costs, and higher throughput. At GIO Power & Water, CIO Jim Fowler is part of the team exploring how to apply these techniques to some of the world's essential infrastructure, from power plants to water treatment systems. Join us, and bring your questions, as we talk about what's ahead.