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”.
- 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.
- 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.
- 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.
- 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.
- 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.”
- 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.
- 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.
- 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.
- 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.
- 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.
