RSS Feed
Download our iPhone app
Browse DevX
Sign up for e-mail newsletters from DevX


Pitfalls on the Road to Enterprise Architecture Maturity : Page 2

Here are some ways that an enterprise architecture gets lost on the way to maturity and some alternate paths to get back on track.


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.


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.


  • TOGAF Online > Part VII: Architecture Capability Framework > Architecture Maturity Models
  • Wikipedia: Capability Maturity Model Integration
  • OCIO › Policy and Programs › Enterprise Architecture › DOC ACMM v1.2

  • Scott Nelson plays the roles of development manager, architect, project manager, and portal evangelist on any given day, and blogs lessons learned at Head in the Web when they are not suitable for Developer.com or DevX.
    Email AuthorEmail Author
    Close Icon
    Thanks for your registration, follow us on our social networks to keep up-to-date