Module 2 - Introduction to the ADM PDF

Module 2 -- Introduction to the ADM =================================== Key Terms --------- **Architecture Contract** Agreement between the architecture team and the project or solution delivery team. It defines the responsibilities, deliverables, standards, and compliance measures required to de...

Module 2 -- Introduction to the ADM =================================== Key Terms --------- **Architecture Contract** Agreement between the architecture team and the project or solution delivery team. It defines the responsibilities, deliverables, standards, and compliance measures required to develop and implement the architecture. **Architecture Partition** A way to divide the overall enterprise architecture into smaller, manageable sections. This makes it easier to focus on specific areas, reduce complexity, and ensure better governance. **Architecture Vision** a high-level, strategic view of what the future architecture will achieve. It provides a clear and concise description of the intended outcomes, acting as a \"north star\" to guide stakeholders and architecture efforts. **Governance Repository** A record of governance activity across the enterprise **Request for Architecture Work** A document sent from the sponsoring organisation to the architecture organisation to trigger the start of an architecture development cycle **Statement of Architecture work** A document that defines the scope and approach that will be used to complete an architecture development cycle Chapter 1 -- Basic Overview --------------------------- **[Basic Structure of the ADM]** - The ADM provides a tested and repeatable process for developing architectures. - Through the ADM cycle, there\'s a requirement for validation of the results against the original expectations. - This applies to both the results for the whole ADM cycle and those from particular phases of the process. - The requirement management phase is a continuous phase that makes sure any changes to the requirements are handled correctly through the governance processes and reflects across the other phases. An enterprise might choose to record all these requirements including those that are part of the scope of the current statement of architecture work through a single requirement repository - The lifecycle of outputs must be managed through version numbering policy. - This is practised by the architect to meet the requirements of the organisation and to work with architecture tools - In the ADM, documents that are under development and hasn\'t gone through any formal review are noted as \"draft\". - Approved doesn\'t mean its finalised. The document may grow during the subsequent phases but only be changed through appropriate change control and governance processes. - This is used with ADM to illustrate the evolution of Baseline and target architecture definitions **[Key points about the ADM]** The Architecture Development Method (ADM) in TOGAF is flexible and can be repeated multiple times across different phases, between phases, and even within phases. Each time you use the ADM, you need to make decisions about: How much of the enterprise to include. How detailed the architecture should be. The timeframes you're planning for, including intermediate goals. What resources and existing architectural assets to use, such as earlier work in the Architecture Repository or industry models. The ADM is designed to adapt to different industries, locations, and organizational needs. You can tailor it to your situation, even combining it with other frameworks that may work better for specific requirements, such as government frameworks used by US Federal agencies. The decisions depend on available resources, skills, and the value the organization expects from the effort **[Iteration]** The TOGAF **ADM is flexible and iterative**. 1. **Not a Linear Process**: The ADM diagram (the \"crop circle\") shows how activities connect and information flows, but it's not meant to represent a strict order like a waterfall process. 2. **What Practitioners Do**: Whenever the EA team works on any activity, it's part of an ADM phase. For example: - If someone develops a roadmap, they're working in Phase E (Opportunities and Solutions). - For each phase, you use required inputs and produce required outputs. 3. **Considering the Whole Picture**: When developing a Target Architecture: - You must consider how changes impact all areas (business, data, application, technology). - You also address gaps and plan the work needed to fix them. 4. **Simplifying Complexity**: Each ADM phase focuses on a specific goal to make it easier to manage. Inputs and outputs help guide what needs to be done. 5. **Starting Point**: Every architecture project must begin with **Phase A (Architecture Vision)** to define its purpose. After that, the process adapts based on what's being developed. In short, the ADM is **iterative, adaptable, and not one-size-fits-all**. Each project adjusts its path through the ADM based on its goals, but always starts with Phase A. **[Understand ADM iteration]** The ADM (Architecture Development Method) is a guide for creating important outputs for an architecture project. These outputs are created through \"work products,\" like diagrams or documents. Each phase of the ADM is used only if the project actually needs it. If a phase isn't relevant or has already been completed, you can skip it. In TOGAF 10, when we talk about repeating parts of the ADM (iteration), the focus is on getting the right information. If the information you need for the project isn't available in the Enterprise Architecture (EA) Landscape, you'll need to create it. Instead of thinking about constantly going back and redoing phases (looping), you should check if the information---about the subject, details, timing, or how recent it is---is already there. If it is, move on. If it's missing, use the relevant ADM phase to produce the needed information. A screenshot of a computer Description automatically generated The stylized Gantt chart in G186 Figure 10 shows how all phases of the ADM can overlap and be open at the same time when working on a candidate architecture and testing it for acceptance. The phases remain open until all the needed information is gathered. Once the information is complete, the phases can close. For example, if you\'re working on Business Architecture, you\'re in **Phase B** of the ADM, no matter the timing, purpose, or project you\'re working on. Phase B focuses on addressing stakeholder concerns related to the Business Architecture, identifying gaps, and understanding how changes impact the rest of the Enterprise Architecture (EA). The chart also shows that many ADM steps can be done at the same time. A good practitioner will look at the big picture, consider how changes affect the whole architecture, and address concerns from all stakeholders as they work through the phases. +-----------------------------------+-----------------------------------+ |  | relate to different points in | | | time. When the stylized Gantt | | | chart (Figure 10) is applied to | | | these purposes, it shows that the | | | practitioner will keep going back | | | to the necessary phases as | | | needed. Each time they revisit a | | | phase, they focus on the specific | | | level of detail required for the | | | purpose at that moment. This | | | approach ensures that the | | | architecture development process | | | stays relevant and aligned with | | | the project's needs over time. | +===================================+===================================+ | A diagram of a graph Description | Most problem-solving models | | automatically generated | follow a linear, step-by-step | | | process, which is easy to | |   | understand and aligns with | | | business cycle milestones. | | | However, this doesn't reflect how | | | people usually solve problems. | | | G186 Figure 11, from Jeff | | | Conklins titled *"Wicked Problems | | | and Social Complexity within | | | Dialog Mapping,"* illustrates a | | | more interactive approach. It | | | shows that testing ideas and | | | implementation together is a best | | | practice. This involves | | | iteratively checking if the | | | high-level strategy aligns with | | | practical execution and ensuring | | | that the execution supports the | | | overall direction. | | | | | | In Enterprise Architecture, | | | iteration is driven by the | | | specific information needed for | | | the current project, rather than | | | just the timing of EA | | | deliverables. The key question is | | | when the EA Capability needs to | | | provide specific work products to | | | support the project effectively. | | | | | | Table 3 in the TOGAF guide *\"A | | | Practitioners' Approach to | | | Developing Enterprise | | | Architecture Following the TOGAF® | | | ADM\"* summarizes the work | | | products that are actively used | | | by key enterprise processes, | | | helping practitioners focus on | | | delivering the right outputs at | | | the right time. | +-----------------------------------+-----------------------------------+