The TOGAF Architecture Development Method (ADM) forms the core of TOGAF. It is a reliable, proven method for developing an IT architecture that meets the business needs of an organization, utilizing the other elements of TOGAF described in this document, and other architectural assets available to the organization.
An enterprise architecture provides views, roadmaps, architecture specifications, controls, and other useful things. Architecture is developed, and the EA Landscape populated. To do this, Practitioners require a set of essential knowledge. The Enterprise consumes effective guidance about and the ability to govern change.
Keep in mind that the essential output is what stakeholders, sponsors, and boss’ boss’ boss wants. No-one wants an architecture; they want guidance on planning and executing an effective change. Practitioners use an architected approach to providing the best available guidance on effective change. The essential outcomes and outputs are derived from the objectives of the phase.
A summary of the essential outcome/output and knowledge is provided in the table below:
| Phase | Output & Outcome | Essential Knowledge |
| Phase A: Architecture Vision | · Sufficient documentation to get permission to proceed.
· Permission to proceed to develop a Target Architecture to prove out a summary target. |
· The scope of the problem being addressed.
· Those who have interests that are fundamental to the problem being addressed. (Stakeholders & Concerns) · What summary answer to the problem is acceptable to the stakeholders? (Architecture Vision) · Stakeholder priority and preference. What value does the summary answer provide? |
| Phase B, Phase C, & Phase D | · A set of domain architectures approved by the stakeholders for the problem being addressed, with a set of gaps, and work to clear the gaps understood by the stakeholders. | · How does the current Enterprise fail to meet the preferences of the stakeholders?
· What must change to enable the Enterprise to meet the preferences of the stakeholders? (Gaps) · What work is necessary to realize the changes, that are consistent with the additional value being created? (Work Package) · How stakeholder priority and preference adjust in response to value, effort, and risk of change. (Stakeholder Requirements) |
| Phase E: Opportunities & Solutions | · A set of work packages that address the set of gaps, with an indication of value produced and effort required, and dependencies between the work packages to reach the adjusted target. | · Dependency on the set of changes. (Work Package & Gap dependency)
· Value, effort, and risk associated with each change and work package. · How stakeholder priority and preference adjust in response to value, effort, and risk of change. |
| Phase F: Implementation and Migration Plan | · An approved set of projects, containing the objective and any necessary constraints, resources required, and start and finish dates. | · Resources available to undertake the change.
· How stakeholder priority and preference adjust in response to value, effort, and risk of change. (Stakeholder Requirements) |
| Phase G: Implementation Governance | · Completion of the projects to implement the changes necessary to reach the adjusted target state. | · Purpose and constraints on the implementation team. (Gap, Architecture Requirement Specification, Control)
· How stakeholder priority and preference adjust in response to success, value, effort, and risk of change. (Stakeholder Requirements)
|
| Phase H: Architecture Change Management | · Direction to proceed and start developing a Target Architecture that addresses perceived, real, or anticipated shortfalls in the Enterprise relative to stakeholder preferences. | · Gaps between approved target, or preference, and realization from prior work. (Value Realization)
· Changes in preference or priority. (Stakeholder Requirements) |
