There are several definitions of enterprise architecture (EA) maturity. Many — if not most — are modeled on the Capability Maturity Model Integration (CMMI). Perhaps because the precise definition of maturity levels (not to mention the number of levels) vary between versions of enterprise architecture models, most enterprises find themselves setting their own levels a little higher and a little sooner than would seem practical for their intended models.
Whereas the CMMI has five stages of maturity, a compact model could have only four (Initiated > Defined > Measurable > Optimized) and still be recognizable as the same idea. The US DoC ACMM Framework as referenced by TOGAF has six stages because it starts at Level 0 (none), which could be interpreted as a sincere approach to incorporating the real world into the model. For models that start at stage 0, the first stage is the decision to pursue an enterprise architecture and architecture maturity. Models that start at stage 1 both create architecture maturity as a byproduct and pursue it as a goal.
In this article, I will identify some assumptions based on the goals of an enterprise architecture strategy and consider how those assumptions map to the reality experienced in various enterprises.
How Most Enterprises Measure Architectural Maturity
Most enterprises use some kind of scoring system to measure their progress along the path to architectural maturity. The United States Department of Commerce’s DOC ACMM v1.2 contains a scoring system that is clear, concise, and consistent. It has six levels, each measured in nine areas, and a summary scoring system that boils it all down to a scale of 1 to 5.
The number of levels, areas evaluated, clarity of the evaluation system and scale used to measure the current level of architectural maturity can vary greatly from one enterprise to another when examined at a detailed level. Still, when considering the high-level definitions of what maturity means (and enterprise architecture is a high-level discipline), the variations then appear to be fairly minimal.
The scale begins either at the enterprise architecture being non-existent or at the best guess of the current state of the enterprise architecture. The levels then move up the scale to some desired end state. The goal is to place a marker along the path to architectural maturity that states “We are here.”
With such a relatively clear understanding of the architectural maturity path and where it will lead, the level of maturity at which one enterprise perceives itself should (with acceptable minimal variations) be recognizable from within the enterprise and appear so to an external observer as well. So why is this so often not the case?
The Dangers of Spreadsheets for EA Data Gathering
It would be difficult to imagine working in IT without spreadsheets. Spreadsheets are an excellent tool for outlining and organizing data resulting from complex activities. However, they are a dangerous tool for gathering the data that they present so well, despite both the temptation and convenience spreadsheets provide for it.
One of the major challenges for Enterprise Architects is obtaining the information they need to do their jobs. Even after they get past the common challenges of gaining acceptance and cooperation, they are still left with the universal speed bumps of getting the necessary time and attention from managers to provide the data required for management.
Carrying the process one step further, managers (especially at the earlier stages of architecture maturity) are reluctant to take the time from their employees to obtain the necessary, low-level inputs that lead to accurate measurements. Finally, the employees themselves have a tendency to rush when providing inputs and (unless the information requests are very carefully formatted) will tend to rate their efforts as high as they believe they can without being challenged.
For these reasons (and usually others), the data for the spreadsheets are gathered using spreadsheets, which creates accuracy issues. After reviewing the processes employed to gather the data used to determine architectural maturity more closely, it is easy to see where a Level 2 enterprise could believe it has achieved a higher level. It is also understandable that what an outsider would perceive as an organization just barely starting on Level 2 will be presented in a slide deck (another very useful and frequently abused tool) as a company well on its way to achieving Level 4.
Two issues in using spreadsheets as the input for measuring architectural maturity are immediately obvious. One is that spreadsheets are great tools for summarizing but respondents need a thorough understanding of how to measure the value of the data they are providing. However, including the documentation for that understanding in the spreadsheet often results in a hard-to-read format. Providing a separate document to explain how to complete the spreadsheet may seem like a simple solution, but it is just as simple for respondents to ignore that document — especially for respondents who are trying to complete it quickly.
Most Web-based surveys have the same challenges as the spreadsheet, only they look better. The bottom line here is that sometimes solving one problem (in this case simplifying the information-gathering process) can create other problems, such as inaccurate data due to haste, misinterpretation of the data being requested, or both.
No Off-ramps on the Road to Architectural Maturity
In all ventures the achievement of goals is the biggest threat. You read that correctly. It is the very counter-intuitiveness of this threat that makes it such a common danger. The threat is the complacency that can easily follow a success, and the harder won the goal is the more likely that the achievers will rest upon their laurels for longer than is safe.
With the focus on frameworks and repeatable processes, and the use of the spreadsheets to track progress, the pursuit of enterprise architecture maturity is more susceptible to the danger of complacency than most ventures.
Frameworks are a necessary and valuable part of an enterprise architecture. Frameworks help to provide the necessary stability in the architectural foundation. A stable foundation can more easily support the other processes involved with growing the maturity of the architecture. Just as the foundations of many physical structures (especially bridges) need regular inspections, repairs and upgrades, frameworks need regular review to ensure their integrity and potential for improvement.
For instance, the enterprise architecture process includes allowing exceptions for individual projects. In addition to being an expedient for projects that are at a more localized level, exceptions are intended to be used as an opportunity to discover improvements to existing frameworks. They are also a measurement of the stability of a framework. If exceptions are frequently granted, there is very likely either an issue with the exception evaluation process or the framework itself. Just because a spreadsheet has the creation of a particular framework checked as “done” does not mean it is time to forget the need that framework fills. The same can be said of all of the parts that make up an enterprise architecture.
Enterprises are especially tempted to take the off ramp to complacency at the earliest and latest stages of their architectural maturity. In the early stages, projects often have team members under tremendous deadline pressures looking for shortcuts such as pointing to previous work as evidence of their continued compliance while failing to review new work for continued compliance. Companies that have moved far along the road to maturity often stall out under processes that have become too rigid and make the introduction of newer, better solutions so tedious that few (if any) are willing to stay the course necessary to have their suggestion reviewed and approved.
Getting Back on Track Toward Architectural Maturity
If the previous section on measurements being mistaken for a reality seems frighteningly familiar, it is an opportunity to weigh a couple of risks against each other. One risk lies in continuing along the same path, allowing the enterprise to believe the illusion it has created for itself. Many companies do just that, with the evidence being stagnated growth, high employee turnover and decreasing margins.
An alternative risk lies in gathering the information through direct interviews, which may cause some within the company to perceive the enterprise architecture team as annoying, expensive and intrusive. Replacing the status quo false perception with the false perceptions of the enterprise architecture team can work to your advantage in this case. While gathering information through interviews is much more difficult than getting the numbers input directly into the spreadsheet, in the long run it will be more profitable for all. If it takes longer to get the information by interview, then either A) The interviewees have a very clear idea of where they are at and are forthcoming about the supporting details, or B) This is yet more proof that the data provided via spreadsheets is rushed at best and inaccurate at any rate.
A successful enterprise architecture strategy will always account for some resistance during periods preceding a transition to the next level. The rewards of achieving, maintaining and then going beyond the next level are almost always agreed upon. Taking it one step further to foster the understanding of what it will cost to get there while maintaining the agreement of value will create a more solid foundation and set the stage for achieving the long-term goals.
If your enterprise is heading for an early exit, it is time to police the review process and avoid the speed trap of skipping steps because of prior success. Growth is hard, and deserves a moment of recognition and celebration at each step. The difference between continued growth and peaking too soon after achieving a new level is determined by whether you choose to look back on your accomplishments or focus on the next goal.
Conclusion
I suppose some enterprises may score themselves lower than what they truly have achieved, but they are doing an excellent job of hiding. The companies that are on track for enterprise maturity adopt one behavior that will help them get there: constantly challenging themselves to prove their excellence on each and every project. Looking at their examples, it is easy to fool yourself into thinking it was easier for them to get where they are than it is for your organization to follow them. But when you actually do, you learn that the difference is that successful enterprises achieved mature architectures by staying on the difficult path until they adapted habits that helped them stay on course.
In this article, we examined a couple of ways enterprises can veer off course but hardly an exhaustive list. There can be any number of ways that an enterprise on the road to maturity can stall or stray. Likewise, there are other approaches than those given above to get the enterprise back on track. The one constant is that the first step to getting back on target is to question whether the path you are on is really taking your organization towards its goals.
