The Top 10 Enterprise Architecture Mistakes

This past week I found a very interesting piece of guidance from the  Gartner Enterprise Architecture Summit 2009. I was planning on writing a piece like this myself, but thanks to Scott Bittler, he has made my job a lot easier. 

Scott Bittler, a research vice president at Gartner, says that “The key for enterprise architects is to create not the perfect or most elegant architecture for the moment, but the most adaptable architecture for the future. EA is a challenging discipline and careful attention to the basics can mean the difference between failure and success. Avoiding the pitfalls in the first place is much easier than climbing out of a hole you’ve inadvertently tumbled into. Applying the ways to avoid these pitfalls results in achieving EA benefits faster and reduced risk of programme failure. It will also improve the credibility of IT among business leaders”.

1. The Wrong Lead Architect: Gartner identified the single biggest EA problem as a chief architect who is an ineffective leader. He or she may understand EA well but has ineffective leadership skills that even a good organisational structure and staffing levels cannot overcome. Gartner recommends that such a lead architect be replaced by someone with strong ‘soft’ skills such as enthusiasm, communication and passion, as well as being well respected and strategically minded.
2. Insufficient Stakeholder Understanding and Support: This happens when employees outside the EA team don’t participate in the EA programme, EA content is not used in projects and management questions its value. Gartner’s solution is to make EA education and communication a top priority to secure executive-team sponsorship. “The key is to ‘sell’ first and architect later,” said Mr Bittler.
3. Not Engaging the Business People: When IT and business goals are not aligned, resultant problems include non-technical people trying to make technical decisions while enterprise architects become too reactionary and tactical in response to projects. To overcome this, Gartner recommends that enterprise architects get involved in the development of the business context and engage jointly with other employees in the business architecture.
4. Doing Only Technical Domain-Level Architecture: This dated EA approach is still in use in some organisations and is even narrower in scope than technical architecture. Holistic EA best-practice is much broader as it includes business, information and solutions architecture.
5. Doing Current-State EA First: Successful EA provides prescriptive guidance but current-state EA does not, so it delays delivery of EA value and hinders the creation of good future-state EA. “The temptation is often to do the easy – current-state – EA first,” said Mr Bittler. “Instead, establish the business context and then focus first on future-state EA.”
6. The EA Group Does Most of the Architecting: This is a pitfall because the EA content is typically off the mark as it was not informed by those on the business side. There is also consequently no buy-in for the EA. The primary job of architects is to lead the EA process rather than impose EA content on the organisation. They should form virtual teams to create content and seek consensus on the content.
7. Not Measuring and Not Communicating the Impact: The value of EA is often indirect, so it may not be obvious to everyone in the organisation. This then exposes the EA programme to risk of failure. Gartner recommends that enterprise architects create a slide to demonstrate each success story of EA applied to a project. They should include measurement and documentation of EA in the programme plan.
8. Architecting the ‘Boxes’ Only: Enabling better business agility and integration is key but architecting standards for the ‘boxes’ (business units) in process, information, technical and solutions models doesn’t address this. Integration and interoperability standards are high EA priorities and must account for more than just technical architecture. Architects should focus more on the links between the boxes.
9. Not Establishing Effective EA Governance Early: Enterprise architects must resist the temptation to wait for more architecture content before setting governance processes and instead develop content and governance in parallel.
10. Not Spending Enough Time on Communications: Key messages about EA are not intuitively obvious, so enterprise architects must work to educate the business. It is critical that organisations develop and execute an EA communications plan with messages tailored to each audience.

These are all really great points. Since Scott did a great job of articulating these I only have a few comments:

On item #1 with regards to leadership, I believe that this is critical as well. I have personally have observed very smart and talented Chief Architects not be as successful as they really could be with their programs. Often times as a result the EA team disbands or reorganizes. While I do agree that the soft skills defined are important (enthusiasm, communication and passion, as well as being well respected and strategically minded), I think there are other aspects are critical as well. 

• Must be able to Sell EA. Not the used car salesman version but truly be able to articulate the value in terms that everyone at the decision making table understands. 
• Chief Architects must be pragmatic. It is easy to over-archtiect / engineer things like governance, process, standards or solution architectures. Understanding what is realistic and achievable at a given time (based on many factors of the organization) will ensure greater success and adoption by the organization.
• "Think Strategically but Act Tacitly", remember that as you make your decisions. The audience, organization or even your technical capabilities within the organization may not be ready for your more advanced thinking. Like in chess, make sure you have a direction but check mate is always several moves ahead.

I look at item #2 , #7 and #10 as part of the same overall strategy. Chief Architects must be able to foster communities in the enterprise. These communities will be the drivers behind the destiny of the organization, not EA. Enterprise Architecture is the facilitators, providers of non-bias opinions (ideally), check points for other enterprise considerations, etc. This is a key input into the governance processes that will be enforced. The result will be an organization that is behind governance because they helped create it. 

Another piece that will ensure success for Chief Architects is building a communication plan. While communication was explicitly called out with the great advice on tailoring your message, I would include a few more considerations that will add a positive impact on your communications:

• Frequency, communicate often! You can never over communicate the successes and tangible impacts to the organization. 
• Transparency, not only should you communicate often but also communicate as much as you can, even if the artifacts you are creating are in draft. Items to communicate: architecture decisions, architecture review board artifacts, solution architectures, technology life cycle roadmaps and decisions and governance materials.
• Feedback loop, make sure there is a feedback loop and ensure that it is heard. I have observed this time after time where architects or developers say they don;t have a voice or do not understand why a particular policy exists. Provide a feedback loop so they can ask questions, challenge and debate openly with EA. 

On item #4 with Enterprise Architecture only preforming IT Architecture... I agree with this in theory, but with this one, it really depends. It depends on so many factors that I would rather talk about it in another post rather than here. But very simply through my discussions with other enterprise architecture organizations is that most companies are just not ready or understand the need to do this. The overwhelming number of organizations I have spoke with over the past two years have EA reporting to either the CIO or CTO (and there are even some below those). In this model there a so many organizational challenges to overcome. If companies where truly ready for this, these companies would have the office of enterprise architecture report to the CEO directly. Other factors here are maturity and general understanding of what value EA provides. 

I would agree with this if the organization has a mature EA capability but if the company is new to EA, no dice. 

Item #5 talks about not doing current state first. I agree whole completely here. But at some point you will have to do analytics on what you have. Instead of "boiling the ocean" on all of your IT systems, pick only a few of your mission critical ones and start there. The goal here is to focus on the most important systems as they will yield the most return on investment.

Item #8 is talks about boxes and lines that us architects create. I agree we have spent a great deal of time on the boxes and haven't shown the same attention to the lines. I heard this loud and clear at the Gartner EA Summit last year from Brian Burke. I personally don't discriminate against lines but I see how it can happen... 

Item #9 is a bit lite for such a broad and important topic such as Governance. What I will say here is that I agree with Scott on this but a few more qualifiers need to be in there for me. First, Just In Time Governance (JITG). I agree we shouldn't let analysis hinder us from setting up necessary governance areas that are industry standard that EA knows will add value but we need to be careful at what level we implement. This is a delicate balance and again depends on where you are at in the maturity curve. I would love to see Gartner or Forrester put together a matrix that puts this into more context based on organizational dynamics and maturity. 

Like I said before, Scott did a great job here with compiling his thoughts on the Top Ten EA Mistakes. Scott, if your reading... please comment and let me know how far off I am from your intent or thoughts. I wouldn't mind hear back from you on this.

Comments

[Kevin Lee Smith]

How about these top 19 EA risks?

1) “It’s a Silver Bullet”
EA is perceived as a perfect fix for all of an organisations problems, with little or no work or cost.

2) “Nothing to do with me mate”
EA is perceived as an IT or technology level thing.

3) “…how much?!!!”
EA is perceived as large, costly and slow. EA is perceived as a huge Initiative to immediately move the enterprise from Current to Target with associated huge costs and timescales.

4) “Are we there yet?”
EA is perceived as a destination rather than a journey, and/or as a deliverable rather than a process with deliverables.

5) “…I have important fire firefighting to do...”
EA is perceived as a roadblock to more important and immediate problems such as “getting the car out of the river”. EA is perceived as purely long term & strategic and not capable of adding value in a tactical world.

6) “We don’t live in a perfect world”
EA is perceived as ivory tower, academic and theoretical and is only applicable if we lived in a perfect world

7) “Oh what pretty pictures”
EA is perceived as creating static “pretty” pictures that hang on people’s walls but not used by anyone.

8) “You tool!”
EA modeling tools are perceived as expensive and “nice to have” but not mandatory.

9) “I don’t want another maintenance nightmare”
EA models are perceived as being owned and updated by IT

10) “How many paperclips do we have and who is using each one”
EA is perceived as producing Models with huge amounts of detail and will descend into analysis paralysis.

11) “It’s something Consultants invented to get more money”
EA is perceived as of no use and will only cost money for no benefit.

12) “Do You Know, Where You’re Going To….”
EA is perceived as not being able to define a Future state because no one knows what that is and its always changing anyway.

13) “Techy, techy”
The perception is that because EA contains the word architecture it must be all about IT and nothing to do with the business.

14) “Daddy knows best”
he perception is that IS is dictating to the Business.

15) “Mummy knows best”
The perception is that the Business is dictating to IS.

16) “Model This!”
Feverish modeling of various things without a plan for how to gather the data, how to QA it, and who will benefit from it once it is gathered.

17) “Don’t mention the war - I mentioned it once but I think I got away with it!”
EA is driven in a largely covert manner, It is only known of within IS and even then only to a very select few.

18) “Bonuses for Failure!”
Executive incentives reward short term investments and reduced acquisition costs.

19) “It’s my ball and you can’t play with it!”
Commodities such as servers, databases, storage and Integration are bought and managed in a piecemeal fashion.

The full document defingin these with Impact, Reality and mitigation Strategies is part of Foundation section of PeaF and can be found here http://www.pragmaticea.com/peaf0-foundation.htm

[clearconceptualthinking.blogspot.com]

Hi Kevin,

great stuff. I just discovered you, but this article of yours will be on my favourites list right away!

Cheers!

Rolf

[Bruno Thiel]

Well done Rolf and Kevin. I might add:

> Trying to implement an EA as part of a transformation program that is already being on its way.

"Oh and by the way, we should define an EA and governance structures for this transformation program". - Too Late, too little time.