What is the Architecture Development Method?
The ADM is part of TOGAF, and provides guidance for developing an enterprise architecture
Book a Demo
The Architecture Development Method Distilled
Preliminary Phase
Defining "how we do architecture" in your enterprise
The main objectives of the Preliminary Phase are to determine and establish the Architecture Capability desired by the organization.
A key part of this is to define what needs to be done, and how it will be carried out. For example, the main output is a Request for Architecture Work that outlines requirements, and deciding what organizational context, structures, tools or architecture frameworks need will be needed to support this work.
Approach
In this phase TOGAF® is tailored to meet the needs of the coming iteration of ADM. We define underlying principles, assess the ability of the enterprise architecture and business to make the required changes, and integrate TOGAF with other management frameworks.
There are steps in this phase to scope the enterprise organizations impacted from the proposed changes, to confirm that the right governance and support frameworks are in place, to define and establish the EA team and organization, to identify and establish architecture principles, to tailor TOGAF and any other frameworks, and to implement tools.
At the end of this phase, the EA team should be ready to follow an iteration of the ADM cycle. This is partly why the Preliminary Phase is shown at the top of the ADM diagram, and outside of the main cycle of Phases A to H.
Phase A: Architecture Vision
The initial phase of the ADM
Phase A provides a clear Statement of the Architecture Work that will be delivered in an iteration of the ADM. It also provides the Vision of the proposed enterprise architecture. This sense of direction is vital for guiding the work throughout this iteration of the ADM.
The Statement of Architecture Work defines the program of works to develop and deploy the architecture outlined in the Architecture Vision. And it is the Vision that provides the high-level aspiration of the capabilities and business value that the proposed enterprise architecture will deliver.
Approach
Starting with the Request for Architecture Work, Phase A provides a tool (this Vision) that sells the benefits of the proposed capability to stakeholders and decision-makers within the enterprise.
Business Scenarios are used to understand the business requirements and help articulate the architecture requirements implied by the required capability.
This is documented in the Statement of Architecture Work, which is used to build consensus to support the final architecture. Consensus is represented when the sponsoring organization signs this document.
Phase B: Business Architecture
Develop your Target Business Architecture
TOGAF® approaches enterprise architecture as a way of improving business capability – which is why the first architecture development phase deals with the Business Architecture.
The ADM starts from a business perspective – with a strong business need identified in the Request for Architecture Work in the Preliminary Phase, and further refined into a Statement of Architecture Work and Architecture Vision in Phase A.
Approach
A key objective in the Business Architecture phase is to develop a Target Business Architecture that shows how the enterprise can achieve the Architecture Vision and address the Request for Architecture Work. Its second objective is to make a first-cut at identifying candidate Architecture Roadmap components to bridge the gap between the Baseline and Target Business Architectures.
TOGAF regards knowledge of the Business Architecture as a prerequisite for architecture work in other domains, such as Data, Application, and Technology
It is Business Architecture that also demonstrates the business value and return on investment of architecture work to key stakeholders.
Business models, such as activity or process models, use-case and class models, or node connectivity diagrams, extend business scenarios to map architecture from high-level to more detailed business requirements.
All three architecture development phases (B, C & D) follow similar steps.
It is important to reuse any available reference models, and tailor all outputs to address stakeholder viewpoints. Architects then develop a baseline and target description of the Business Architecture, and perform gap analysis to figure out how to make the transition from one to the other.
Phase C: Information Systems Architectures
Including the development of Data and Application Architectures
TOGAF® divides Phase C – the Information Systems Architectures – into two, covering the development of the Data and Application Architectures. The TOGAF documentation has a brief introductory chapter covering both domains, and then a separate chapter each for Data and Application.
As with the other architecture development phases (B & D), the objectives are to develop the target information systems architecture for data and application and to identify candidate Architecture Roadmap components based upon the gaps between Baseline and Target Architectures.
Approach
Phase C always involves a combination of Data and Application Architecture. Providing both are covered, it doesn’t matter in which order – there are advocates for both approaches.
The steps for Data and Application are very similar – selecting reference models, viewpoints and tools; developing a baseline and then target architecture description, performing gap analysis and defining candidate roadmap components; and resolving any impacts across the architecture landscape.
After conducting a formal stakeholder review the architecture is finalized, and the Architecture Definition Document created.
The key differences between Data and Application are in the subject matter, which is reflected in the use of different reference models, techniques, and architectural representations. For example, Data Architecture might use entity-relationship or class diagrams, while Application Architecture might use an Application Communication diagram or Software Engineering diagrams.
Phase D: Technology Architecture
Develop a Technology Architecture for your architecture project
Phase D is the Phase in TOGAF® that develops the Technology Architecture for an architecture project. Technology architecture is a description of the structure and interaction of the platform services, and logical and physical technology components.
Phase D develops the Target Technology Architecture that enables the data and application components (developed in Phase C), which in turn enable the business components.
Approach
The architectures developed in Phases B, C and D combine to enable the Architecture Vision – which addresses stakeholder concerns and the Request for Architecture Work.
As with the other architecture development phases, Phase D identifies candidate Architecture Roadmap components to make the transition from Baseline to Target.
The steps in Phase D are almost identical to the steps in Phases B and C – the main difference is that the focus is now on Technology. So this includes Technology Reference Models and Technology criteria or measurements – such as Performance, Maintainability, Location and Latency, or Availability.
It's very important to identify outputs and deliverables to help build a Technology Architecture that truly enables the Information Systems and Business Architectures.
Getting the right scope accelerates pay-back, while an excessively large scope will frustrate a successful implementation. This is not about deploying technology for its own sake, but developing a Technology Architecture that really does address the Architecture Vision and Request for Work.
This phase provides a clear statement of the Architecture Work that will be delivered in an iteration of the ADM, delivering a high-level vision that defines the program of works.
Phase E: Opportunities and Solutions
Identify opportunities to deliver the Target Architecture
Phase E is well named – it is about finding Opportunities for delivering the Target Architecture by implementing specific Solutions.
Phase E generates the first complete version of the Architecture Roadmap – by combining the analysis and suggestions from the Architecture Development phases – B, C & D.
Approach
This phase concentrates on how to deliver the architecture. So it looks at creating an Architecture Roadmap listing Work Packages in a timeline to realize the Target Architecture.
When the change is so large that it is impossible to go directly from the Baseline to the Target Architecture, then it is Phase E that produces an incremental approach, made up of intermediate or Transition Architectures.
And it is Phase E that maps the required architectural changes to investment programs and projects that have the funding and resources to carry out the Work Packages, and deliver the Transition and Target Architectures.
The inputs to this phase are pretty much everything that’s been output from earlier phases.
The steps take these outputs; consolidate them, analyze dependencies, and reconcile differences; and confirm again that the organization is able to make the changes.
Phase E refines and updates the requirements, architecture documentation and Architecture Roadmap. The key output is a first-cut of the Implementation and Migration Plan.
Phase E - Opportunities and Solutions, where TOGAF® first looks at how the Vision and Future Architectures are delivered.
Phase F: Migration Planning
Finalize a detailed Implementation and Migration Plan
The early phases of ADM identify the need for architectural change and then develop the business, data, application and technology architectures to support that need.
Phase E then produced a high-level Implementation and Migration Plan to leverage investment opportunities and identify specific solutions to deliver the Target Architecture.
Phase F finalizes a detailed Implementation and Migration Plan, together with the final Architecture Roadmap.
Approach
It also makes sure that this Plan is coordinated with the change management approach used within the enterprise and with other initiatives within the overall change portfolio.
Finally, Phase F ensures that key stakeholders fully understand the business value, the cost of work packages, and the Transition and Future Architectures.
Whereas the early Phases of ADM are very much directed by the Enterprise Architecture team, the Phases from E through to H require collaboration with other change agents. Phase F in particular requires four management frameworks to work closely together for the Implementation and Migration Plan to succeed. These four areas are:
- Business Planning
- Enterprise Architecture
- Portfolio and Project Management
- Business Planning
Working together, these four areas must prioritize efforts, using criteria such as Performance Evaluation, Return-on-Investment, Business Value, Critical Success Factors, Measures of Effectiveness, and Strategic Fit.
This phase provides a clear statement of the Architecture Work that will be delivered in an iteration of the ADM, delivering a high-level vision that defines the program of works.
Phase G: Implementation Governance
Ensure implementation conforms with the Target Architecture
The actual development and implementation take place in parallel with Phase G. Phase G makes sure that an implementation project, and also other ongoing projects, are compliant with the defined architectures.
Typically the Target Architecture is developed as a series of transitions to realize business value and benefits as soon as possible, and to reduce risk in a transformation program. Each Transition represents an incremental step towards the Target, delivering business benefits in its own right.
Approach
By the time we reach Phase G, the architecture has been developed (in Phases A to D), the opportunities and solutions for delivering the architecture have been identified (in Phase E), and the detailed implementation and migration plan has been finalized (in Phase F). So the role of the architecture team in Phase G is all about providing architectural oversight of the implementation.
This is done by confirming the scope and priorities for deployment, guiding development and solutions deployment, and performing compliance reviews.
An Architecture Contract document is used to drive architecture change. Produced at the beginning of Phase G, and approved by the architecture function and those responsible for implementation, it is the mechanism for assessing compliance in architecture governance.
This phase provides an architectural oversight of implementation. Implementation Governance ensures that implementation projects conform to the Target Architecture.
Phase H: Architecture Change Management
Establish procedures to manage change to the new architecture
Nothing ever goes exactly to plan – and there will always be new demands and requests to change the architecture. Phase H describes the change management process to manage changes to the architecture in a cohesive and architected way.
Typically this requires continual monitoring of governance requests, new technologies, or changes in the business environment.
Approach
The process should support the implemented enterprise architecture as a dynamic environment that has the flexibility to evolve rapidly in response to these changes.
In Phase H it is critical that the governance body set up criteria to judge whether a Change Request warrants a simple architecture update or whether it requires starting a new cycle of the Architecture Development Method (ADM). It’s important to avoid "creeping elegance", so changes must relate directly to business value.
How the enterprise architecture is used is the most important part of the architecture development cycle, so monitoring business growth and decline is critical in Phase H. Eventually the enterprise architecture that worked for the organization yesterday ceases to support the capabilities of today or tomorrow.
Change requests output from Phase H can be classified as Simplification - often driven by a requirement to reduce investment; Incremental change - driven by a requirement to derive additional value from existing investment; or Re-architecting change which is driven by a requirement to increase investment and create new value.
Phase H ensures that the architecture achieves its original target business value, by managing changes to the architecture in a cohesive and architected way.
Architecture Requirements Management
How to manage Architecture Requirements through the ADM
Requirements are produced, analyzed and reviewed in each of the phases of the ADM. The Requirements Management Phase describes the process of managing these architecture requirements throughout the ADM.
The Requirements Management Phase is central to the ADM – which is why it is shown at the center of the ADM crop circle diagram. This Phase describes a process for Requirements Management, and how that process links to the other phases of the ADM.
Requirements
Requirements are not static – they dynamically evolve as we complete each Phase of the ADM, and also between cycles of the ADM. Requirements for enterprise architecture, and subsequent changes to those requirements, are identified, stored, and fed into and out of the relevant ADM phases, and also between cycles of the ADM.
Dealing with changes in requirements is crucial. Architecture deals with uncertainty and change - the "grey area" between what stakeholders expect and what is possible. Architecture requirements are therefore invariably subject to change.
Moreover, architecture deals with many drivers and constraints which are beyond the control of the enterprise – such as changing market conditions or new legislation - which can produce changes in requirements in an unforeseen manner.
TOGAF® emphasizes that the Requirements Management process itself doesn’t dispose of, address, or prioritize requirements, as this is done within the relevant phase of the ADM. The Requirements Management Phase is merely the process for managing requirements throughout the overall ADM.
Are you ready to architect your digital future?
Book a free demonstration of iServer365 to see how it can deliver TOGAF based EA for your digital transformation needs