Architecture Maturity February 25, 2010
Posted by mdereszynski in Architecture, Enterprise Architecture.trackback
What is the best measure of your Enterprise Architecture groups maturity? Is it best measured by an industry standard such as CMMI or one of the analysts maturity models? Should you pay a consulting firm to tell you how effective your EA is? I think the measure of your EA effectiveness should be how much influence your group has in driving business change.
The Center for Information Systems Research (CISR) at MIT along with The Boston Consulting Group surveyed CIOs at 104 firms, only 33% of the CIOs rated their senior executives as effective at driving value from IT. What’s worse is that only 40% felt like their executives could successfully prioritize the investments in IT! This kind of data to me shows that the majority of IT departments are not in touch with the business priorities or even the challenges facing the organization.
How do you turn this around? How does a company realign it’s IT department with the company goals without throwing out the organization and starting over? Well first, the IT organization must recognize that there is a problem and identify wherein the problem lies. To determine where the root cause of this lack of influence is not very easy. But we can look at the kinds of things that a mature EA group does and then assess the enterprise against these. Once we have decided where in the maturity you would like to then make a plan to get your group to that level.
- Mature Enterprise Architecture Organizations have appropriate stakeholder support.
- Valuable Enterprise Architectures have a reference which is based on business context
- Effective Enterprise Architecture Organizations have the right scope and authority.
- The very best EA Organizations have the right team members.
Stakeholder Support
This is number 1 on my list because it is impossible to execute on the other three priorities without buy-in and participation from senior/executive members of the organization. Additionally, it is impossible to continue to get the right level of stakeholder backing if the EA is ineffective.
Stakeholder involvement must start from the top, CIO at least and probably even one step higher. The business must understand that for the IT organization to be effective at all, it must be able to plan and strategize the technology investments which are in lock-step with the business plan. Without this plan, the IT organization is simply guessing at where the business might be headed. IT organizations never get out of “order-taking” mode.
Nearly as important as having executive stakeholders is having the support of the directors and IT managers which are responsible for executing the architecture. Having the best architecture which lays out a consistent vision for the future is useless if the engineers who are required to build and support these systems can’t execute or don’t understand the intent. It is the responsibility of Enterprise Architects to share the vision and describe the architecture in a way that both ends of the spectrum (business and IT) understand.
Reference Architecture
I don’t put much faith in writing reams of documents which describe the current state of an environment or even in plans to improve. I take the path of least resistance approach, which should be clear from nearly all my writing. A reference architecture though is one of those key pieces of documentation that I always insist on. The reason I insist on having a reference architecture is that when it is done correctly, it can be the basis for many other valuable exercises. The reference architecture which describes the business capabilities rarely change (in most companies less than once per 12-18 months) and when it does it is usually very modestly, never drastically.
Good reference architectures have a solid business context which are used to describe how technology changes affect the business as a whole. They provide a basis for making strategic plans based on real data showing underperforming business functions and IT capabilities. Simply having a reference architecture of your current product set or IT capabilities doesn’t provide the long-term value of an architecture which has a business context.
Scope and Authority
Now let’s set something straight here first – I’m not an advocate of turning your Enterprise Architects into the IT police. I have seen that in order to establish their effectiveness, some EA organizations start by requiring that all solutions are reviewed by this organization, all business interactions must include this group and/or all purchases are reviewed and blessed by this organization. This is not the right kind of scope and authority in my opinion. It simply is not scalable in an organization of more than a few hundred employees. But on the other end of the spectrum, the EA shouldn’t have to secure Executive orders to ensure consistency in delivering solutions to the business either.
In my experience, Architects are much like consultants in terms of growing authority and scope. Two key aspects are relevance and credibility. Architects that guide the way and show the path of least resistance are much more effective than those architects that use the ban-hammer to keep engineering teams in line. In order to gain this trust architects need to demonstrate the patterns they want followed with real business solutions. This has two advantages, first it keeps Architects from becoming technology geezers (out of touch with real world issues) and secondly, reliable and consistent solutions come naturally because they it is always simpler to follow an example than to blaze a new trail.
The Right People
This here is currently the most difficult aspect of maturity to improve. Effective architects have a complex array of personality, technical skills and vision. Although many of these qualities can be learned (see my post on Becoming an Architect), not many people exist who will exhibit these characteristics. Most EA organizations are going to be forced to settle for a less-than-optimal ratio of excellent architects, good architects and aspiring architects. The best EA organizations are going to recognize which technical and business people have the right stuff and they will ensure that they have the right motivation, coaching, training and mentoring to become the organizations premier architects in the future.
I’ve waxed poetic about this before as well, but finding and encouraging your organization to adopt a standardized method to judge the quality of your architects can help to identify gaps in your talent pool and building a plan for advancing the profession. Most organizations will have definitions for the profession, but relying on trusted industry certifications will make the job of finding and hiring talent simpler and more reliable. IASA is a great vendor/framework agnostic organization that is focusing on promoting the profession of architecture and has recently begun the process of certifying professionals that exhibit the very best talent in the world. What’s more, this organization can provide a social network of architects from which to choose when you look to expand or mature your EA team.
[...] a story I can remember. I’ve talked about this alot in other posts (here, here). Architects are story tellers. They tell stories to business users to describe what [...]