The Modeling Tripod – Process, Business, Governance

The majority of organizations that I've talked to openly acknowledge that they're at a low level of maturity in their architecture practice. There are various maturity models out there, and plenty of organizations offering maturity assessments as part of their services. TOGAF has a fairly good one, which I’ll be using for this post. On the other hand, something that isn't explicitly called out, but which I've observed from various customers, is that achieving a given level of architectural maturity involves improving in several areas; areas that are dependent on each other.

Summary: Adopting an architecture program involves three strands; implementation of architectural processes, alignment with the business, and governance of activities. Progressing through the stages of architectural maturity requires attention to all three at each stage. Taking the maturity model in chapter 51 of TOGAF as an example, we have 5 levels:

Initial-> Under Development-> Defined-> Managed-> Optimizing

(I am ignoring level 0, ‘None’, where no EA exists). For each level, 9 points are defined.

Consider Level 1:

TOGAF 9 Architecture – Maturity Level 1

1. Processes are ad hoc and localized. Some Enterprise Architecture processes are defined. There is no unified architecture process across technologies or business processes. Success depends on individual efforts.
2. Enterprise architecture processes, documentation, and standards are established by a variety of ad hoc means and are localized or informal.
3. Minimal, or implicit linkage to business strategies or business drivers.
4. Limited management team awareness or involvement in the architecture process.
5. Limited operating unit acceptance of the enterprise architecture process.
6. The latest version of the operating unit's enterprise architecture documentation is on the web. Little communication exists about the enterprise architecture process and possible process improvements.
7. IT security considerations are ad hoc and localized.
8. No explicit governance of architectural standards.
9. Little or no involvement of strategic planning and acquisition personnel in the enterprise architecture process. Little or no adherence to existing standards.

Now, compare this with the definition of level 2:

TOGAF 9 Architecture - Maturity Level 2

1. Basic enterprise architecture process is documented based on OMB Circular A-130 and Department of Commerce Enterprise Architecture Guidance. The architecture process has developed clear roles and responsibilities.
2. IT vision, principles, business linkages, Baseline, and Target Architecture are identified. Architecture standards exist, but not necessarily linked to Target Architecture. Technical Reference Model (TRM) and Standards Profile framework established.
3. Explicit linkage to business strategies.
4. Management awareness of architecture effort.
5. Responsibilities are assigned and work is underway.
6. The DoC and operating unit enterprise architecture web pages are updated periodically and are used to document architecture deliverables.
7. IT security architecture has defined clear roles and responsibilities.
8. Governance of a few architectural standards and some adherence to existing Standards Profile.
9. Little or no formal governance of IT investment and acquisition strategy. Operating unit demonstrates some adherence to existing Standards Profile.

What becomes obvious is that certain points in level 2 cannot be achieved without achieving other points also at that level. Take point 2 for example; “Explicit Linkage to business strategies”. It is hard to see how we can achieve this if the enterprise architecture documents “are established by a variety of ad hoc means and are localized or informal” (maturity level 1, point 2).

This is just one example. What about the jump from level 2 to level 3?

TOGAF 9 Architecture - Maturity Level 3

1. The architecture is well defined and communicated to IT staff and business management with operating unit IT responsibilities. The process is largely followed.
2. Gap analysis and Migration Plan are completed. Fully developed TRM and Standards Profile. IT goals and methods are identified.
3. Enterprise architecture is integrated with capital planning and investment control.
4. Senior management team aware of and supportive of the enterprise-wide architecture process. Management actively supports architectural standards.
5. Most elements of operating unit show acceptance of or are actively participating in the enterprise architecture process.
6. Architecture documents updated regularly on DoC enterprise architecture web page.
7. IT security architecture Standards Profile is fully developed and is integrated with enterprise architecture.
8. Explicit documented governance of majority of IT investments.
9. IT acquisition strategy exists and includes compliance measures to IT enterprise architecture. Cost benefits are considered in identifying projects

Again, it’s hard to see how you can sell point 9, ‘IT acquisition strategy exists and includes compliance measures to IT enterprise architecture’ to senior IT leaders, with the explicit linkage of Enterprise Architecture to business strategies mentioned above.

Whether it’s the TOGAF maturity model or something else, you can identify three main categories of maturity marker – architecture processes, business alignment, and governance. The people who defined these maturity models were sensible to include all three areas, as you can’t realistically achieve the highest level of maturity in one without raising the others. It’s a bit like a stool with three legs – if one leg was a fifth the height of the other two, how could it support the weight?

The bottom line is that architecture maturity is a package deal; you need to work on achieving all aspects of a given maturity level before focusing on any part of the next one.