{"id":11996,"date":"2022-08-14T16:19:53","date_gmt":"2022-08-14T22:19:53","guid":{"rendered":"https:\/\/conexiam.com\/?p=11996"},"modified":"2025-01-30T20:38:38","modified_gmt":"2025-01-31T03:38:38","slug":"togaf-adm-phase-f-ausarbeitung-des-implementierungsplans","status":"publish","type":"post","link":"https:\/\/conexiam.com\/de\/togaf-adm-phase-f-craft-the-implementation-plan\/","title":{"rendered":"TOGAF ADM Phase F \u2013 Erstellen des Implementierungsplans"},"content":{"rendered":"\n<h1>\n\t\tTOGAF\u00ae ADM Phase F &#8211; Craft the Implementation Plan\n\t<\/h1>\n\t<p>TOGAF ADM Phase F crafts the Implementation Plan. Executing Implementation Plans are how enterprises directs change. A Phase F Implementation Plan will use one, two, twenty or more change projects. It doesn&#8217;t matter whether you are using Portfolio or Program to manage change. Craft the Implementation Plan to support your organization&#8217;s improvement.<\/p>\n<p><a href=\"https:\/\/conexiam.com\/what-is-the-togaf-framework\/\">TOGAF Standard 10th edition<\/a> is clear, the purpose of enterprise architecture is to guide effective change. Effective change means we execute plans and projects. TOGAF ADM Phase F represents a transition from where the <a href=\"https:\/\/conexiam.com\/what-is-enterprise-architecture-complete-guide\/\">enterprise architecture<\/a> process transitions to the control of change leaders. Without executing change, enterprise architecture is a pointless activity.<\/p>\n<p><a href=\"https:\/\/conexiam.com\/togaf-adm-phases-explained\/\">TOGAF ADM<\/a> separates the Phase F Implementation Plan from the Phase E Architecture Roadmap to support the transition from developing an architecture to developing the means to change. Enterprise architects have a critical role in change. However, the profession is designed for advisory, not action. We embed this best practice in the design of the <a href=\"https:\/\/conexiam.com\/togaf-adm-phases-explained\/\">architecture development method<\/a>. The enterprise architecture identified the most effective change and provided stakeholder&#8217;s the means to <a href=\"https:\/\/conexiam.com\/basics-of-enterprise-architecture-governance\/\" data-wpil=\"url\">govern change<\/a>. They are ready to develop the implementation plan.<\/p>\n\t\t\t<a href=\"https:\/\/conexiam.com\/togaf-enterprise-architecture-training-course\/\" target=\"_self\">\n\t\t\t\t\t\t\tExplore TOGAF Certification Training\n\t\t\t<\/a>\n\t<h2>TOGAF ADM Phase F &#8211; Craft the Implementation Plan<\/h2>\n<p>At a Glance:<\/p>\n<ul>\n<li><a href=\"#introduce\">TOGAF ADM Overview<\/a><\/li>\n<li><a href=\"#introduce\">What is TOGAF Phase F?<\/a><\/li>\n<li><a href=\"#introduce\">What is an Implementation Plan?<\/a><\/li>\n<li><a href=\"#introduce\">Why is an Implementation Plan different from an Architecture Roadmap?<\/a><\/li>\n<li><a href=\"#deliverables\">TOGAF ADM Phase F Deliverables<\/a><\/li>\n<li><a href=\"#deliverables\">What is the Role of the Enterprise Architect in Phase F?<\/a><\/li>\n<li><a href=\"#deliverables\">What is the Role of Portfolio Planners and Project Planners in Phase F?<\/a><\/li>\n<li><a href=\"#techniques\">Implementation Plan Tools and Techniques<\/a><\/li>\n<li><a href=\"#techniques\">Implementation Plan Techniques<\/a>\n<ul>\n<li><a href=\"#techniques\">Portfolio Planning<\/a><\/li>\n<li><a href=\"#techniques\">Program Planning<\/a><\/li>\n<li><a href=\"#techniques\">Benefit Realization<\/a><\/li>\n<li><a href=\"#techniques\">Risk Mitigation<\/a><\/li>\n<li><a href=\"#techniques\">Architecture Contract<\/a><\/li>\n<li><a href=\"#techniques\">Implementation Strategy<\/a><\/li>\n<li><a href=\"#techniques\">Using Architecture Roadmap Techniques for Implementation Planning<\/a>\n<ul>\n<li>Architecture Roadmap Type 1: Heatmap<\/li>\n<li>Architecture Roadmap Type 2: Lifecycle Charts<\/li>\n<li>Architecture Roadmap Type 3: Work Package Impact &amp; Dependency<\/li>\n<li>Architecture Roadmap Type 4: Scenario Analysis<\/li>\n<li>Transition Architecture<\/li>\n<li>Gap &amp; Solution<\/li>\n<\/ul>\n<\/li>\n<\/ul>\n<\/li>\n<li><a href=\"#techniques\">Implementation Plan Techniques Aligned to Architecture Purpose<\/a><\/li>\n<li><a href=\"#techniques\">Implementation Plan Techniques for Enterprise Architecture Use Cases<\/a><\/li>\n<li><a href=\"#techniques\">How does TOGAF Phase F align with Agile Development?<\/a><\/li>\n<li><a href=\"#techniques\">How does TOGAF Phase F enable Enterprise Agility?<\/a><\/li>\n<li><a href=\"#close\">Final Thoughts on TOGAF ADM Phase F &#8211; Craft the Implementation Plan<\/a><\/li>\n<\/ul>\n\t\t\t<a href=\"https:\/\/conexiam.com\/download-enterprise-architecture-governance-guide\/\" target=\"_self\">\n\t\t\t\t\t\t\tDownload the Enterprise Architecture Governance Guide\n\t\t\t<\/a>\n\t\t\t\t<img decoding=\"async\" data-src=\"https:\/\/conexiam.com\/wp-content\/uploads\/2022\/08\/AdobeStock_83825573-600x400.jpeg\" alt=\"TOGAF 10 Phase F Implementation Plan\" itemprop=\"image\" height=\"400\" width=\"600\" title=\"TOGAF 10 Phase F Implementation Plan\" onerror=\"this.style.display='none'\" src=\"data:image\/svg+xml;base64,PHN2ZyB3aWR0aD0iMSIgaGVpZ2h0PSIxIiB4bWxucz0iaHR0cDovL3d3dy53My5vcmcvMjAwMC9zdmciPjwvc3ZnPg==\" class=\"lazyload\" style=\"--smush-placeholder-width: 600px; --smush-placeholder-aspect-ratio: 600\/400;\" data-srcset=\"https:\/\/conexiam.com\/wp-content\/uploads\/2022\/08\/AdobeStock_83825573-600x400.jpeg 600w, https:\/\/conexiam.com\/wp-content\/uploads\/2022\/08\/AdobeStock_83825573-768x512.jpeg 768w, https:\/\/conexiam.com\/wp-content\/uploads\/2022\/08\/AdobeStock_83825573-18x12.jpeg 18w, https:\/\/conexiam.com\/wp-content\/uploads\/2022\/08\/AdobeStock_83825573.jpeg 1200w\" data-sizes=\"auto\" data-original-sizes=\"(max-width: 600px) 100vw, 600px\" \/>\n\t<h2>TOGAF ADM Overview<\/h2>\n<p>The TOGAF ADM sets the <a href=\"https:\/\/conexiam.com\/what-is-the-togaf-framework\/\">TOGAF Framework<\/a> apart from other <a href=\"https:\/\/conexiam.com\/the-three-types-of-enterprise-architecture-framework\/\">enterprise architecture frameworks<\/a>. It is the only enterprise architecture framework that includes all <a href=\"https:\/\/conexiam.com\/what-is-an-enterprise-architecture-framework\/#important\">three parts of a framework<\/a> &#8211; how to document an architecture, <a href=\"https:\/\/conexiam.com\/enterprise-architecture\/enterprise-architecture-consulting\/#develop\">how to build an enterprise architecture team<\/a>, and <a href=\"https:\/\/conexiam.com\/togaf-adm-phases-explained\/\">how to develop an architecture<\/a>.<\/p>\n<h3><a href=\"https:\/\/conexiam.com\/togaf-adm-phases-explained\/\">TOGAF ADM Develops an Enterprise Architecture<\/a><\/h3>\n<p>Each <a href=\"https:\/\/conexiam.com\/togaf-adm-phases-explained\/\">TOGAF ADM<\/a> phase explains the activities to develop knowledge. Each ADM Phase develops knowledge about part of the <a href=\"https:\/\/conexiam.com\/what-is-enterprise-architecture-complete-guide\/\">enterprise architecture<\/a>. The interactions between the Phases are information flows. These information flows coalesce into a few critical deliverables &#8211; one is the TOGAF ADM Phase F Implementation Plan.<\/p>\n<h2>What is TOGAF Phase F?<\/h2>\n<p>TOGAF Phase F provides the steps and information inputs for enterprise architects to support planners in crafting an Implementation Plan. It is a clear best practice for the enterprise architects to support planners. Their role is to ensure the stakeholder&#8217;s decisions in the architecture are reflected in the plan. Where prior decisions are not reflected in the Implementation Plan, the enterprise architecture must be updated. Only when your enterprise commits to a change is the candidate enterprise architecture finally approved.<\/p>\n<h3>What is the Objective of TOGAF ADM Phase F?<\/h3>\n<p>The objective of Phase F is to transition from the <a href=\"https:\/\/conexiam.com\/roadmapping-as-design\/\">Architecture Roadmap<\/a> developed in <a href=\"https:\/\/conexiam.com\/togaf-adm-phase-e-build-the-architecture-roadmap\/\">TOGAF ADM Phase E<\/a> to an Implementation Plan. The architecture roadmap has already winnowed out poor change options. The Implementation Plan is how your organization intends to execute change and reach the transition states.<\/p>\n<p>When we explain enterprise architecture, we speak about considering possible change, weighing options. All that is in the past. The Architecture roadmap points the path forward, potential transition points. It is time for the last selection.<\/p>\n<p>Success requires:<\/p>\n<ul>\n<li>You decide how to execute change (Projects)<\/li>\n<li>You know the resources that will be marshalled to deliver the change<\/li>\n<li>You know the benefits required, and constraints imposed (Architecture Contract)<\/li>\n<\/ul>\n<h3>Interaction with TOGAF <a href=\"https:\/\/conexiam.com\/togaf-adm-phase-b-develop-the-business-architecture\/\">Phase B<\/a>, <a href=\"https:\/\/conexiam.com\/togaf-adm-phase-c-develop-the-application-architecture\/\">Phase C<\/a> <a href=\"https:\/\/conexiam.com\/togaf-adm-phase-d-develop-the-technology-architecture\/\">Phase D<\/a>, and <a href=\"https:\/\/conexiam.com\/togaf-adm-phase-e-build-the-architecture-roadmap\/\">Phase E<\/a><\/h3>\n<p>While waterfall approaches do not deliver good architecture, there should be a sharp break between an Architecture Roadmap and crafting an Implementation Plan. Exploring and discarding potential change is a valuable outcome in enterprise architecture. Phase F enters a hard, practical world.<\/p>\n<p>Portfolio planners, Program Managers, and Project Managers do not live in a world of possibilities. They live in a hard world of execution. They speak of things like the <a href=\"https:\/\/en.wikipedia.org\/wiki\/Project_management_triangle\">iron triangle<\/a>. They expect to learn the destination, the expected benefits, and constraints. They intend to drag everyone over the finish line.<\/p>\n<p>While the TOGAF Standard says you will not complete the target architecture until Phase F, your architecture will only change when your organization refuses to proceed. Otherwise, architecture development is complete.<\/p>\n<h2>What is an Architecture Implementation Plan?<\/h2>\n<p>An Implementation Plan provides a schedule of the projects that will realize the Target Architecture. The executable projects will be grouped into managed portfolios and programs. The <a href=\"https:\/\/conexiam.com\/roadmapping-as-design\/#4.1.6\">Implementation Strategy<\/a> states the approach to change.<\/p>\n<p>Let&#8217;s unpack the Implementation Plan definition. First, the Implementation Plan is a schedule. It links projects in time.<\/p>\n<p>Second, it is based on a project. We know from <a href=\"https:\/\/www.pmi.org\/\">PMI<\/a> that every project is a set of interdependent tasks that have a common goal. Projects characteristics:<\/p>\n<ul>\n<li>A clear start and end date. They will have a clear beginning, a definite end, and an overview of what happens in between<\/li>\n<li>They create something new. They are a onetime unique activity. It is never repeated the same way again<\/li>\n<li>It has clear boundaries. They operate within constraints of time, money, quality, and functionality<\/li>\n<li>It is never business as usual. It changes business as usual<\/li>\n<\/ul>\n<p>Third, it groups the projects into <a href=\"#techniques\">Portfolios<\/a> and <a href=\"#techniques\">Programs<\/a> for management.<\/p>\n<p>Last, it states how change will proceed. The <a href=\"https:\/\/conexiam.com\/roadmapping-as-design\/#4.1.6\">Implementation Strategy<\/a> will require a change be:<\/p>\n<ul>\n<li>Evolutionary<\/li>\n<li>Revolutionary<\/li>\n<li>Greenfield<\/li>\n<\/ul>\n<h2>Why is an Implementation Plan Different from an Architecture Roadmap?<\/h2>\n<p>The TOGAF Standard ADM separates Phase E and Phase F, and the Architecture Roadmap from the Implementation and Migration Plan. The separation is based on best-practice planning. An architecture roadmap supports deciding your path, destination, and where decisions still have not been made. It also supports identifying where there are unresolved forks in the journey. The implementation and migration plan only support execution.<\/p>\n<p>We can guarantee that your current roadmaps look more like Implementation Plans than Architecture Roadmaps. However, we rarely see the work broken into discrete projects, and the projects linked into Portfolio and Program for management. Usually, it is a single extensive project. Rarely is the Implementation Strategy explicit, which leads to the project trying to decide inside the project what is the best approach. They always decide on the path that is easiest for the project.<\/p>\n<p>Real implementation plan development is done with stakeholders, resource owners, and your enterprises planners. The enterprise architect is there to highlight the expected value, dependency, and implementation strategy. We have already assessed value. You have transition architectures. This is an exercise in planning to deliver what is expected, not figure out what is reasonable.<\/p>\n\t\t\t<a href=\"https:\/\/conexiam.com\/download-enterprise-architecture-governance-guide\/\" target=\"_self\">\n\t\t\t\t\t\t\tDownload the Enterprise Architecture Governance Guide\n\t\t\t<\/a>\n\t<h2>TOGAF ADM Phase F Implementation Plan Deliverables<\/h2>\n<p>The two central outcomes of Phase F are an implementation plan and architecture contract. This is the action part of the enterprise architecture.<\/p>\n<p>Most valuable use of the Implementation Plan<\/p>\n<ol>\n<li>Defining the change plan. Identify what will change, and by when<\/li>\n<li>Defining the type of change through the Implementation Strategy<\/li>\n<li>Defining the control through Portfolio and Program<\/li>\n<\/ol>\n<p>An Implementation Plan will help answer the following questions:<\/p>\n<ul>\n<li>When change will happen &#8211; <a href=\"#techniques\">Implementation Plan&#8217;s Projects<\/a><\/li>\n<li>What must and must not change &#8211; <a href=\"#techniques\">Implementation Plan&#8217;s Projects<\/a><\/li>\n<li>What kind of change will happen &#8211; <a href=\"https:\/\/conexiam.com\/roadmapping-as-design\/#4.1.6\">Implementation Strategy<\/a><\/li>\n<li>What set of work is focused on specific outcomes &#8211; <a href=\"#techniques\">Implementation Plan&#8217;s Portfolio<\/a><\/li>\n<li>What set of work will be executed together &#8211; <a href=\"#techniques\">Implementation Plan&#8217;s Program<\/a><\/li>\n<\/ul>\n<p>An Architecture Contract will help answer the following questions:<\/p>\n<ul>\n<li>What tangible and intangible benefit is expected &#8211; <a href=\"#techniques\">Architecture Contract &#8211; Benefit<\/a><\/li>\n<li>When constraints limit the freedom of the implementers &#8211; <a href=\"#techniques\">Architecture Contract &#8211; Architecture Specification<\/a><\/li>\n<li>How risks and uncertainty will be addressed &#8211; <a href=\"#techniques\">Architecture Contract &#8211; Control<\/a><\/li>\n<li>What change is expected &#8211; <a href=\"#techniques\">Architecture Contract &#8211; Implementation Strategy<\/a><\/li>\n<li>What change is out of bounds &#8211; <a href=\"#techniques\">Architecture Contract &#8211; Transition<\/a> &amp; Benefit<\/li>\n<\/ul>\n<p>An Implementation Plan is an enterprise change execution tool. It pulls together execution and marshals an organization.<\/p>\n<h2>Completion of Phase F Implementation Plan<\/h2>\n<p>All TOGAF ADM Phases lead you to developing the knowledge you need. The outcome of Phase F is an Implementation Plan and supporting Architecture Contract.<\/p>\n<table>\n<tbody>\n<tr>\n<td width=\"33%\"><strong>Output &amp; Outcome<\/strong><\/td>\n<td width=\"67%\"><strong>Essential Knowledge<\/strong><\/td>\n<\/tr>\n<tr>\n<td>An approved set of projects<a href=\"#_ftn1\" name=\"_ftnref1\">[1]<\/a>, containing the objective and any necessary constraints, resources required, and start and finish dates.<\/td>\n<td>Resources available to undertake the change.\nHow stakeholder priority and preference adjust in response to value, effort, and risk of change. (Stakeholder Requirements)<\/td>\n<\/tr>\n<\/tbody>\n<\/table>\n<p>Table from <a href=\"https:\/\/conexiam.com\/download-the-enterprise-architecture-practitioners-guide\/\">TOGAF Series Guide: Enterprise Architect&#8217;s Guide to Developing Architecture<\/a><\/p>\n<h2>Phase F Bare Bones<\/h2>\n<p>In Phase F, the change planners perform most of the heavy lifting. Implementation Plans require a commitment to work.<\/p>\n<p>The bare bones of Phase F are:<\/p>\n<ul>\n<li>What will change and when &#8211; <a href=\"#techniques\">Implementation Plan&#8217;s Projects<\/a><\/li>\n<li>What kind of change will happen &#8211; <a href=\"https:\/\/conexiam.com\/roadmapping-as-design\/#4.1.6\">Implementation Strategy<\/a><\/li>\n<li>How change will be managed to an outcome &#8211; <a href=\"#techniques\">Implementation Plan&#8217;s Portfolio<\/a><\/li>\n<li>How change will be managed as work &#8211; <a href=\"#techniques\">Implementation Plan&#8217;s Program<\/a><\/li>\n<li>What benefit will be delivered &#8211; <a href=\"#techniques\">Architecture Contract<\/a><\/li>\n<li>What constraints limit the freedom of the implementers &#8211; <a href=\"#techniques\">Architecture Contract<\/a><\/li>\n<\/ul>\n<p>We always feel liberated in Phase F. The broad architecture possibilities narrow down to a single thread. All the complex trade-off is behind us, and we are down to the hard negotiation of resource and time. Frankly, if our Architecture Roadmap doesn&#8217;t have a handle on the boundary of scope and quality, we were not ready for Implementation Planning.<\/p>\n<ul>\n<li>What will change and when<\/li>\n<\/ul>\n<p>Work packages assigned to Projects. One or more Projects reaching to a Transition State, or the final Target. What will change? When will it happen?<\/p>\n<p>You will need to explain Transition States. Implementers are concrete realists. They will identify with the target state and seek to drive there. As a result, they will want to move past a Transition State. They will be very uncomfortable with the idea that a stakeholder will get to a Value Resting Points as a synonym and execute an off-ramp.<\/p>\n<p>What work, what scope, when. It is all in the <a href=\"#techniques\">Implementation Plan&#8217;s Projects<\/a>.<\/p>\n<ul>\n<li>What kind of change will happen<\/li>\n<\/ul>\n<p>Never leave the type of change to a Project team. They have an end-goal and will cut any corner to claim victory. Therefore, systems are <em>not<\/em> decommissioned. This is why legacy processes <em>last forever<\/em>. If you are expecting replacement, it is Greenfield. If you are expecting enhancement, it is Evolutionary. Be clear, and then in <a href=\"https:\/\/conexiam.com\/togaf-adm-phase-g-ensure-value-with-implementation-governance\/\">Phase G Implementation Governance<\/a> test for compliance. Use your most powerful <a href=\"https:\/\/conexiam.com\/enterprise-architecture-governance\/#implementation-governance\">implementation governance<\/a> tools, the <a href=\"https:\/\/conexiam.com\/roadmapping-as-design\/#4.1.6\">Implementation Strategy<\/a>.<\/p>\n<ul>\n<li>How change will be managed to an outcome<\/li>\n<\/ul>\n<p>The Project Management profession invented the concept of Portfolio and Program to solve for the problem of managing a complex set of projects. People doing the work have trouble seeing how they fit together. They look at very immediate reward and will fixate on tangible delivery at the end of the project. When your enterprise architecture has one or more transition states, you need additional <a href=\"https:\/\/conexiam.com\/enterprise-architecture-governance\/#implementation-governance\">implementation governance<\/a>.<\/p>\n<p>Grouping projects by outcome, and having someone responsible for the outcome, simplifies implementation governance. Best practice architecture governance uses natural authority structures. Portfolio management is a natural structure. Help your stakeholders create their <a href=\"#techniques\">Implementation Plan&#8217;s Portfolio<\/a>.<\/p>\n<ul>\n<li>How change will be managed as work<\/li>\n<\/ul>\n<p>Portfolio is used to group for the outcome. Program is used to group for execution. When you are grouping projects by execution, you are simplifying <a href=\"https:\/\/conexiam.com\/enterprise-architecture-governance\/#implementation-governance\">implementation governance<\/a>. Like Portfolio grouping follow <a href=\"https:\/\/conexiam.com\/basics-of-enterprise-architecture-governance\/\" data-wpil=\"url\">best practice architecture governance<\/a> and adopt a natural authority structure. Help your stakeholders create their <a href=\"#techniques\">Implementation Plan&#8217;s Program<\/a>.<\/p>\n<ul>\n<li>What benefit will be delivered<\/li>\n<\/ul>\n<p>We developed the concept of Architecture Contract to separate benefit, or value, from a project description. Project teams look to the end of the project. Project teams look to their sponsor&#8217;s needs. You can expect Implementers to drop benefits that are not directly aligned with their project. You can expect the drop to be framed as de-risking or lowering cost.<\/p>\n<p>To provide clear direction and control, use the <a href=\"#techniques\">Architecture Contract<\/a> to have the benefit, or value. Especially if you are building <a href=\"https:\/\/conexiam.com\/what-is-business-architecture\/#models\">capability<\/a> or ensuring future <a href=\"https:\/\/conexiam.com\/what-is-enterprise-agility\/#what\">enterprise agility<\/a>.<\/p>\n<ul>\n<li>What constraints limit the freedom of the implementers<\/li>\n<\/ul>\n<p>If you do not have something you <em>must<\/em> control, you need to stay away from Architecture Specifications. Architecture Specifications always block innovation and limit the creativity and knowledge of your implementation teams.<\/p>\n<p>When you need something, use an Architecture Specification in the <a href=\"#techniques\">Architecture Contract<\/a>. In <a href=\"https:\/\/conexiam.com\/conexiam-navigate\/\">Navigate\u2122<\/a>, we use four types of Architecture Specification:<\/p>\n<ul>\n<li>Principle, where general guidance on how to decide is appropriate<\/li>\n<li>Pattern, where there is a known preferred approach<\/li>\n<li>Standard, where there is a known acceptable approach<\/li>\n<li>Rule, where all choices must be removed<\/li>\n<\/ul>\n<p>We expect our enterprise architects to always have a Standard before they craft a Rule. Test their Standard against a Pattern. Ensure the Pattern meets the Principle. We do this to ensure that we have limited the Implementers&#8217; degrees of freedom as little as possible. Writing a Rule is easy, but it requires near omniscience. You must look forward and know the unique circumstances and future abilities. Or get the Rule wrong.<\/p>\n<p>The three completion essentials of Phase F:<\/p>\n<ul>\n<li>First, definition of done. When will we get to a Transition State?<\/li>\n<li>Second, accountability for change. Who is accountable for what Portfolio or Program?<\/li>\n<li>Third, rules of the road. What benefit will be delivered? What constraint is imposed?<\/li>\n<\/ul>\n<p>With these three essentials, the stakeholders are ready to develop an Implementation Plan. They know what they want done. They know what they do not want changed. They know how they have limited their implementers.<\/p>\n<h2>TOGAF ADM Phase F &#8211; Implementation Plan Deliverables and Enterprise Architecture Purposes<\/h2>\n<p>There are four core purposes for developing enterprise architecture. Either you are supporting Strategy, Portfolio, Project, or Solution Delivery. In most circumstances, you will not develop an Architecture Roadmap unless you are supporting Strategy or Portfolio. The patterns are explained in the <a href=\"https:\/\/conexiam.com\/download-the-enterprise-architecture-practitioners-guide\/\">Enterprise Architect&#8217;s Guide to Developing Architecture<\/a>.<\/p>\n<p>Different deliverables have different importance in each purpose.<\/p>\n<h3><a href=\"https:\/\/conexiam.com\/developing-enterprise-architecture-strategy\/\">Architecture to Support Strategy<\/a><\/h3>\n<p>When you are supporting strategy, you will provide an end-to-end Target Architecture and develop roadmaps of change. Your architecture will identify change initiatives and supporting portfolio and programs. The architecture roadmap will set terms of reference, identify synergies, and govern the execution of portfolio and programs.<\/p>\n<h3><a href=\"https:\/\/conexiam.com\/what-is-architecture-to-support-portfolio\/\">Architecture to support Portfolio<\/a><\/h3>\n<p>When you are supporting a portfolio, you will normally address the single portfolio. Your architecture will identify projects, and set their terms of reference, align their approaches, identify synergies, and govern the project&#8217;s execution.<\/p>\n<table>\n<tbody>\n<tr>\n\n<td><strong>Architecture to Support Strategy<\/strong><\/td>\n<td><strong>Architecture to Support Portfolio<\/strong><\/td>\n<td><strong>Architecture to Support Project<\/strong><\/td>\n<td><strong>Architecture to Support Solution Delivery<\/strong><\/td>\n<\/tr>\n<tr>\n<td><strong>Phase F Work Product: Architecture Implementation Plan<\/strong><\/td>\n<td>Likely not used<\/td>\n<td><strong>Key Deliverable<\/strong>\n<p>During portfolio budgeting<\/p>\nRefresh as required to support budgeting and program management<\/td>\n<td><strong>Key Deliverable<\/strong>\nBefore project start<\/td>\n<td><strong>Key Deliverable<\/strong>\nBefore engagement and contracting<\/td>\n<\/tr>\n<tr>\n<td><strong>Phase F Work Product: Architecture Contract<\/strong><\/td>\n<td>Likely not used<\/td>\n<td>Limited use<\/td>\n<td><strong>Key Deliverable<\/strong>\nBefore completion of project initiation<\/td>\n<td><strong>Key Deliverable<\/strong>\nBefore engagement and contracting<\/td>\n<\/tr>\n<tr>\n<td><strong>Phase F Work Product: Target Enterprise Architecture<\/strong><\/td>\n<td>Important deliverable\nUsed for record keeping and future architecture development<\/td>\n<td>Important deliverable\nUsed for record keeping and future architecture development<\/td>\n<td>Mostly superior architecture\nUsed for record keeping and future architecture development<\/td>\n<td>Superior Architecture<\/td>\n<\/tr>\n<\/tbody>\n<\/table>\n<p>Table from <a href=\"https:\/\/conexiam.com\/download-the-enterprise-architecture-practitioners-guide\/\">TOGAF Series Guide: Enterprise Architect&#8217;s Guide to Developing Architecture<\/a><\/p>\n<h3>Implementation Plan<\/h3>\n<p>The structure of your Implementation Plan changes whether you are working to support strategy, portfolio, or project. Implementation Plans are used to <a href=\"https:\/\/conexiam.com\/basics-of-enterprise-architecture-governance\/\" data-wpil=\"url\">govern implementation<\/a>.<\/p>\n<table>\n<tbody>\n<tr>\n<td width=\"140\"><strong>\u00a0<\/strong><\/td>\n<td width=\"125\"><a href=\"https:\/\/conexiam.com\/navigate-atlas-to-support-strategy\/\"><strong>Architecture to support Strategy<\/strong><\/a><\/td>\n<td width=\"125\"><a href=\"https:\/\/conexiam.com\/what-is-architecture-to-support-portfolio\/\"><strong>Architecture to support Portfolio<\/strong><\/a><\/td>\n<td width=\"125\"><strong>Architecture to support Project<\/strong><\/td>\n<td width=\"109\"><strong>Architecture to support Solution Delivery<\/strong><\/td>\n<\/tr>\n<tr>\n<td width=\"140\"><a href=\"#deliverables\"><strong>Implementation Plan Projects<\/strong><\/a><\/td>\n<td width=\"125\">Summary<\/td>\n<td width=\"125\">Key Deliverable<\/td>\n<td width=\"125\">Superior Architecture<\/td>\n<td width=\"109\">Superior Architecture<\/td>\n<\/tr>\n<tr>\n<td width=\"140\"><a href=\"#deliverables\"><strong>Implementation Plan Strategy<\/strong><\/a><\/td>\n<td width=\"125\">Appropriate to Project<\/td>\n<td width=\"125\">Key Deliverable<\/td>\n<td width=\"125\">Key Deliverable or Superior Architecture<\/td>\n<td width=\"109\">Superior Architecture<\/td>\n<\/tr>\n<tr>\n<td width=\"140\"><a href=\"#deliverables\"><strong>Implementation Plan Portfolio<\/strong><\/a><\/td>\n<td width=\"125\">Key Deliverable<\/td>\n<td width=\"125\">Key Deliverable<\/td>\n<td width=\"125\">Superior Architecture<\/td>\n<td width=\"109\">Superior Architecture<\/td>\n<\/tr>\n<tr>\n<td width=\"140\"><a href=\"#deliverables\"><strong>Implementation Plan Program<\/strong><\/a><\/td>\n<td width=\"125\">Key Deliverable<\/td>\n<td width=\"125\">Key Deliverable<\/td>\n<td width=\"125\">Superior Architecture<\/td>\n<td width=\"109\">Superior Architecture<\/td>\n<\/tr>\n<\/tbody>\n<\/table>\n<h3>Architecture Contract<\/h3>\n<table>\n<tbody>\n<tr>\n<td width=\"136\"><strong>\u00a0<\/strong><\/td>\n<td width=\"126\"><a href=\"https:\/\/conexiam.com\/navigate-atlas-to-support-strategy\/\"><strong>Architecture to support Strategy<\/strong><\/a><\/td>\n<td width=\"126\"><a href=\"https:\/\/conexiam.com\/what-is-architecture-to-support-portfolio\/\"><strong>Architecture to support Portfolio<\/strong><\/a><\/td>\n<td width=\"126\"><strong>Architecture to support Project<\/strong><\/td>\n<td width=\"109\"><strong>Architecture to support Solution Delivery<\/strong><\/td>\n<\/tr>\n<tr>\n<td width=\"136\"><a href=\"#deliverables\"><strong>Architecture Contract &#8211; Benefit<\/strong><\/a><\/td>\n<td width=\"126\">Appropriate to Project<\/td>\n<td width=\"126\"><strong>Key Deliverable<\/strong><\/td>\n<td width=\"126\"><strong>Key Deliverable<\/strong> or Superior Architecture<\/td>\n<td width=\"109\">Superior Architecture<\/td>\n<\/tr>\n<tr>\n<td width=\"136\"><a href=\"#deliverables\"><strong>Architecture Contract &#8211; Architecture Specification<\/strong><\/a><\/td>\n<td width=\"126\">Principle<\/td>\n<td width=\"126\">Principle &amp; Pattern<\/td>\n<td width=\"126\">Principle, Pattern, &amp; Standard<\/td>\n<td width=\"109\">Principle, Pattern, Standard, &amp; Rule<\/td>\n<\/tr>\n<tr>\n<td width=\"136\"><a href=\"#deliverables\"><strong>Architecture Contract &#8211; Control<\/strong><\/a><\/td>\n<td width=\"126\">Appropriate to Project<\/td>\n<td width=\"126\"><strong>Key Deliverable<\/strong> appropriate to Project<\/td>\n<td width=\"126\"><strong>Key Deliverable<\/strong> or Superior Architecture<\/td>\n<td width=\"109\"><strong>Key Deliverable<\/strong> or Superior Architecture<\/td>\n<\/tr>\n<tr>\n<td width=\"136\"><a href=\"#deliverables\"><strong>Architecture Contract &#8211; Implementation Plan Strategy<\/strong><\/a><\/td>\n<td width=\"126\">Appropriate to Project<\/td>\n<td width=\"126\">Key Deliverable<\/td>\n<td width=\"126\"><strong>Key Deliverable<\/strong> or Superior Architecture<\/td>\n<td width=\"109\">Superior Architecture<\/td>\n<\/tr>\n<tr>\n<td width=\"136\"><a href=\"#deliverables\"><strong>Architecture Contract &#8211; Transition<\/strong><\/a><\/td>\n<td width=\"126\"><strong>Key Deliverable<\/strong><\/td>\n<td width=\"126\"><strong>Key Deliverable<\/strong> or Superior Architecture<\/td>\n<td width=\"126\"><strong>Key Deliverable<\/strong> or Superior Architecture<\/td>\n<td width=\"109\">Superior Architecture<\/td>\n<\/tr>\n<\/tbody>\n<\/table>\n<h3>Target Enterprise Architecture<\/h3>\n<p>The complete <a href=\"https:\/\/conexiam.com\/enterprise-architecture-model-a-quick-overview-of-the-basics\/\" target=\"_blank\" rel=\"noopener\">enterprise architecture will comprise the domain architecture models<\/a> and the set of consolidated gaps. As a deliverable, you are updating the Target Enterprise Architecture to use in future Architecture Development, or as a reference in Phase G Implementation Governance.<\/p>\n<p>Models that comprise the Target Enterprise Architecture<\/p>\n<ul>\n<li>&gt;&gt;&gt; <a href=\"https:\/\/conexiam.com\/what-is-business-architecture\/#models\">Business Architecture Models<\/a><\/li>\n<li>&gt;&gt;&gt; <a href=\"https:\/\/conexiam.com\/togaf-adm-phase-c-develop-the-application-architecture\/#techniques\">Application Architecture Models<\/a><\/li>\n<li>&gt;&gt;&gt; <a href=\"https:\/\/conexiam.com\/togaf-adm-phase-d-develop-the-technology-architecture\/#techniques\">Technology Architecture Models<\/a><\/li>\n<li>&gt;&gt;&gt; <a href=\"https:\/\/conexiam.com\/roadmapping-as-design\/#4.1\">Architecture Roadmap Techniques<\/a><\/li>\n<\/ul>\n<h2>What is the role of the Enterprise Architect in Phase F?<\/h2>\n<p>In TOGAF Phase F, we expect the Enterprise Architect to advise planners. They will need to interpret the target architecture, and any transitions. Most critically they will ensure that expected benefit and constraint are captured in the plans.<\/p>\n<p>Architects are used to planning sequences of work that deliver unexpected benefits. Or expecting the need for a constraint. The Enterprise Architect will need to explain Transition States.<\/p>\n<p>Project planners have brief time-horizons and are very direct thinkers. They will be uncomfortable with:<\/p>\n<ul>\n<li>Intangible benefits<\/li>\n<li>Deferred realization of benefit<\/li>\n<li>Constraint that hinders the current project<\/li>\n<\/ul>\n<p>Regarding benefit we always use the example of building a bridge. The ramp, and the supports are necessary, but deliver no incremental value. Also, until you finish the entire road-deck, the bridge provides no realizable value. It helps people understand we may be doing a great deal of work, simply to do more work before we\u00a0 can realize a significant benefit.<\/p>\n<p>We find speaking about highways and interchanges helps them understand constraints that hinder the current project. As traffic volume increases, the costs for the roadbed and asphalt increase dramatically. Until we build the bridge, traffic volume is low, so spend on roadbed simply drives up the cost of the current project. When the road, the bridge, and the interchange come together, you have a traffic network that can sustain the volume. One that delivers value. One that doesn&#8217;t require ripping up the road in use and re-building it.<\/p>\n<p>The most important role of the enterprise architect is thinking ahead and crossing boundaries. They will understand why the current project might be constrained, or the success criteria are not obvious. They will help engage Portfolio owners when the project sponsor is removing enterprise benefit.<\/p>\n<h3>Two Central Facts about TOGAF Phase F &#8211; Implementation Plan<\/h3>\n<p>Take a pragmatic approach to <a href=\"https:\/\/conexiam.com\/three-steps-to-build-an-effective-enterprise-architecture-team\/\">building your enterprise architecture teams<\/a>. We base the pragmatic approach on an uncomfortable fact &#8211; if normal thinking delivered flexible, efficient organizations, our profession would not exist. Enterprise architecture requires abnormal thinking.<\/p>\n<p>There are two central facts we tell <a href=\"https:\/\/conexiam.com\/what-is-an-enterprise-architect\/\">enterprise architects<\/a> about TOGAF Phase F &#8211; Architecture Roadmap. First, other than your Stakeholder, no one involved in Implementation Planning will believe anything you say. Your ideas will always be too big, too deferred, to theoretical. You will need to watch everyone like a hawk watch for mice. They will need a strong relationship with your stakeholder. You will need to use the trade-off conversations you have already had to develop the Architecture Roadmap. In fact, you can expect to re-argue the trade-off with everyone else. Second, if you do not have a documented Architecture Contract, you will struggle with Implementation Governance. No one will remember the expected benefit, the implementation strategy, or any constraint. Ever. They will re-imagine everything during project execution (<a href=\"https:\/\/conexiam.com\/togaf-adm-phase-g-ensure-value-with-implementation-governance\/\">TOGAF ADM Phase G<\/a>) to complete the project as easily as possible to serve the tactical interests of the Project sponsor.<\/p>\n<p>Stakeholders need enterprise architects to guard the value they want. Usually, most of the guarding is from the Project sponsor and the implementation team.<\/p>\n<p><a href=\"#_ftnref1\" name=\"_ftn1\">[1]<\/a> Do not fixate on definition of the term &#8220;project&#8221; or what a project is. It is just an organizing effort for work to achieve an understood outcome. Your organization&#8217;s internal definition of a project, and the label used, will be unlikely to align with anyone else&#8217;s. My assistant refers to booking a flight as a project.<\/p>\n\t\t\t<a href=\"https:\/\/conexiam.com\/togaf-enterprise-architecture-training-course\/\" target=\"_self\">\n\t\t\t\t\t\t\tExplore TOGAF Certification Training\n\t\t\t<\/a>\n\t\t\t\t<img decoding=\"async\" data-src=\"https:\/\/conexiam.com\/wp-content\/uploads\/2022\/08\/AdobeStock_104691994-600x284.jpeg\" alt=\"TOGAF ADM Phase F Implementation Techniques\" itemprop=\"image\" height=\"284\" width=\"600\" title=\"TOGAF ADM Phase F Implementation Techniques\" onerror=\"this.style.display='none'\" src=\"data:image\/svg+xml;base64,PHN2ZyB3aWR0aD0iMSIgaGVpZ2h0PSIxIiB4bWxucz0iaHR0cDovL3d3dy53My5vcmcvMjAwMC9zdmciPjwvc3ZnPg==\" class=\"lazyload\" style=\"--smush-placeholder-width: 600px; --smush-placeholder-aspect-ratio: 600\/284;\" data-srcset=\"https:\/\/conexiam.com\/wp-content\/uploads\/2022\/08\/AdobeStock_104691994-600x284.jpeg 600w, https:\/\/conexiam.com\/wp-content\/uploads\/2022\/08\/AdobeStock_104691994-768x364.jpeg 768w, https:\/\/conexiam.com\/wp-content\/uploads\/2022\/08\/AdobeStock_104691994-18x9.jpeg 18w, https:\/\/conexiam.com\/wp-content\/uploads\/2022\/08\/AdobeStock_104691994.jpeg 1200w\" data-sizes=\"auto\" data-original-sizes=\"(max-width: 600px) 100vw, 600px\" \/>\n\t<h2>Implementation Plan Models, Tools, and Techniques<\/h2>\n<p>The TOGAF ADM Phase F delivers the Implementation Plan and Architecture Contract. This Phase exists to enable action.<\/p>\n<p>Phase F is a translation of the Architecture Roadmap and the Target Architecture to action. There are five central Implementation Plan crafting techniques that help stakeholders understand the how to realize the target architecture&#8217;s benefits.<\/p>\n<ul>\n<li>Portfolio Grouping<\/li>\n<li>Program Grouping<\/li>\n<li>Benefit Realization<\/li>\n<li>Risk Mitigation<\/li>\n<li>Architecture Contract<\/li>\n<li>Implementation Strategy Model<\/li>\n<li>Using Architecture Roadmap Techniques<\/li>\n<\/ul>\n<h2>Implementation Plan Techniques<\/h2>\n<p>Taken together, the techniques will highlight everything the Enterprise Architects have to contribute to crafting the Implementation Plan. The Enterprise Architect&#8217;s role nets down to guarding the value of the change.<\/p>\n<h3>Portfolio Planning \/ Portfolio Grouping<\/h3>\n<p>The Project Management profession uses Portfolio and Program to enable managing a complex set of projects. Project Sponsors and the Implementers look at the project&#8217;s explicit deliverables.<\/p>\n<p>Portfolio Planning groups the projects by outcome. As a specified Portfolio someone can be accountable for the outcome. This increases the possibility of success and enables implementation governance.<\/p>\n<p>The Portfolio creates a natural authority structure. The rest of the organization will adopt the authority structure and outcome-based reporting.<\/p>\n<h3>Program Planning \/ Program Grouping<\/h3>\n<p>Program groups projects for execution. Just like Portfolio, you will reach a person accountable for managing a set of related projects. An execution-oriented natural authority structure is created. The rest of the organization will adopt the authority structure and execution-based reporting.<\/p>\n<h3>Benefit Realization<\/h3>\n<p>We always align benefits of the enterprise architecture to the deficiency that started the current architecture development. We use the Architecture Roadmap and the Enterprise Architecture to <a href=\"https:\/\/conexiam.com\/enterprise-architecture-governance\/#implementation\">govern implementation<\/a>. This requires separating expected benefits from the project&#8217;s that are expected to deliver the benefit.<\/p>\n<p>In <a href=\"https:\/\/conexiam.com\/conexiam-navigate\/\">Navigate<\/a> we align a benefit to Work Package. We link Work Package to the Gap it is filling and the Project that will deliver it.<\/p>\n<p>We routinely find that during Project Initiation and Project Execution, the work that will deliver a Benefit is de-scoped, while the Benefit continues to appear on the Project&#8217;s PowerPoint slides. This is especially true when the Project Sponsor will not receive the Benefit.<\/p>\n<p>Enterprise architecture exists to guide effective change. Effective change realizes the Benefits.<\/p>\n<p>When crafting the Implementation Plan, we look for the work that will explicitly fill a Gap and deliver a Benefit. No work, and you have an unfilled Gap and a missing Benefit.<\/p>\n<h3>Risk Mitigation<\/h3>\n<p>We have two uses of the term <a href=\"https:\/\/conexiam.com\/risk-architecture-with-sabsa-domain-framework\/\">Risk<\/a>. First, it is the effect of uncertainty on meeting your objective. This is the definition used by the Risk Management Profession. We find it resonates most strongly with enterprise architecture. Second, is the normal usage where a Risk is a bad thing that can happen. We find most people think of Risk as a Threat, or Bad thing. It doesn&#8217;t matter how you use Risk. We find uncertainty and threat are addressed the same way. You address it with a control, and that control must be implemented through a Work Package.<\/p>\n<p><a href=\"https:\/\/conexiam.com\/conexiam-navigate\/\">Navigate<\/a> aligns Risk to either an Asset or an Objective. A Control mitigates the Risk. A Work Package implements Controls. \u00a0We link Work Package to the accountable Project.<\/p>\n<p>Objectives are why we are doing the change. Missing means the change was pointless. When you have an uncertainty of meeting the objective, what are you doing to reduce the uncertainty? Addressing uncertainty is critical Implementation Planning and <a href=\"https:\/\/conexiam.com\/enterprise-architecture-governance\/#implementation\">implementation governance<\/a> activity.<\/p>\n<p>Again, we separate the Risk and Control from the Project. We link through Work. This allows us to plan and monitor for de-scoping.<\/p>\n<p>We routinely find that during Project Initiation, and Project Execution Objectives and Assets that are not directly tied to the Project and Project Sponsor will be de-scoped. This is especially true when the Project Sponsor does not own the Objective.<\/p>\n<p>We routinely expected change initiatives to develop capabilities, reduce agility draining friction, lower ongoing operational costs. Yet they routinely fail. They fail because we deliver work through focused projects. Each focused project is bound by the Iron Triangle and will aggressively de-scope. We have never seen a descoping presented as a threat to an enterprise objective. They always present it as an improvement to the project.<\/p>\n<p>Enterprise Architects must address uncertainty of reaching objectives during Implementation Planning. Without this, they cannot perform <a href=\"https:\/\/conexiam.com\/enterprise-architecture-governance\/#implementation\">implementation governance<\/a> activity.<\/p>\n<h3>Architecture Contract<\/h3>\n<p>TOGAF&#8217;s concept of the Architecture Contract is incredibly powerful. Often it is presented as some form of documented agreement between the EA Team and the Project. While documenting it is useful, the contract is between the Stakeholder and the Project. It is <em>never<\/em> between the Project and the EA Team.<\/p>\n<p>When we craft an Architecture Contract, we ensure it includes:<\/p>\n<ul>\n<li><strong>Benefit<\/strong><\/li>\n<\/ul>\nWhat Benefits will the Project deliver through what Work packages?<br \/>\nThis provides visibility to the Implementers, the governance process, and the Stakeholder expecting the Benefit who is accountable, and what they are doing to deliver their accountability.\n<ul>\n<li><strong>Control<\/strong><\/li>\n<\/ul>\nWhat Controls will the Project deliver through what Work Packages? What these Controls mitigate Risks?<br \/>\nJust like the Benefit, this provides visibility to the Implementers, the governance process, and the Stakeholder expecting to realize the Objective who is accountable, and what they are doing to deliver their accountability.\n<ul>\n<li><strong>Architecture Specification<\/strong><\/li>\n<\/ul>\nWhat constraints remove freedom from the implementers?<br \/>\nThis clarifies where a project team must follow guidance that contradicts the logic of their project. If their project&#8217;s logic will drive them to follow the constraint, we do not need the Architecture Specification. We use the Architecture Specification, where the logic of the project would cause a poor choice for the enterprise.\n<ul>\n<li><strong>Implementation Plan Strategy<\/strong><\/li>\n<\/ul>\nHow to approach change<br \/>\nJust like the Architecture Specification, how must an Implementer approach the project? This is especially true where the project logic will lead them to another approach.\n<ul>\n<li><strong>Transition<\/strong><\/li>\n<\/ul>\n<p>When are we deliberately stopping short? Every minute of work on change past a Transition point is probable waste. We craft transition points to be Value Resting Points. Points in the change where the Stakeholders can delay, stop, or change direction. We use transitions for <a href=\"https:\/\/conexiam.com\/enterprise-architecture-governance\/#implementation\">implementation governance<\/a>. They help when the project logic, or preferences of the Project Sponsor will drive a project to go further than is expected. Usually with an explanation of efficiency. However, if the Sponsors, delay, stop, or change direction and the next complete Value Resting Point is not reached the project built another half-bridge.<\/p>\n<h3><a href=\"https:\/\/conexiam.com\/roadmapping-as-design\/#4.1\">Implementation Strategy<\/a><\/h3>\n<p>Whether you include the Implementation Strategy in the Architecture Contract, the Implementation Strategy is critical when crafting an Implementation Plan. The three types of change (Evolutionary, Revolutionary, and Greenfield) will drive the project design and system design.<\/p>\n<p>For example, if you require starting from scratch (Greenfield), you are expecting organization, process, and system change. You are deliberately throwing away the existing organization, process, and systems. Your project had better be designed to craft something new and lead the change management through the change.<\/p>\n<p>Frankly, legacy systems, poor processes, and rigid organizations are sustained by typing a change to the Project&#8217;s easy path (Evolutionary).<\/p>\n<h3>Using <a href=\"https:\/\/conexiam.com\/roadmapping-as-design\/#4.1\">Architecture Roadmap Techniques<\/a><\/h3>\n<p>The different techniques to develop an Architecture Roadmap are used to provide different guidance and constraint when crafting the implementation plan.<\/p>\n<ul>\n<li><a href=\"https:\/\/conexiam.com\/roadmapping-as-design\/#4.1.2\">Architecture Roadmap Type 1: Tagging with Recommendation and Heatmaps<\/a><\/li>\n<\/ul>\n<p>Heatmaps will provide guidance and constraint from attributes like value, work, risk, or transition state. They drive project design.<\/p>\n<ul>\n<li><a href=\"https:\/\/conexiam.com\/roadmapping-as-design\/#4.1.3\">Architecture Roadmap Type 2: Lifecycle Charts<\/a><\/li>\n<\/ul>\n<p>Lifecycle charts provide guidance and constraint about time. Whether the Lifecycle chart is about a system or a change, it highlights the boundaries for starting and stopping. They are powerful when a change event is needed by a certain time. It is surprising how often a late change is worthless. If you can&#8217;t have the new system in time, a new system late loses its value.<\/p>\n<ul>\n<li><a href=\"https:\/\/conexiam.com\/roadmapping-as-design\/#4.1.4\">Architecture Roadmap Type 3: Work Package Impact &amp; Dependency<\/a><\/li>\n<\/ul>\n<p>Dependency models provide guidance and constraint about dependency. Whether the dependency is work, organization, systems, or transition states. A dependency diagram will often help you understand required-by dates in a Lifecycle Chart.<\/p>\n<ul>\n<li><a href=\"https:\/\/conexiam.com\/roadmapping-as-design\/#4.1.5\">Architecture Roadmap Type 4: Scenario Analysis across Multiple Candidates<\/a><\/li>\n<\/ul>\n<p>Scenario roadmaps are rarely useful when developing an Implementation Plan.<\/p>\n<p>Complex visualization of work packages, architecture options or transition state options. Rad plot will typically represent concerns or attributes such as value, work, or risk. Points on the plot will usually represent architecture options or transition state options.<\/p>\n<p>Learn more about Conexiam&#8217;s <a href=\"https:\/\/conexiam.com\/tag\/enterprise-architecture-workshop\/#roadmap\">Architecture Roadmap Workshops<\/a><\/p>\n<h3><a href=\"https:\/\/conexiam.com\/roadmapping-as-design\/#4.1\">Transition Architecture<\/a><\/h3>\n<p>Transition Architecture provides guidance and constraint about stopping points. To deliver a value resting points, you structure projects to reach the transition state together. The most important dates in any Transition State are the &#8216;required by&#8217;, or &#8216;drop-dead&#8217; dates.<\/p>\n<h3><a href=\"https:\/\/conexiam.com\/roadmapping-as-design\/#4.3.3\">Gap &amp; Solution<\/a><\/h3>\n<p>Gaps explain what deficiency we need remediated. They help a project define scope and outcome.<\/p>\n<p>Solutions simplify design. If there is an expected solution, or solution attributes, it simplifies scope and design. This is especially true when you have selected a Greenfield, or Revolutionary, Implementation Strategy.<\/p>\n<h2>Implementation Plan Techniques Aligned to Enterprise Architecture Purpose<\/h2>\n<p>Architecture teams support different purposes. Whether you support Portfolio questions or Solution Delivery will change how you develop and use architecture roadmaps. For example, Architecture to support Solution Delivery won&#8217;t use an Architecture Roadmap Type 1: Heatmap to develop decisions. We will use it as superior architecture and a set of constraints on the architecture development and any implementation. Good architects always work within the constraints of superior architecture.<\/p>\n<table>\n<tbody>\n<tr>\n\n<td><strong>Architecture to Support Strategy<\/strong><\/td>\n<td><strong>Architecture to Support Portfolio<\/strong><\/td>\n<td><strong>Architecture to Support Project<\/strong><\/td>\n<td><strong>Architecture to Support Solution Delivery<\/strong><\/td>\n<\/tr>\n<tr>\n<td><strong>Portfolio Planning<\/strong><\/td>\n<td><strong>Key Deliverable<\/strong><\/td>\n<td><strong>Key Deliverable<\/strong><\/td>\n<td>Superior Architecture<\/td>\n<td>Superior Architecture<\/td>\n<\/tr>\n<tr>\n<td><strong>Program Planning<\/strong><\/td>\n<td><strong>Key Deliverable<\/strong><\/td>\n<td><strong>Key Deliverable<\/strong><\/td>\n<td>Superior Architecture<\/td>\n<td>Superior Architecture<\/td>\n<\/tr>\n<tr>\n<td><strong>Benefit Realization<\/strong><\/td>\n<td><strong>Key Deliverable<\/strong><\/td>\n<td><strong>Key Deliverable<\/strong><\/td>\n<td>Important Deliverable &amp; Superior Architecture<\/td>\n<td>Superior Architecture<\/td>\n<\/tr>\n<tr>\n<td><strong>Risk Mitigation<\/strong><\/td>\n<td><strong>Key Deliverable<\/strong><\/td>\n<td><strong>Key Deliverable<\/strong><\/td>\n<td>Important Deliverable &amp; Superior Architecture<\/td>\n<td>Superior Architecture<\/td>\n<\/tr>\n<tr>\n<td><strong>Architecture Contract<\/strong><\/td>\n<td>Important Deliverable<\/td>\n<td><strong>Key Deliverable<\/strong><\/td>\n<td><strong>Key Deliverable <\/strong>&amp; Superior Architecture<\/td>\n<td><strong>Key Deliverable<\/strong> &amp; Superior Architecture<\/td>\n<\/tr>\n<tr>\n<td><strong>Implementation Strategy<\/strong><\/td>\n<td>Superior Architecture<\/td>\n<td>Superior Architecture<\/td>\n<td>Superior Architecture<\/td>\n<td>Superior Architecture<\/td>\n<\/tr>\n<tr>\n<td><a href=\"https:\/\/conexiam.com\/roadmapping-as-design\/#4.1.2\"><strong>Architecture Roadmap Type 1: Heatmap<\/strong><\/a><\/td>\n<td>Superior Architecture<\/td>\n<td>Superior Architecture<\/td>\n<td>Superior Architecture<\/td>\n<td>Superior Architecture<\/td>\n<\/tr>\n<tr>\n<td><a href=\"https:\/\/conexiam.com\/roadmapping-as-design\/#4.1.3\"><strong>Architecture Roadmap Type 2: Lifecycle Chart<\/strong><\/a><\/td>\n<td>Superior Architecture<\/td>\n<td>Superior Architecture<\/td>\n<td>Superior Architecture<\/td>\n<td>Superior Architecture<\/td>\n<\/tr>\n<tr>\n<td><a href=\"https:\/\/conexiam.com\/roadmapping-as-design\/#4.1.4\"><strong>Architecture Roadmap Type 3: Dependency<\/strong><\/a><\/td>\n<td>Superior Architecture<\/td>\n<td>Superior Architecture<\/td>\n<td>Superior Architecture<\/td>\n<td>Superior Architecture<\/td>\n<\/tr>\n<tr>\n<td><a href=\"https:\/\/conexiam.com\/roadmapping-as-design\/#4.1.5\"><strong>Architecture Roadmap Type 4: Scenario<\/strong><\/a><\/td>\n<td>Superior Architecture<\/td>\n\n\n\n<\/tr>\n<tr>\n<td><a href=\"https:\/\/conexiam.com\/roadmapping-as-design\/#4.1\"><strong>Transition Architecture<\/strong><\/a><\/td>\n<td>Superior Architecture<\/td>\n<td>Superior Architecture<\/td>\n<td>Superior Architecture<\/td>\n<td>Superior Architecture<\/td>\n<\/tr>\n<tr>\n<td><a href=\"https:\/\/conexiam.com\/roadmapping-as-design\/#4.1\"><strong>Gap &amp; Solution<\/strong><\/a><\/td>\n\n<td>Superior Architecture<\/td>\n<td>Superior Architecture<\/td>\n<td>Superior Architecture<\/td>\n<\/tr>\n<\/tbody>\n<\/table>\n<h2>Implementation Plan Techniques for Enterprise Architecture Use Cases<\/h2>\n<p>Implementation Plan techniques provide better support for different <a href=\"https:\/\/conexiam.com\/enterprise-architecture-use-cases\/\">enterprise architecture use cases<\/a>. Depending on the use case, enterprise architects are more efficient in helping their stakeholders with different techniques.<\/p>\n<p>While every enterprise architecture use case is about change, the type of change and drivers are different.<\/p>\n<table>\n<tbody>\n<tr>\n\n<td><strong>Strategic Change<\/strong><\/td>\n<td><strong>Incremental Change<\/strong><\/td>\n<td><strong>Improve Cost<\/strong><\/td>\n<td><strong>Improve Quality<\/strong><\/td>\n<td><strong>Improve Enterprise Agility<\/strong><\/td>\n<td><strong>Mitigating Technology Risk<\/strong><\/td>\n<td><strong>IT Modernization<\/strong><\/td>\n<td><a href=\"https:\/\/conexiam.com\/digital-transformation\/\" target=\"_blank\" rel=\"noopener\"><strong>Digital Transformation<\/strong><\/a><\/td>\n<td><strong>Application Portfolio Rationalization<\/strong><\/td>\n<td><strong>Acquisition Integration<\/strong><\/td>\n<\/tr>\n<tr>\n<td><strong>Portfolio Planning<\/strong><\/td>\n<td>Critical<\/td>\n<td>Useful<\/td>\n\n\n<td>Critical<\/td>\n<td>Useful<\/td>\n<td>Useful<\/td>\n<td>Critical<\/td>\n<td>Useful<\/td>\n<td>Critical<\/td>\n<\/tr>\n<tr>\n<td><strong>Program Planning<\/strong><\/td>\n<td>Critical<\/td>\n<td>Very Useful<\/td>\n<td>Useful<\/td>\n<td>Useful<\/td>\n<td>Critical<\/td>\n<td>Very Useful<\/td>\n<td>Critical<\/td>\n<td>Critical<\/td>\n<td>Critical<\/td>\n<td>Critical<\/td>\n<\/tr>\n<tr>\n<td><strong>Benefit Realization<\/strong><\/td>\n<td>Critical<\/td>\n<td>Very Useful<\/td>\n<td>Critical<\/td>\n<td>Critical<\/td>\n<td>Critical<\/td>\n<td>Very Useful<\/td>\n<td>Very Useful<\/td>\n<td>Critical<\/td>\n<td>Useful<\/td>\n<td>Critical<\/td>\n<\/tr>\n<tr>\n<td><strong>Risk Mitigation<\/strong><\/td>\n<td>Critical<\/td>\n<td>Very Useful<\/td>\n<td>Critical<\/td>\n<td>Critical<\/td>\n<td>Critical<\/td>\n<td>Very Useful<\/td>\n<td>Very Useful<\/td>\n<td>Critical<\/td>\n<td>Useful<\/td>\n<td>Critical<\/td>\n<\/tr>\n<tr>\n<td><strong>Architecture Contract<\/strong><\/td>\n<td>Critical<\/td>\n<td>Useful<\/td>\n<td>Useful<\/td>\n<td>Useful<\/td>\n<td>Critical<\/td>\n<td>Critical<\/td>\n<td>Useful<\/td>\n<td>Critical<\/td>\n<td>Critical<\/td>\n<td>Critical<\/td>\n<\/tr>\n<tr>\n<td><strong>Implementation Strategy<\/strong><\/td>\n<td>Critical<\/td>\n<td>Useful<\/td>\n<td>Useful<\/td>\n<td>Useful<\/td>\n<td>Critical<\/td>\n<td>Critical<\/td>\n<td>Critical<\/td>\n<td>Critical<\/td>\n<td>Useful<\/td>\n<td>Useful<\/td>\n<\/tr>\n<tr>\n<td><a href=\"https:\/\/conexiam.com\/roadmapping-as-design\/#4.1.2\"><strong>Architecture Roadmap Type 1: Heatmap<\/strong><\/a><\/td>\n<td>Useful<\/td>\n<td>Useful<\/td>\n<td>Useful<\/td>\n<td>Useful<\/td>\n<td>Useful<\/td>\n<td>Useful<\/td>\n<td>Useful<\/td>\n<td>Useful<\/td>\n<td>Useful<\/td>\n<td>Useful<\/td>\n<\/tr>\n<tr>\n<td><a href=\"https:\/\/conexiam.com\/roadmapping-as-design\/#4.1.3\"><strong>Architecture Roadmap Type 2: Lifecycle Chart<\/strong><\/a><\/td>\n<td>Critical<\/td>\n<td>Critical<\/td>\n<td>Useful<\/td>\n<td>Useful<\/td>\n<td>Critical<\/td>\n<td>Useful<\/td>\n<td>Useful<\/td>\n<td>Critical<\/td>\n<td>Useful<\/td>\n<td>Critical<\/td>\n<\/tr>\n<tr>\n<td><a href=\"https:\/\/conexiam.com\/roadmapping-as-design\/#4.1.4\"><strong>Architecture Roadmap Type 3: Dependency<\/strong><\/a><\/td>\n<td>Critical<\/td>\n<td>Critical<\/td>\n<td>Useful<\/td>\n<td>Useful<\/td>\n<td>Critical<\/td>\n<td>Useful<\/td>\n<td>Useful<\/td>\n<td>Critical<\/td>\n<td>Useful<\/td>\n<td>Critical<\/td>\n<\/tr>\n<tr>\n<td><a href=\"https:\/\/conexiam.com\/roadmapping-as-design\/#4.1.5\"><strong>Architecture Roadmap Type 4: Scenario<\/strong><\/a><\/td>\n<td>Limited Use<\/td>\n\n\n\n<td>Limited Use<\/td>\n\n\n<td>Limited Use<\/td>\n\n<td>Useful<\/td>\n<\/tr>\n<tr>\n<td><a href=\"https:\/\/conexiam.com\/roadmapping-as-design\/#4.1\"><strong>Transition Architecture<\/strong><\/a><\/td>\n<td>Critical<\/td>\n<td>Critical<\/td>\n<td>Useful<\/td>\n<td>Useful<\/td>\n<td>Critical<\/td>\n<td>Useful<\/td>\n<td>Useful<\/td>\n<td>Critical<\/td>\n<td>Useful<\/td>\n<td>Critical<\/td>\n<\/tr>\n<tr>\n<td><a href=\"https:\/\/conexiam.com\/roadmapping-as-design\/#4.1\"><strong>Gap &amp; Solution<\/strong><\/a><\/td>\n<td>Useful<\/td>\n<td>Useful<\/td>\n<td>Useful<\/td>\n<td>Useful<\/td>\n<td>Useful<\/td>\n<td>Useful<\/td>\n<td>Useful<\/td>\n<td>Useful<\/td>\n<td>Useful<\/td>\n<td>Useful<\/td>\n<\/tr>\n<\/tbody>\n<\/table>\n<h2>Applying Enterprise Architecture Principles to Implementation Plan Development<\/h2>\n<p>Your architecture principles will drive and constrain your Implementation Plan. Our consulting practices identified <a href=\"https:\/\/conexiam.com\/7-architecture-principles-every-enterprise-architect-should-know\/\">7 Architecture Principles every enterprise architect should know<\/a>. The following table provides a simple example of how an Implementation Plan is constrained by superior architecture.<\/p>\n<p>Any Implementation Plan that doesn&#8217;t conform to the letter and spirit of superior architecture needs to be caught by <a href=\"https:\/\/conexiam.com\/basics-of-enterprise-architecture-governance\/\" data-wpil=\"url\">enterprise architecture governance<\/a> and reworked.<\/p>\n<table>\n<tbody>\n<tr>\n\n<td><strong>Implementation Plan Implication<\/strong><\/td>\n<\/tr>\n<tr>\n<td><strong>Don&#8217;t Mess With Success<\/strong><\/td>\n<td>All change needs to be assessed by the possibility it will damage current success. Potential improvement needs to be constrained to ensure the baseline is maintained.<\/td>\n<\/tr>\n<tr>\n<td><strong>Focus On Excellence<\/strong><\/td>\n<td>Change must be focused. All change without a direct line to enterprise value must be questioned. Use value definitions supporting excellence to assess the potential value of a change.\nDo not be afraid to identify changes that do not improve enterprise excellence as &#8216;<em>value free<\/em>.&#8217;<\/td>\n<\/tr>\n<tr>\n<td><strong>Why Not One?<\/strong><\/td>\n<td>Changes that create duplication need to be challenged, with value delivery decreased.\nChanges that remove duplication need to have the value delivery increased.<\/td>\n<\/tr>\n<tr>\n<td><strong>Data is an Asset<\/strong><\/td>\n<td>Ensure control of the data model is not surrendered in ways that diminish the value of data asset.<\/td>\n<\/tr>\n<tr>\n<td><strong>Systems Work Where We Work<\/strong><\/td>\n<td>Work location and work style are foundational measures of value. Any change that cannot meet location and style needs value delivery decreased.<\/td>\n<\/tr>\n<tr>\n<td><strong>Painless User Experience<\/strong><\/td>\n<td>Change costs need to be reviewed to ensure that user impact is properly assessed. Carefully look at change impact compared to potential benefit. You will always pay for impact, while you might not receive the expected benefit.<\/td>\n<\/tr>\n<tr>\n<td><strong>Self Service<\/strong><\/td>\n<td>Self-service is an enterprise value measure. Look at self-service delivery through the baseline, transition, and target states. Adjust cost and benefit assessments to reward provisioning self-service and penalizing and damage to existing self-service. You always pay for damage. You might receive a benefit.<\/td>\n<\/tr>\n<\/tbody>\n<\/table>\n<h2>How does TOGAF Phase F align with Agile Development?<\/h2>\n<p>Every Implementation Plan will provide multiple constraints and guidance for agile development. We see <a href=\"https:\/\/conexiam.com\/agile-development-and-enterprise-architecture\/\">Enterprise Architecture and Agile Development<\/a> intersecting in four areas. There are four areas where there is an intersection:<\/p>\n<ol>\n<li>define the agile approach<\/li>\n<li>guide the backlog in sprint<\/li>\n<li>constrain choices inside the sprints<\/li>\n<li>solve for cross product dependency<\/li>\n<\/ol>\n<p>The Implementation Plan will significantly affect defining the agile approach. For example, the Implement Strategy Model will force or prohibit using agile development.<\/p>\n<p>Transition states and expected Benefits will inform product development or product release, which will guide the backlog.<\/p>\n<h2>How does TOGAF Phase F enable Enterprise Agility?<\/h2>\n<p><a href=\"https:\/\/conexiam.com\/what-is-enterprise-agility\/\">Enterprise agility<\/a> \u00a0is your organization&#8217;s ability to respond to the unexpected. Implementation Plans are responding to the expected. Strong planning skills help you respond to the unexpected. There is a direct correlation in the enterprise agility model to the ability to gather information and make a resolution decision. These are planning skills.<\/p>\n<h3><a href=\"https:\/\/conexiam.com\/what-is-enterprise-agility\/\">Enterprise Agility Model<\/a><\/h3>\n<ol>\n<li>Alertness &#8211; Can you detect opportunities and threats?<\/li>\n<li>Accessibility &#8211; Can you access relevant information in time to respond?<\/li>\n<li>Decisiveness &#8211; Can you decide using the available information?<\/li>\n<li>Swiftness &#8211; Can you implement your decisions in the time available?<\/li>\n<li>Flexibility &#8211; What are you doing to reduce the barriers to action?<\/li>\n<\/ol>\n\t\t\t\t<img decoding=\"async\" data-src=\"https:\/\/conexiam.com\/wp-content\/uploads\/2022\/08\/AdobeStock_210408928.jpeg\" alt=\"TOGAF ADM Phase F Implementation Plan\" itemprop=\"image\" height=\"507\" width=\"1200\" title=\"TOGAF ADM Phase F Implementation Plan\" onerror=\"this.style.display='none'\" src=\"data:image\/svg+xml;base64,PHN2ZyB3aWR0aD0iMSIgaGVpZ2h0PSIxIiB4bWxucz0iaHR0cDovL3d3dy53My5vcmcvMjAwMC9zdmciPjwvc3ZnPg==\" class=\"lazyload\" style=\"--smush-placeholder-width: 1200px; --smush-placeholder-aspect-ratio: 1200\/507;\" data-srcset=\"https:\/\/conexiam.com\/wp-content\/uploads\/2022\/08\/AdobeStock_210408928.jpeg 1200w, https:\/\/conexiam.com\/wp-content\/uploads\/2022\/08\/AdobeStock_210408928-600x254.jpeg 600w, https:\/\/conexiam.com\/wp-content\/uploads\/2022\/08\/AdobeStock_210408928-768x324.jpeg 768w, https:\/\/conexiam.com\/wp-content\/uploads\/2022\/08\/AdobeStock_210408928-18x8.jpeg 18w\" data-sizes=\"auto\" data-original-sizes=\"(max-width: 1200px) 100vw, 1200px\" \/>\n\t\t\t<a href=\"\/personal-enterprise-architecture-kickstart\/\" target=\"_self\">\n\t\t\t\t\t\tBe a Better Enterprise Architect &#8211; Free 12-week Kickstart Program\n\t\t\t\t\t<\/a>\n\t<h2>Final Thoughts on TOGAF ADM Phase F<\/h2>\n<p>Without an Implementation Plan, the enterprise architecture is a beautiful theoretical exercise. Every <a href=\"https:\/\/conexiam.com\/enterprise-architecture\/enterprise-architecture-consulting\/#develop\">Enterprise Architecture Team<\/a> needs to excel at supporting their organization craft good Implementation Plans. Without a plan that delivers the expected benefits, or required value, most of the enterprise architecture work was wasted.<\/p>\n<p>Enterprise Architecture Teams that support project and solution delivery will need to reverse engineer a portfolio roadmap to get the guidance and constraints they need.<\/p>\n<p>Enterprise architects working in TOGAF ADM Phase F have a complex role. They must:<\/p>\n<ul>\n<li>vigilantly guard benefit delivery and risk mitigation while relaxing about how the change will be executed<\/li>\n<li>advise planners about the bigger picture without slowing down the process<\/li>\n<li>work with stakeholders to carry the change decisions into formal planning and enable change governance<\/li>\n<\/ul>\n<p>In TOGAF ADM Phase F, you move away from the <a href=\"https:\/\/conexiam.com\/enterprise-architecture-domains\/\">enterprise architecture domains<\/a> and focus on the real-world. TOGAF is very clear. We develop architecture to guide effective change. Plans are required to implement the change. We waste architecture development without the transition to a plan effort.<\/p>\n<p>High functioning EA Teams drive toward crafting Implementation Plans. Without becoming the planner. Implementation governance is possible when the planners and project sponsors understand what we expect them to deliver.<\/p>\n<p>TOGAF ADM Phase F supports crafting the Implementation Plan. Others craft the Implementation Plan. Enable action that assigns scarce change resources to the most enterprise value. Deliver on the value. Deliver effective change.<\/p>\n\t\t\t<a href=\"https:\/\/conexiam.com\/togaf-enterprise-architecture-training-course\/\" target=\"_self\">\n\t\t\t\t\t\tTake the Plunge &#8211; Get TOGAF Certified\n\t\t\t\t\t<\/a>\n<h2>\n\t\tImprove Your Enterprise Architecture Skills\n\t<\/h2>\n\t<a href=\"https:\/\/conexiam.com\/enterprise-architecture\/enterprise-architecture-training\/\">We train successful enterprise architects<\/a><br \/>\n<a href=\"https:\/\/conexiam.com\/enterprise-architecture\/enterprise-architecture-consulting\/#develop\">We develop successful enterprise architecture teams<\/a>\n\t\t\t<a href=\"https:\/\/conexiam.com\/register\/personal-kickstart\/\" target=\"_self\">\n\t\t\t\t\t\tFree 12 Week Enterprise Architect&#8217;s Kickstart\n\t\t\t\t\t<\/a>\n\t\t\t<a href=\"https:\/\/conexiam.com\/enterprise-architecture-certification\/\" target=\"_self\">\n\t\t\t\t\t\tEnterprise Architecture Training\n\t\t\t\t\t<\/a>\n\t\t\t<a href=\"https:\/\/conexiam.com\/togaf-enterprise-architecture-training-course\/\" target=\"_self\">\n\t\t\t\t\t\t\tTOGAF Enterprise Architecture Training Course\n\t\t\t<\/a>\n\n","protected":false},"excerpt":{"rendered":"<p>TOGAF\u00ae ADM Phase F &#8211; Craft the Implementation Plan TOGAF ADM Phase F crafts the Implementation Plan. Executing Implementation Plans are how enterprises directs change. A Phase F Implementation Plan will use one, two, twenty [&hellip;]<\/p>\n","protected":false},"author":1,"featured_media":11997,"comment_status":"closed","ping_status":"closed","sticky":false,"template":"","format":"standard","meta":{"_uf_show_specific_survey":0,"_uf_disable_surveys":false,"site-sidebar-layout":"default","site-content-layout":null,"ast-site-content-layout":"default","site-content-style":"default","site-sidebar-style":"default","ast-global-header-display":"","ast-banner-title-visibility":"","ast-main-header-display":"","ast-hfb-above-header-display":"","ast-hfb-below-header-display":"","ast-hfb-mobile-header-display":"","site-post-title":"disabled","ast-breadcrumbs-content":"","ast-featured-img":"disabled","footer-sml-layout":"","ast-disable-related-posts":"","theme-transparent-header-meta":"default","adv-header-id-meta":"","stick-header-meta":"default","header-above-stick-meta":null,"header-main-stick-meta":"","header-below-stick-meta":null,"astra-migrate-meta-layouts":"set","ast-page-background-enabled":"default","ast-page-background-meta":{"desktop":{"background-color":"","background-image":"","background-repeat":"repeat","background-position":"center center","background-size":"auto","background-attachment":"scroll","background-type":"","background-media":"","overlay-type":"","overlay-color":"","overlay-opacity":"","overlay-gradient":""},"tablet":{"background-color":"","background-image":"","background-repeat":"repeat","background-position":"center center","background-size":"auto","background-attachment":"scroll","background-type":"","background-media":"","overlay-type":"","overlay-color":"","overlay-opacity":"","overlay-gradient":""},"mobile":{"background-color":"","background-image":"","background-repeat":"repeat","background-position":"center center","background-size":"auto","background-attachment":"scroll","background-type":"","background-media":"","overlay-type":"","overlay-color":"","overlay-opacity":"","overlay-gradient":""}},"ast-content-background-meta":{"desktop":{"background-color":"var(--ast-global-color-5)","background-image":"","background-repeat":"repeat","background-position":"center center","background-size":"auto","background-attachment":"scroll","background-type":"","background-media":"","overlay-type":"","overlay-color":"","overlay-opacity":"","overlay-gradient":""},"tablet":{"background-color":"var(--ast-global-color-5)","background-image":"","background-repeat":"repeat","background-position":"center center","background-size":"auto","background-attachment":"scroll","background-type":"","background-media":"","overlay-type":"","overlay-color":"","overlay-opacity":"","overlay-gradient":""},"mobile":{"background-color":"var(--ast-global-color-5)","background-image":"","background-repeat":"repeat","background-position":"center center","background-size":"auto","background-attachment":"scroll","background-type":"","background-media":"","overlay-type":"","overlay-color":"","overlay-opacity":"","overlay-gradient":""}},"footnotes":""},"categories":[758,153],"tags":[],"class_list":["post-11996","post","type-post","status-publish","format-standard","has-post-thumbnail","hentry","category-blog","category-togaf"],"_links":{"self":[{"href":"https:\/\/conexiam.com\/de\/wp-json\/wp\/v2\/posts\/11996","targetHints":{"allow":["GET"]}}],"collection":[{"href":"https:\/\/conexiam.com\/de\/wp-json\/wp\/v2\/posts"}],"about":[{"href":"https:\/\/conexiam.com\/de\/wp-json\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"https:\/\/conexiam.com\/de\/wp-json\/wp\/v2\/users\/1"}],"replies":[{"embeddable":true,"href":"https:\/\/conexiam.com\/de\/wp-json\/wp\/v2\/comments?post=11996"}],"version-history":[{"count":0,"href":"https:\/\/conexiam.com\/de\/wp-json\/wp\/v2\/posts\/11996\/revisions"}],"wp:featuredmedia":[{"embeddable":true,"href":"https:\/\/conexiam.com\/de\/wp-json\/wp\/v2\/media\/11997"}],"wp:attachment":[{"href":"https:\/\/conexiam.com\/de\/wp-json\/wp\/v2\/media?parent=11996"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/conexiam.com\/de\/wp-json\/wp\/v2\/categories?post=11996"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/conexiam.com\/de\/wp-json\/wp\/v2\/tags?post=11996"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}