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

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
naki357
50%
50%
naki357,
User Rank: Apprentice
4/30/2014 | 4:53:06 PM
re: 8 Reasons Enterprise Architecture Programs Fail
Hello Chris, 

 

Nice article.  I think you touched on a lot of great points here.  I had written a somewhat similar piece about a week ago, with a focus on barriers to technical innovation in the large enterprise. Some of the failures I noted are directly attributed to poor Enterprise Architecture at a systemic as well as individual contributor level.

Here are a couple of my thoughts on common problems:

1) The "No" Man Enterprise Architect.  

It's much easier to say "no" to advocates of innovation rather than research whether a new technology or solution is viable for the given situation, as well as compliant with enterprise regulations.  This "No" Man never actually realizes that it's his job to research new technologies, build proofs of concept, and constantly re-invent himself. He just rejects anything that comes across his desk without lifting a single finger of due diligence.

2) Overly-centralized Enterprise Architecture

Overly-centralized EA will allow your organization to fall years behind on hardware and software upgrades because it's too hard or expensive to test something new on all applications across the enterprise, or determine whether all aspects of it fall within corporate standards and practices (which are inevitably many years out of date).  I believe that a Federated model of EA works very well to combat this issue.

3) Outdated standards and practices

Beliefs such as:

"Oracle is the only robust, high-performing database for the enterprise"

"The Cloud is not secure"

"We don't use Javascript frameworks"

Far too many organizations are making decisions based on assumptions that are completely unfounded or were only true 5-10 or more years ago. 

My whole article "The 12 Barriers to Technical Innovation in the Large Enterprise" is available if anyone is interested in having a read. 
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 - September 2, 2014
Avoiding audits and vendor fines isn't enough. Take control of licensing to exact deeper software discounts and match purchasing to actual employee needs.
Flash Poll
Video
Slideshows
Twitter Feed
InformationWeek Radio
Archived InformationWeek Radio
In in-depth look at InformationWeek's top stories for the preceding week.
Sponsored Live Streaming Video
Everything You've Been Told About Mobility Is Wrong
Attend this video symposium with Sean Wisdom, Global Director of Mobility Solutions, and learn about how you can harness powerful new products to mobilize your business potential.