This blog post continues Matthew Kern’s discussion about enterprise architecture. See part one in the series.
Last month we described three enterprise architecture processes that support the three levels of transformational management described in the PMBOK. We concluded:
- Enterprise architecture supports portfolio management. It is that architecture process that supports the portfolio manager
- Segment architecture supports program management. It is that architecture process that supports the program manager
- Solution (sometimes system) architecture supports project management. It is that architectural process that supports the project manager
This month we will add the two missing processes that: 1) tie these three together; and 2) assure continuous improvement of enterprise architecture.
Enterprise architecture governance: How do you assure that the architectures and architectural plans of the projects support the program to which they belong? How do you assure that the architectures and plans of programs support the portfolio? If the middle level is missing how do you assure the project architectures and plans directly support the portfolio?
The answer is enterprise architecture governance. It must have two key parts to be effective:
1) When operations are inadequate business plans must be developed (describing the outcomes, improvements and returns that justify their effort), and sent to portfolio management for review. Once reviewed programs/projects must be initiated and tracked to completion.
2) Plans and architectures must be reviewed to assure that they align with higher level budgets, goals and objectives.
In “A Practical Guide to Federal Enterprise Architecture” three committees were suggested to implement enterprise architecture governance. With small changes, the same approach has been applied until today. The three committees common today are (with some variation usual):
- A portfolio or budget committee reviews and selects programs and projects to execute, and those to not execute. It reviews the portfolio. This often is tied to a yearly budget cycle.
- An executive steering committee oversees a particular product line or service line and assures that the program (and its plans and architectures) reflect needed operational changes, issues or concerns. It reviews segment architectures and plans. This is often tied operational evaluations, reviews or audits.
- A Change Control Board reviews project plans and solution architecture. This is often tied to “stage gates” or program events.
Representatives from higher level activities participate on lower level review committees. In this way “alignment” is achieved in plans, via approval. Enterprise architecture governance is the required “glue” that ties together the three levels of processes supporting transformational management.
Enterprise architecture process improvement, aka maturity management
Enterprise architecture works best if tailored to the latest improvements, and to local conditions. Furthermore, enterprise architecture return must be measured and reported. To do this some notion of “maturity” of processes must exist.
Software development process maturity is managed by a framework called CMMI. Some analogous thing might be expected to exist for enterprise architecture, which is different from software development. The United States Government Accountability Office produced an EAMMF (Enterprise Architecture Management Maturity Framework) to serve exactly that purpose. With it you monitor and improve and measure your enterprise architecture efforts.
Just as with software development, at the lowest levels of maturity your enterprise architecture processes may be ad-hoc. When they are written down and repeated the maturity improves. When all the organization is trained in the processes the maturity improves. When audits occur to assure the processes are used, the maturity improves. When the processes are measured, the maturity improves again. When the measurements are used to improve the return, efficiency and effectiveness of enterprise architecture, you have a mature enterprise architecture practice.
Frameworks are important to maturity. Writing down what you do in your practice, a required step for maturity improvement, produces a framework. Generic enterprise architecture frameworks are widely available as a starting point. As your enterprise architecture process maturity improves you tailor the framework to exactly what you need and do, improving efficiency, effectiveness and results. All generic frameworks as starting points are not equally good as all three levels of processes (enterprise/portfolio, segment/program, and solution/project). You can, and often should, mix and match frameworks for local needs.
We have attempted to clarify enterprise architecture. In total five processes compose enterprise architecture. Hopefully this will allow you to improve your recruiting, training and management of architecture efforts.
Standards
Having these definitions in hand, let’s look at some common standards and how they relate to conducting enterprise architecture.
| Standard | Applicability | Explanation |
| ITIL | Medium | ITIL focuses on the continuous improvement and management of operational services. Enterprise architecture focuses on transformation and discontinuous improvement, such as the creation of a brand new service.There is some overlap, mostly with segment level architecture. |
| COBIT | High | CobiT has high applicability to EA governance. As is, CobiT is not sophisticated in EA governance, but all governance is best if simplified and unified, made consistent. |
| CMMI | Low | CMMI relates to the maturity of software development processes. Software architecture (not development) is a subordinate type of architecture beneath solution (system) architecture. CMMI is often cited as a good maturity model for technology in a broad sense. |
| ISO 9000 series | Medium to low | Like Six Sigma this standard is definitive where thousands or millions of identical units are produced.In transformation where only a few deliverables exist all of different types, it is of far less interest. Where EA is conducted as a service by consultants there is more applicability, controlling errors in written deliverables, however engineers and editors have different skills and editing is unlikely to be merged into production. |
| ISO/IEC 17799 | Medium to Low | This standard focuses on operational processes and security. Enterprise architecture focuses on transformation and discontinuous improvement, such as the creation of a brand new service. |
| eTOM | Medium | Like ITIL, eTOM focuses on service operations, not transformation or initial startup. There is some overlap. |
| Six Sigma | Low | At the project level there is a beginning and an end, deliverables are finite and of diverse types. Six Sigma is definitive in operations, where thousands or millions of a unit are produced, but often far less applicable to transformation. It does have some applicability to governance and repetitive yearly activity in the enterprise portfolio, but this is not proven. |
I must now hurry to add 2 caveats to the table above:
1) Enterprise architecture is often responsible for the selection and enforcement of standards. In this sense all standards, above or not, are fair game for adoption by the enterprise.
2) It is often true that the very adoption of these standards is a transformational project, and the design of implementation, use and adoption is enterprise architecture.
Next month we will wrap up this discussion of what enterprise architecture is, and how it relates to internal controls (the post will include a link to a new EA paper written by Matt)
