This blog post continues Matthew Kern’s discussion about enterprise architecture. For the previous post click here. See here for part one in the series.
Last month we went over the last two of five major processes of enterprise architecture. We then discussed some common IT standards and how they apply to enterprise architecture. The most interesting part of that, to me, is how many such standards are operational in nature and not transformational. Enterprise architecture is transformational. The overlap is sparse. This underlines the continued need for enterprise architecture frameworks.
There are some more highly related international standards, with relevance to enterprise architecture. IEEE 1471 proposes a standard for architecture, but it is mainly geared toward solution architecture and even more narrowly toward software, whereas the addition of fax/copier/printers without any software development is a perfectly valid enterprise architecture transformational initiative. ISO/IEC/IEEE 42010:2011 is similarly oriented. Both also reference systems engineering, and in systems or solution architecture this is common. Neither quite addresses portfolio management the area of most interest here in internal controls. Ron and I found this collaboration because of the link to internal controls and performance management (see image).
PMI has a standard for portfolio management (link here is to second edition, published 2008), the US government has CPIC, and other governments have their portfolio management standardization, but this is the adjacent and tightly coupled process not enterprise architecture itself.
So Back to Burk, OMB A-130, and the PMBOK: The enterprise level of architecture supports the portfolio manager, not the program manager or the project manager. While the broad sense of “enterprise architecture” as all five processes certainly is relevant to internal controls, and governance is certainly all about internal controls, the unique contribution of enterprise architecture to internal controls can be found primarily in the enterprise level architecture specifically. This has to do with the processing of business plans for proposed initiatives. (A separate audit process assures the existence and function of these controls in the US Government.)
Drawing from the US Federal Government where this process may be most mature and is certainly at least well defined, the relationship of enterprise architecture to portfolio management is described by the US Policy named OMB Circular A-130. Portfolio management is named CPIC (Capital Management and Investment Control). In CPIC portfolio management has three stages: select, control and evaluate. A commercial equivalent to US Government CPIC is the ANSI/PMI Portfolio management standard (link here is to third edition, published 2013).
Portfolio management or CPIC selects from the candidate business cases for transformation this year (current budget year). Business cases are, arguable, best produced by the operational functional manager in charge of the operation, function or line of business being improved or created (supported by the program manager for transformation of that area and the segment architect). Portfolio management selects the best set of projects to implement and projects are started for that set, each project having a project manager served by whatever solution or system architecture is warranted. Projects are controlled by portfolio management while transformation is in process. The project ends, the resulting systems and processes become part of operational or functional management in a steady state, and are evaluated for performance until they too must eventually be replaced at end of life. See image.
Here is the key point of the whole article series: each business case must contain description, cost benefit analysis, and risks. Selection occurs on this basis. Benefits (and costs) must include all major tangible and intangible benefits (and costs). (US Federal Government guidance found here.) The most important of these to long-term operations will be performance improvements to the organization. These will be implemented in the specific business processes of that particular operation or function being improved. The present performance must be baselined (today) to validate the business case. Performance improvements to operations will be periodically evaluated (future) in the “evaluate” phase of CPIC (or the equivalent in other portfolio management). When the operational or functional process is no longer effective (competitive) it must again be transformed, and in the meantime continuous improvement methods should occur.
The role of enterprise architecture in supporting this process is roughly as follows. An inventory of the major aspects of the organization as it exists today is created. The selected transformational projects and outcomes are applied to create a model of the future organization. Major milestones for all selected projects are merged to create a “transition plan” or “roadmap”. A “vision” of the future organization is created consistent with the strategic plan, and communicated to all stakeholders. Standards are set, possibly including approved product sets. Principals are established to improve implementation of transformational projects. Lastly, the performance improvements in the business cases are compared to the business goals of the strategic plan’s goals and objectives, determining if there is still a gap in the portfolio. There are many variations of all of this, but that is the rough picture.
Thus enterprise architecture guides portfolio selection and perhaps optimization of business cases prior to selection. It guides implementation. It connects strategy to implementation. It does this by forming a key part of the internal control structure, supporting portfolio selection and optimizing the performance improvements sought versus the strategic plan. Benefits of implementing enterprise architecture may include the following:
- Identification of gaps between the promised achievements of the portfolio and the goals of the strategic plan;
- Identification of redundant projects and programs for elimination;
- Improvement of the performance improvements in individual business cases for better alignment with the goals and objectives of the strategic plan;
- Reduction of TOC (Total Cost of Ownership) and procurement costs via standardization of an approved products list;
- Identification of projects and programs irrelevant to goals for elimination.
- Improved interoperability and data sharing by promotion of standards and use of principles.
- Improved IT security by the promotion of standards, principles, approved products and checks in governance but also by security specific performance measures.
- Improved transparency of decision making.
- Reduced corruption and political influence.
- Eventually, greater trust in leadership.
Note that none of these benefits occurs if the portfolio management or CPIC process is not functional. For this reason and the tightly connected nature of the two activities I suggest it may be best to merge them and measure their efforts as a whole (i.e “The capital planning committee is the governance activity associated with enterprise level architecture”).
Please note that a transformation project, designed to change the enterprise, might be anything. If you think that might include changing “culture” (a controversial topic), that would be a valid transformative project or program, for example. In most cases any project is held responsible for its own stakeholder management and cultural change requirements, and these are not the focus of that project but a supporting element. Each project is generally responsible for its own change management, with oversight via governance similar to any other required element.
Additionally there is a special relationship between enterprise architecture and information technology as an enabler of automation and process improvement (typical). Enterprise architecture may be expanded to other technologies for which a valid solution framework exists or can be constructed. In all cases, whatever the change may be, the ultimate arbiter of success is measured improvement in organizational performance.
Most organizations have failed to understand the term “enterprise architecture” in the full sense of all five activities listed here. Commonly only solution architecture is understood, and is termed enterprise architecture in ignorance. Sometimes questions may arise as to the effectiveness of enterprise architecture in organizations completely lacking portfolio management, and where enterprise architecture has been precluded from being effectively implemented (OMB introduced “PortfolioStat” reviews to combat that). Much of this may be due to the confusing history of enterprise architecture, and a lack of dissemination of key aspects of it beyond the US Federal government where it was initially created and funded (and note, at the time of writing this post, the NIST website was largely closed, thereby creating potential further risks or issues). However the current overview of the US Federal Government Common Approach to Federal Enterprise Architecture presents an unfocused and ambiguous view of the levels of architecture, which could be improved by simply reiterating the work of Burk in 2006 or adopting this slightly extended model.
Hopefully this view of enterprise architecture has helped to clarify discussion and description of enterprise architecture in this series. Further information on the 5 activities can be found in my related paper Enterprise Architecture as Five Activities.