Traditional Layers of Abstraction: “IT Follows Business”
An enterprise architecture (EA) framework typically distinguishes several architecture layers and sets of views on EA artifacts. This decomposition helps disentangle the vast complexity of elements and their relationships in an enterprise. Such a framework is typically organized along three or four architectural dimensions that are used to structure the artifacts, e.g. Business Architecture, Information Architecture, Information Systems Architecture, and Technology Architecture. As depicted in Figure 1, these dimensions are typically viewed, either implicitly or explicitly, as layers of abstraction.
The underlying basic assumption in this traditional view is that business needs drive information needs, which drive technology decisions. Business processes and organizational structures follow the strategy, are implemented in and supported by information systems, which, in turn, are supported by technical infrastructure. While this “IT follows business” approach may be useful in categorizing IT assets, it does not provide an adequately strategic view on IT or enough detail on the social/organizational aspects of work.
Starting Point: Organizational Levels of Work
By contrast, our starting point for enterprise architecture and its governance is the organization and its natural levels of work and decision-making. This allows straightforward alignment of architectural elements and artifacts with their governance (roles, responsibilities, ownership, stewardship). The explicit notion of levels also helps link EA to other organizational frameworks, such as Scaled Agile Framework (SAFe), as the levels constitute a common backdrop for different systems.
We can also divide enterprise architecture conceptually to two distinct yet interlinked architectures: Technical Architecture and Business Architecture. The former encompasses the detail-level breakdown of Capability Architectures (sensu TOGAF) and the latter higher-level big picture, which builds on the capability abstraction. The two architectures are self-contained and each self-regulated with its paradigmatic function, methods, and tools. Capabilities are “citizens of both worlds” – boundary objects that bridge the two architectures. The vertical dual-architecture approach to enterprise architecture is exhibited in Figure 2.
Capability-Based Planning
A key underpinning of agile enterprise architecture is Capability-Based Planning (CBP). CBP is a technique for planning of investments in capabilities that will help achieve the business outcomes as specified in strategy.[1] A capability is a key architectural building block of Business Architecture. It defines “what” the business does rather than “how” things are done. As it represents a reasonably stable business function that is self-contained and relatively independent, it provides a good basis for architectural modularization.
The CBP method is focused on planning the required business improvements in terms of value-adding capability increments that deliver discrete, visible, and quantifiable outcomes and a measurable change in the maturity of the capability.[2] The method is fully compatible with TOGAF and SAFe frameworks, as discussed below.
The high level CBP process, loosely reflecting the Plan-Do-Check-Act cycle, is depicted in Figure 3.
The Map phase precedes the CBP cycle. It entails identifying the high-level capabilities of the enterprise and their breakdown structure. In the telecom sector, TM Forum’s Business Process Framework (eTOM) (see Figure 4) is a good reference model to guide and structure the capability mapping.
In the Assess phase, the performance of capabilities is assessed against one or more metric. A metric can pertain to the extent, quantity, amount, or degree of something that is measured or calculated. Specific capability maturity models can be used to measure the performance of respective capabilities.
In the Calibrate phase, capability development is aligned with business strategy. Strategic objectives are translated to capability requirements that are expressed in specific and measurable terms. Based on these capability requirements, the set of focal capabilities to be improved (existing capabilities) or developed (new ones) is identified, accordingly. Strategically prioritized focal capabilities and required capability development programs and projects can be illustrated with a “Cap Map” diagram, as shown in Figure 5.
In the Plan phase, the details of the implementation can be defined. Capabilities are delivered in a defined number of capability increments (one or more) that deliver discrete, visible and quantifiable outcomes. When all increments have been completed, the capability has been realized. Each increment is considered along the dimensions specific to the capability. The evolution of a capability in terms of capability increments can be visualized with a “radar” diagram, as exhibited in Figure 6.
Based on the gaps between the current baseline and the transition architecture of the next capability increment, requirements of the stakeholders, the overall transformation readiness, and any implementation constraints, capability development work can be planned, e.g. for agile release trains. A detailed increment-specific Implementation and Migration Plan (cf. TOGAF) can help specify the resource requirements and scheduling.
In the Improve phase, the capability increments are implemented vis-à-vis the transition architecture and according to the Implementation and Migration Plan. The Architecture Contract (cf. TOGAF) governs the connection between architecture and implementation organizations. The EA function monitors the progress of capability development against the planned capability increments. It intervenes and escalates deviations from the plan as required and manages any risks that arise.
References
[1] A. Aldea, M. E. Iacob, M. Lankhorst, D. Quartel, and B. Wimsatt, “Capability-Based Planning: The Link Between Strategy and Enterrprise Architecture,” whitepaper, The Open Group, November 2016.
[2] TOGAF Version 9.1, Open Group Standard, The Open Group, 2011.