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
From version 1, the TOGAF Standard has embraced the concept of architecture partitions.  In summary,
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
The TOGAF Standard, Version 9, published in 2009, built on this by including a model for developing architecture partitions at various levels of detail :
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
The standard does recommend that the ADM be adapted to meet the needs of the enterprise; agility is one such need.
The standard identifies how the ADM can used iteratively to develop a comprehensive enterprise architecture landscape.
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.
Mike Lambert is a Fellow of The Open Group and Chair of The Open Group Architecture Forum.
The Open Group TOGAF® Standard – Version 9.2
Chapter 36 of the TOGAF Standard, Version 9.2
Chapter 19 of the TOGAF Standard, Version 9.2
Section 15.5.1 of the TOFAF Standard, Version 9.2.
Section 12.3.10 of the TOGAF Standard, Version 9.2
Sections 4.2 and 4.3 of the TOGAF Standard, Version 9.2
Sections 18.1 and 18.2 of the TOGAF Standard, Version 9.2
Sections 7.3.2, 9.3.2, 10.3.2, 11.3.2 of the TOGAF Standard, Version 9.2
Sections 7.3.3, 9.3.3, 10.3.3. 11.3.3 of the TOGAF Standard, Version 9.2
Section 14.3.2 of the TOGAF Standard, Version 9.2
Section 15.5.1 of the TOGAF Standard, Version 9.2
Thank you, Mike.
Agility is the key, absolutely!
The way I look at it is:
– Strategic -> Capability -> Segments
At the same time:
Baseline -> Transition 1 -> Transition 2 -> .. -> Transition(n) -> Target
Each of these phases are sprints. And Sprint 0 could take a bit longer to determine and lay out the strategy, capabilities, baseline, use stories, etc and then comes the phases for transition architectures.
I believe it is similar to what you have laid out in the article above, but broken it further to define and bound sprint and correlate to the ADM. Would appreciate your thoughts!
Mike, applying agile concepts to TOGAF itself, what would you consider a ‘minimum viable TOGAF’? And isn’t it high time to replace the ‘circular waterfall’ picture of the ADM by something akin to your parallel value streams (which remind me of RUP btw)?
I see the Minimum Viable Architecture Product at the end of a sprint, would be an increment in value. This could be a deliverable, or a SSB(s) depending on your timescales.
Depending on system complexity the transition architecture could be seen as a phase made up of many sprints. Each sprint delivers a number of value products that are: Independent (of all others), Negotiable (not a specific contract for features), Valuable (or vertical), Estimable (to a good approximation), Small (so as to fit within an iteration), Testable (in principle, even if there isn’t a test for it yet).
Comments are closed.