By Mike Lambert, Fellow of The Open Group and Chair of The Open Group Architecture Forum
The Open Group TOGAF® Standard – Version 9.2 was published April 16, 2018. A common misconception voiced by several people at that time was that Enterprise Architecture in general and the TOGAF Standard are barriers to enterprise agility.
This paper addresses that misconception by reference to specific sections of the standard; it does not assume the adoption of any specific agile method.
Why is Agility Important?
Increasingly there is a demand for enterprises to deliver benefits more quickly. There is an imperative to respond quickly to drivers for change, and to be able to change direction quickly and safely.
What role does Enterprise Architecture play?
Enterprise Architecture provides a framework for change, linked to both strategic direction and business value. Enterprise Architecture provides a sufficient view of the organization to manage complexity, support continuous change and manage the risk of unanticipated consequences.
The demand for agility is not new.
The US Clinger-Cohen Act of 1996 was a major driver for the adoption of Enterprise Architecture, because it required investment in new IT systems (in the US Public sector) to demonstrate fit with existing systems. Almost immediately, it was recognized that it is not practical to develop a full Enterprise Architecture “top down”; it is necessary to break the work down into “segments” related to the specific needs of the enterprise at particular points in time, and to have some form of “Integration Architecture” to ensure that the segments fit together and are aligned with the strategic direction of the enterprise.
The TOGAF Standard has embraced Agility from Version 1
This states that every architecture initiative needs to be scoped to address the specific needs of the segment to be addressed. (Section 4.5 of the TOGAF Standard).
The major scoping dimensions are
- Breadth of the enterprise
- Depth; level of detail
- Time Period
- Relevant Architecture Domains
Specifically, this model introduced the term Capability Architecture reflecting the need to be able to deliver (small) increments of capability “continuously” to meet the evolving need of the enterprise.
However, it stressed the need for an understanding of the overall strategic direction of the enterprise at a very high level and the context within which the capability increment needs to fit, to avoid unanticipated consequences.
How does that relate to the call for increased agility in 2018?
There is an ongoing demand for the size and timescale of architecture segments and increments of capability to become ever shorter.
This in turn is resulting in a tendency for enterprises to skip the development of strategic and segment architecture, which in turn is resulting in some high-profile IT Failures because of the unanticipated consequences of what appeared to be minor changes.
The Keys to Successful Agility
There are two major factors to achieving successful agility:
- Managing Scope, understanding when a new capability is needed, how much of the enterprise is impacted and how different parts of the enterprise interact.
- Having a “Big Picture” showing the overall strategic direction of the enterprise, key business capabilities and significant relationships that must be protected. Without this, the lack of understanding of key dependencies may result in unanticipated consequences and piecemeal development and change may detract from the overall strategy for the enterprise. Having a “Big Picture” enables an impact assessment of any proposed change.
Levels of Architecture Enable Agility
Top-down, The Enterprise Strategic Architecture provides a high-level view of the area of the enterprise impacted by change; the Capability Architectures are detailed descriptions of (increments of) capability to be delivered. These are Sprints in the agile world. They are sufficiently detailed to be handed to developers for action. As the diagram shows, sprints can occur in parallel.
A key consideration is achieving is that the sprints are time-boxed and aimed at addressing a set of bounded objectives. The Capability architectures should be tightly scoped to address those objectives.
The higher levels show the relationships and dependencies between capability increments and provide the framework for the management of risk of unanticipated consequences. They provide the information needed to assess the overall impact of a proposed change.
Bottom-up, there is feedback from the implementation of capability increments which influences the higher levels. The enterprise strategic architecture may evolve as a result of experience gained from the deployment of each and every capability increment.
The strategic architecture is not static. It must be evolved as the strategy of the enterprise evolves; in an agile environment, that is likely to be more frequent than a “traditional” long term strategic plan.
However, it is vital to have appropriate governance to maintain the link between the strategic architecture and the business needs of the enterprise.
Transition Architecture Manage Risk
Transition Architectures provide a way of managing risk. Transition Architecture document the architectural state after delivery of each sprint, mapping each increment of capability to the desired end state and demonstrating the stability of the complete system.
The TOGAF Architecture Development Method
The iconic graphic of the TOGAF ADM reinforces the perception that Enterprise Architecture is a long “waterfall” process.
However, the TOGAF Standard does not:
- Mandate that the steps must be performed in the sequence shown
- Mandate a “waterfall” method
- Specify the duration of any phase or cycle of architecture development
Enterprise Architecture in an Agile Environment
A traditional view of Enterprise Architecture shows a number of stages:
In terms of the TOGAF ADM,
- Phases B, C and D define the baseline and target
- Phases E, F and G deploy the target
- Phase H manages change
In an agile environment it is likely that these activities may be a continuous managed process:
The TOGAF standard already includes guidance which is directly relevant to this “architecture style”:
This paper has demonstrated that the TOGAF ADM can be adapted to support enterprise agility.
Indeed, over the last few years, there have been numerous presentations at quarterly members meetings of The Open Group of the successful application of the TOGAF ADM in an agile environment.