A revised TOGAF ADM for whole-of-enterprise architecture development
6 likes•2,174 views
The document discusses modifications to the TOGAF Architecture Development Method (ADM) to adapt it for whole-of-enterprise architecture beyond just IT-centric applications. It outlines a structured process encompassing phases from solution design to implementation, including governance, stakeholder engagement, and iterative assessments. The aim is to create a flexible architectural framework that evolves with ongoing business and technological changes.
A revised TOGAF ADM for whole-of-enterprise architecture development
- 1. The second part of the cycle, for solution design and implementation, is much closer to the original A revised TOGAF ADM for whole-of-enterprise architecture TOGAF ADM: the key difference is that it can cover more than just an IT-centric scope: In its standard form, the TOGAF ADM is usable only for IT-architecture. The architecture consultancy • Phase E: Design Solutions – work with solution-designers to assess options and trade-offs between Tetradian has identified a set of amendments to the ADM that allow it to be re-purposed for use in requirements and constraints (from Phase D) to identify high-level solution-designs broader-scope whole-of-enterprise architecture, including contexts in which no IT is in use at all. • Phase F: Plan Migration – work with governance, portfolio and change management teams to This modified TOGAF ADM cycle also maps well with PRINCE2 and similar programme or project develop transformation blueprints, change-programmes and individual implementation-projects management methodologies and governance. Unlike the original ADM, it requires just one explicit • Phase G: Guide Implementation – work with programme and project managers to assist in resolving stakeholder-review at the end of each of Phases A to D. The key governance documents or ‘products’ trade-offs between architecture and implementation also mark the boundaries between the architecture-cycle Phases: When all projects arising from the assessment are complete, the high-level architects and solution- architects alike need to carry out a ‘lessons learned’ exercise, to identify any architectural concerns that might trigger new architecture-cycles, or change the architecture itself. • Phase H: Review Architecture Implications – assess issues and lessons-learned arising from the architecture cycle, and identify (and, if required, implement) any necessary changes to architecture standards and processes The architecture is never ‘complete’: instead, it grows and changes with each iteration, creating a richer and more valuable view of the enterprise as a whole. Methodology – preparation This phase is independent of the main architecture cycle. Since it provides oversight to the main cycle, we need to do it at least once before any architecture work takes place, but we also need to revisit it at regular intervals – for example, as a formal annual review. Phase P – preliminaries In this phase we obtain authorisation from the executive to conduct enterprise-architecture; define the overall scope of enterprise-architecture, and the roles, responsibilities and function of the architecture team; and outline the governance, standards, frameworks and methodologies to be used for archi- tecture development and architecture services. Typical steps include: Step P1 – Establish the enterprise-architecture capability Step P2 – Identify Architecture Principles Step P3 – Identify applicable business policy, legislation and regulations Step P4 – Identify applicable Standards We create and review the architecture capability via a high-level version of the same architecture-cycle. Step P5 – Identify core business-goals and business-drivers In TOGAF, this is described as the ‘Preliminary Phase’. Step P6 – Identify enterprise-architecture scope • Phase P: Preliminaries – establish (or review) the architecture capability, the purpose, governance, Step P7 – Identify constraints framework, methodology and integration, and define a big-picture view of what the overall aims Step P8 – Identify stakeholders and concerns, business requirements, and overall architecture Vision to achieve for the entire enterprise Step P9 – Identify content for high-level models A whole-of-enterprise scope is too large to tackle in one go, so we develop the architecture iteratively, Step PX – Secure approval for Architecture Charter, governance, etc with each step constrained within the specific scope of a single business-issue or change-project. This works because we use a framework that has a true enterprise-wide coverage. It also makes better business sense, because we gain immediate return from the architecture work, and its value increases Methodology – assessment as each project leverages the knowledge and lessons learned from previous architecture-cycles. In the assessment Phases A to D of the architecture-cycle we create most of the architecture models, In the TOGAF standard, scope and purpose are always IT-centric, with an emphasis on detail-level design-requirements and the like. The focus of governance here is more on the architecture itself than technology. But here we may be dealing with any scope, any business-issue. So note that the four on programme-management – though the latter should at least be informed, and preferably engaged, Phases in the assessment part of the cycle have a subtly different emphasis compared to TOGAF: in every step of the process. • Phase A: Establish Iteration Scope – identify the core business-issue(s) to be addressed, and scope Phase A – establish iteration scope (in terms of framework layers, columns and segments) to be covered in the analysis This phase is the start-point of a regular architectural-services cycle, to identify the purpose, scope and • Phase B: Assess Current Context – establish the current architectural description for the scope and context for the current iteration. Typical steps include the following: business-issue identified in Phase A Step A1 – Establish the business-purpose and scope of the cycle • Phase C: Assess Future Context(s) – establish the required future-architecture(s) for the scope and Step A2 – Review applicable Architecture Principles, policies etc business-issue identified in Phase A Step A3 – Identify business goals and strategic drivers • Phase D: Derive Change Requirements – establish the gaps between the current architecture (from Phase B) and desired future architecture (from Phase C), and the resultant change-requirements Step A4 – Establish the architecture-framework scope of the cycle and constraints in relation to the scope and business-issue (from Phase A) Step A5 – Identify additional stakeholders, concerns and requirements Original TOGAF™ ADM © Open Group 2003 / 2008 : www.opengroup.org Revisions as described here © Tetradian Consulting 2008 : www.tetradian.com / www.tetradianbooks.com
- 2. Step A6 – Identify additional constraints Step E4 – Brainstorm co-existence and interoperability requirements Step AX – Secure approval for Statement of Architecture Work Step E5 – Perform architecture re-assessment and gap analysis Step E6 – Develop preliminary solution designs Phase B – assess current context Step E7 – Identify major work packages or projects This phase establishes the current architectural context for the scope specified in Phase A of this cycle. Step EX – Conduct stakeholder review of solution designs Typical steps include the following: Step B1 – Develop Baseline Architecture for ‘as-is’ context Phase F – plan migration Step B2 – Select reference-models, views and viewpoints During Phase F the architecture unit provides support to assist sponsor and programme-management Step B3 – Create and update ‘as-is’ architecture models in developing plans to implement the proposed solution designs. The key responsibility for such Step B4 – Review ‘as-is’ architecture against qualitative criteria decisions rests with the sponsor and programme management body, not the architecture unit. Step B5 – Finalise building-blocks for the architectural scope In practice, enterprise-architecture in Phase F has more of a ‘watching brief’ than an active role, so the Step BX – Conduct checkpoint-review for stakeholders key steps here would depend on broader governance procedures for detail-level project-, programme- and change-management. The TOGAF ADM suggests that typical steps would include: Phase C – assess future context Step F1 – Prioritise projects This phase establishes the probable and/or intended future context for the scope and each future Step F2 – Estimate resource requirements and availability time-horizon specified in Phase A of this cycle. Step F3 – Perform cost/benefit assessment of the various migration projects The steps in Phase C are almost identical to those in Phase B: the only difference should be that the Step F4 – Perform risk assessment architecture developed would apply to the respective time-horizon rather than the current ‘as-is’. All Step F5 – Generate timelined implementation roadmap steps other than CX, the final stakeholder-review, should be repeated for each time-horizon in scope. Step F6 – Document the Migration Plan The review should cover and compare all ‘to-be’ architectures developed in this Phase. Step C1 – Develop Baseline Architecture for ‘to-be’ context Step FX – Conduct stakeholder review of project- or migration-plan Step C2 – Select reference-models, views and viewpoints Phase G – guide implementation Step C3 – Create and update ‘to-be’ architecture models During this phase the architecture unit provides support to sponsor and programme-management, to Step C4 – Review ‘to-be’ architecture against qualitative criteria attain and maintain architecture-compliance during implementation of solutions from Phase E, in Step C5 – Finalise building-blocks for the architectural scope accord with project- or migration-plans from Phase F. Overall governance for the project(s) under Step CX – Conduct checkpoint-review for stakeholders review remains with the respective project- or programme-management body. The steps in this phase depend on the requirements and number of ‘gateways’ in the respective Phase D – derive change-requirements governance methodology. All steps other than GX, the final stakeholder-review, should be repeated This phase establishes the gap between the current ‘as-is’ context and the probable and/or intended for each gateway. The review should assess architecture issues arising from all gateways for the plan, future ‘to-be’ context(s) for the scope and time-horizon specified in Phase A of this architectural cycle. as per the scope for the architecture-cycle. Typical steps include: All steps other than DX, the final stakeholder review, should be repeated for each time-horizon in Step G1 – Review Architecture Compliance Statement scope. The review should compare the ‘as-is’ architecture from Phase B to all ‘to-be’ architectures Step G2 – Assess impact on overall architecture developed in Phase C. Step G3 – Respond to Architecture Compliance Statement Step D1 – Construct and validate matrix of ‘as-is’ to ‘to-be’ architectures Step GX – Conduct stakeholder architectural review of plan-implementation Step D2 – Derive change-requirements from validated matrix Phase H – review lessons-learned Step D3 – Review requirements against existing dispensations Step D4 – Review requirements against qualitative criteria During this phase the architecture unit reviews the results of the iteration in terms of benefits achieved for the business, and implications and impact on overall future architecture. This will often result in Step DX – Conduct checkpoint-review for stakeholders updates or additions to the set of primitives, models, metamodels, Building Blocks and other content in the Enterprise Continuum; to requirements, standards and other decisions; to content within the Methodology – solutions shared glossary and thesaurus; and entries in the issues- and risks-registers. Typical steps include: In the solution Phases E to H, the focus of governance moves to project- and programme management, Step H1 – Assess results from the architecture-cycle with enterprise architecture called upon mainly to provide architectural guidance and arbitration Step H2 – Monitor changes in business and technology environment between projects,. and maintain high-level consistency as the architecture changes over time. Step H3 – Assess potential changes to framework, methodology etc Phase E – design solutions Step H4 – Assess requirements and options for architecture change During this phase the architecture unit will provide technical and other support to assist the sponsor Step HX – Conduct review by architecture governance-body in selecting appropriate options to resolve the gap between the ‘as-is’ and the one or more ‘to-be’ architectures for the context. Note that the key responsibility for decisions on solution designs rests Resources with the sponsor, not the architecture unit. Typical steps include: For more details on this adaptation and use of the TOGAF ADM for whole-of-enterprise architecture, Step E1 – Review gap-analysis and requirements from Phase D see Tom Graves, Bridging the Silos: enterprise-architecture for IT-architects (Tetradian Books, 2008), Step E2 – Identify business drivers and constraints for implementation www.tetradianbooks.com/2008/04/silos/ Step E3 – Brainstorm technical requirements from functional perspective For the standard TOGAF ADM specification, see www.opengroup.org/architecture/togaf8-doc/arch/ Original TOGAF™ ADM © Open Group 2003 / 2008 : www.opengroup.org Revisions as described here © Tetradian Consulting 2008 : www.tetradian.com / www.tetradianbooks.com