TOGAF ADM Phase G - Ensure Value with Implementation Governance
At a Glance
TOGAF Phase G Essential Knowledge
TOGAF ADM Phase G Deliverables
- Show-up and provide Architecture Oversight and Guidance
- Continuous Assessment
- Pull the Stop-Cord
- Assessing Value
- Align with Agile Development
TOGAF ADM Overview
The TOGAF ADM is a logical approach to creating knowledge. Knowledge used to develop an enterprise architecture that guides effective change. Then knowledge to ensure expected value is achieved.
The TOGAF ADM is broken into Phases, each Phase is focused on creating knowledge that is used to:
- select the path forward and the target
- perform implementation governance
- assess the journey forward and course correct
What is TOGAF Phase G?
All of Phase G is focused on implementation governance. Ensuing expected value is delivered.
Architects use the steps of Phase G to develop the following knowledge:
- whether the implementation project is delivering expected value
- whether the implementation project is working within its constraints
- whether the implementation project is exceeding its assigned risk appetite
When there is variance from expected value the architect creates a central work product:
- get-well recommendation
TOGAF Phase G in Action
We know the purpose is to guide effective change. The challenge is change to what outcome? Phase G brings home that we are guiding change to an outcome our stakeholders have selected.
They might want faster. They might want bigger. They might want lower carbon footprint. They might want the ability to break-up the organization.
Stakeholders want, what they want.
When developing enterprise architecture teams, we tell the architects they will spend over 60% of their time in Phase G performing implementation governance.
We also tell them it is hard. Phase G is difficult because the role requires leadership and judgement.
An electrical generation client was spending billions building distributed generation facilities. A high fraction of financial earned value came from construction labor. This was calculated by hundreds, or thousands, of spreadsheets. The board was concerned about reporting earned value.
The architecture alternative selected was to upgrade the HR system, link the time reporting to project management. Time sheet entries would be linked to project phases, and the financial reports would be defensible.
A project was funded, integrators hired, and resources were marshalled. Yet at the kick-off the project sponsor, the VP HR, talked about all the cool HR things the upgrade would do - performance management, learning. Cool HR stuff. Answering a question the lead integrator said 'no, we won't be linking to project management. That is not 'best-practice' for a the payroll module.
We were on day one of the implementation project and the project leader's had casually tossed the funding rational for the upgrade into the trash. They were not going to solve their organization's architectural problem.
They were not in compliance with the architecture contract. I needed guidance. Non-compliance leads to two real choices:
- enforce compliance
- change the architecture
Stakeholders don't always tell me when they change their minds. Maybe they wanted to change architecture. To find out, I left the kick-off and went to the COO who had championed the earned value solution to the board. I asked the COO if there was a change in plan? I wanted to know if I should re-start the initiative looking for an acceptable architecture alternative. If so, I could skip the HR upgrade.
A few days later I was invited to a new kick-off of the HR System upgrade. The COO was standing in the back of the room. The leader integrator had been replaced. The VP HR read from a written statement - apparently there had been some confusion about the project's goals. This project would solve for financial earned value. It would integrate HR-Project Systems-Finance. Unless earned value needed a process change, all existing HR processes would be sustained.
I had my answer, the stakeholders had decided to enforce compliance.
Every time I tell architects that Phase G is hard I think about that project - day after day of working with HR system specialists and HR power-users to force integration with project systems. Ensuring project systems were not impacted. It was the first time my team suggested I get a flak jacket for work.
Implementation governance is about guarding value.
Download Business Leader’s Guide to AI
Download Business Leader’s Guide to Artificial Intelligence Organizations that successfully apply innovative technology have had a competitive advantage. Innovative technology does not come with established success patterns and best practices. Innovative technology is novel and […]
Download the Introduction to the TOGAF Standard, 10th Edition
Download Introduction to the TOGAF® Standard, 10th Edition The TOGAF Standard, 10th Edition makes adoption of enterprise architecture best practices easier. It separates the universal concepts from proven best practice. The standard underscore where to […]
Download Capability-based Planning Guide
Download Capability-based Planning Guide Always drive to realize value. Half an improvement is 100% waste! No one teaches an Eagle to crawl, walk, or run. Eagles Fly! Download Teach your Eagles to Fly: Capability-based Planning […]
Download Business Architecture Capability Assessment Guide
Download Business Architecture Capability Assessment Guide Download a Business Architecture Capability Assessment Guide. Capability-based planning is one of the most powerful business architecture improvement techniques. Best practice of capability-based planning uses capability as a management […]
Download Sample Enterprise Architecture Principles
Download Sample Architecture Principles Download a sample enterprise architecture principles. Enterprise Architecture principles identify how to approach a problem or decision. The approach always drives you towards your enduring priorities. Download Sample Enterprise Architecture Principles […]
Download Enterprise Architecture Governance Guide
Download Enterprise Architecture Governance Guide Download the Enterprise Architecture Governance Guide to understand best practice to direct and control the development of architecture, and change to obtain the expected outcomes. Download Enterprise Architecture Governance Guide […]
Download TOGAF and SABSA Integration
Download TOGAF and SABSA Integration Bring SABSA, the world’s best security architecture framework, and TOGAF, the industry standard enterprise architecture framework together. Download TOGAF and SABSA Integration TOGAF and SABSA Integration Includes SABSA uses a […]
Download Enterprise Architecture Capability Reference Architecture
Download Enterprise Architecture Capability Reference Architecture The Enterprise Architecture Capability Reference Architecture will speed up establishing and enhancing your EA Team. Design your Enterprise Architecture Team for success. Identify and enhance the your enterprise architecture […]
Download Agile Enterprise Architecture Report
Download the Agile Enterprise Architecture Report The Agile Enterprise Architecture Report covers our experience – Agile Enterprise Architecture is real, practical and valuable. We do it every day. Field reports bridge the theoretical concepts and […]
Download Agile Enterprise Architecture Case Study
Download the Agile Enterprise Architecture Case Study Download the Agile Enterprise Architecture Case Study to see an example developing an EA Capability and useful architecture at the same time. We cover all six use cases […]
TOGAF Phase G Essential Knowledge
All TOGAF ADM Phases lead you to developing the knowledge you need. The Outcome of Phase G is an implementaion that delivered the extected value.
| Output & Outcome | Essential Knowledge |
| Completion of the projects to implement the changes necessary to reach the adjusted target state. |
|
Table 4 from TOGAF Series Guide: Enterprise Architect's Guide to Developing Architecture
Phase G Bare Bones
In Phase G, we can simplify the work of an enterprise architect to clarifying the architecture and developing recommendations for corrective action. The bare bones of Phase G are:
- A project's purpose?
Architecture to support Strategy and architecture to support Portfolio will both have an Architecture Roadmap. It will state synergies, terms of reference, and approaches.
Transition architecture will provide outcomes and constraints.
Guarding the value, or expected outcome, is ensuring the project's planned outcome and approach line up with the architecture.
- The constraints on the implementation team?
A good target architecture will state Gap, Architecture Requirement Specification, and Control. An implementation project exists to fill the Gap. Failing to fill the Gap and the project is a waste of change resources. Architecture Specifications and Controls are constraints on the freedom of the implementation team.
- How stakeholder priority and preference adjust in response to success, value, effort, and risk of change.
All enterprise architecture is subject to design and implementation reality. All change programs are subject to the evolving enterprise landscape and enterprise context.
In a perfect world the enterprise architect will be continuously assessing the progress of every change project and the situation the enterprise exists in. Then providing recommendations to stakeholders for finer-grained control of change resources. Imperfect knowledge and time constraints limit this feedback cycle.
The three completion essentials of Phase G depend on a project's value delivery:
- First, a successful implementation project that delivers expected value within the architecture's constraints.
- Second, a cancelled project. When a project cannot provide expected value, an enterprise's scarce change resources should be re-allocated as soon as possible.
- Third, a change of the target architecture. Change the expected value, or create a transition to what can be realized. Relax or tighten constraints.
The enterprise architecture stakeholders own the change decisions in the second and third outcomes. These are not project decisions.
Phase G Knowledge Ensures Value Delivery
Phase G is about delivery of expected value, not successful project completion.
The logic is straightforward:
- we develop a target and identify changes to improve specific things in our organization
- we implement the target to reach the expected outcomes
Any other outcome is a failure. It does not matter how successful the project is on other measures. If it does not deliver the architecture it is a failure.
Work in the Real World
The TOGAF Standard call Phase G 'Implementation Governance' for a reason. We headlined Phase G 'Ensure Value' for a reason.
We develop architecture to guide and constrain change. We look at the three elements of governance direction:
- performance expectation or expected outcome
- constraints in the form of architecture specifications, implementation strategy, and controls
- risk appetite
Enterprise Architecture Training and TOGAF Training
Effective Online Education
Effective Online Education Effective online education works. Students to access the best available instructor. Students control the pace of their learning. Instructors can share rich supplemental material without distracting from the primary topic. Effective distance […]
Avolution ABACUS Training Course
Avolution ABACUS Training Effective enterprise architecture relies on formal modeling and analysis. We provide Avolution ABACUS training from hand-on enterprise architects. Students gain skills and knowledge to create integrated enterprise and domain architectures in this […]
Custom Enterprise Architecture Training
Custom Enterprise Architecture Training Custom enterprise architecture training addresses the professional development your EA Team needs. Good enterprise architects use a broad set of skills, method, in addition to specialized domain knowledge to develop enterprise […]
Business Architecture Training Course
Business Architecture Training Effective enterprise architecture relies on business architecture. The course gives students the skills and knowledge to develop business architecture in an enterprise architecture setting. Business architecture involves describing the structure of the […]
TOGAF Enterprise Architecture Training Course
Do you want training for TOGAF Certification? Demonstrate your knowledge of enterprise architecture with TOGAF Certification TOGAF® Enterprise Architecture Training Course Take a major step to be a better enterprise architect with TOGAF Standard, 10th […]
Enterprise Architect’s Kickstart
Enterprise Architect’s Kickstart We need to keep our skills current. More now than ever. Use the Enterprise Architecture Kickstart to improve your ability to deliver transformative enterprise architecture. This 90-day kick-start is how Conexiam Consulting […]
TOGAF ADM Phase G Deliverables
The central outcome of Phase G is an improved enterprise. An improvement measured in terms expected by the stakeholder. The central deliverable of Phase G is a compliance assessment. We use a compliance assessment when the project is failing to meet the stakeholder's expectations.
The enterprise architect is accountable for an improved enterprise that meets the stakeholder's current desires. The enterprise architect is not responsible for the work, or the project.
TOGAF Phase G Compliance Assessment
| Architecture to Support Strategy | Architecture to Support Portfolio | Architecture to Support Project | Architecture to Support Solution Delivery | |
| Phase G Work Product: Conformance Assessment | Likely not used | Likely not used | Key deliverable
At key points in a project that allows reporting to stakeholders and getting decisions for non- conformance by a non-compliance recommendation. |
Key deliverable
At key points in a project that allows reporting to stakeholders and getting decisions for non- conformance by a non-compliance recommendation. |
Table 3 from TOGAF Series Guide: Enterprise Architect's Guide to Developing Architecture
Get-Well Recommendation (Non-Compliance Recommendation)
The most important part of the Compliance Assessment is the recommendation of what to do when faced with non-compliance.
Go Further with Best Practice Enterprise Architecture Process and Method
Best practice enterprise architecture from Conexiam Navigate
Making Smarter Choices: Why Your Business Needs Architectural Decisions
Making Smarter Choices: Why Your Business Needs Architectural Decisions Enterprises are constantly confronted with the challenge of making crucial decisions. Every day, decisions, including operational practices and technology selections, have a significant impact on a […]
Discover the Power of Enterprise Architecture Patterns
Discovering the Power of Enterprise Architecture Patterns: A Comprehensive Guide Every organization wants to improve. Streamline their operations. Enhance their enterprise agility. Align change with their strategies. Succeed at digital transformation. Enterprise Architecture, a discipline […]
Unlocking the Power of Capability-Based Planning: A Quick Guide
Unlocking the Power of Capability-Based Planning: A Quick Guide Are you looking for a more effective way to plan and execute your business strategy? Look no further than capability-based planning. Identifying and using your organization’s […]
Unlocking Your Business Potential: How to Create an Effective Capability Map
Unlocking Your Business Potential: How to Create an Effective Capability Map Are you struggling to identify the capabilities needed to take your business to the next level? Do you find it challenging to align resources […]
Developing an Architecture View
Developing an Architecture View Enterprise architecture is an essential compass. It helps organizations navigate the complexities of technology, strategy, and operations. The core of enterprise architecture is a systematic approach. The objective is to ensure […]
Standing-up a Modern Architecture Review Board
Standing-up a Modern Architecture Review Board Standing-up an modern architecture review board requires creating a dynamic governance process and establishing a top-level back-stop decision-making body. The objective is to establish effective architecture governance without bureaucracy. […]
Everything You Need to Know About Using Architecture Alternatives
Everything You Need to Know About Using Architecture Alternatives Architecture alternatives are required for good enterprise architecture development. When you start architecture development, your enterprise has deficiencies. There are areas for improvement. You need to […]
Understanding Enterprise Architecture and Agile
Understanding Enterprise Architecture and Agile Both agile and enterprise architecture are designed to reduce risk. Agile software development excels at building something that we have never had before and do not know how to build. […]
Enterprise Architecture Roadmap as Design
Enterprise Architecture Roadmap as Design An Architecture Roadmap is a planning tool that helps an organization’s decision-makers. A dynamic Architecture Roadmap is designed to help them develop and travel the best path forward. It also […]
Using Scenario Analysis for Enterprise Architecture
Using Scenario Analysis for Enterprise Architecture A scenario is simply a plausible future. Scenario analysis looks at how we get to a plausible future and how different scenarios impact our current choices. Scenarios help leaders […]
TOGAF ADM Phase G Techniques
In Phase G, you are creating success. Everything hinges on delivery of expected architecture value. Part of the technique is compliance based. For compliance, the architect will:
- test the designer's and implementer's choices against documented Gaps, Architecture Requirements Specifications and Controls
- test the implemented system against documented Gaps, Architecture Requirements Specifications and Controls
We stress documented. Implementation governance is based on an approved target architecture.
Part of the technique is value focused. For value, the architect looks beyond the project charter, or digital product release plan, to the architecture contract. There is often a difference between what a project is delivering to the sponsor, and what a project is delivering for the architecture. This is especially true when a portfolio roadmap has dependencies or part of a capability improvement.
Architects employ several techniques while engaged in implementation governance:
Show-up and provide Architecture Oversight and Guidance
Architecture oversight and guidance is guarding the expected value.
Think long and hard about the first test on the Implementation Governance Checklist. Architecture oversight does not include doing a designer's or implementer's job. The TOGAF 10 Enterprise Architect's Guide to Developing Architecture is very clear.
Oversight and guidance is about helping the implementers.
First, help the implementation team understand the expected value and constraints on freedom of choice.
The enterprise architect is available in Phase G when the implementation team needs help in interpreting the target architecture or any architecture constraint. The critical role of the enterprise architect is when the implementation team is not following the architecture constraints or is not on a path to deliver the expected value.
One of the most common clarifications is reminding everyone what the expected outcome is. Implementation teams routinely lose sight of the project's value.
One of the most common clarifications is reminding everyone what the expected outcome is. Implementation teams routinely lose sight of the project's expected architecture value.
The other common clarification is explaining constraints. Many enterprises jump from an architecture to support strategy or portfolio directly to an implementation project. We call this jumping to G. Typically, when you jump to G there are far fewer well documented Gaps, Architecture Requirements Specifications and Controls. The enterprise architect needs to fill in the missing documentation.
They will help stakeholders decide what to do when an implementation project is failing to deliver value or not following the constraints in the architecture.
The central outcome of Phase G is the implementation of a change. However, that work is not the responsibility of the enterprise architect. In fact, if the implementation team does an outstanding job, the enterprise architect has nothing to do in Phase G. Think about it. If they follow the architecture and implement a change that will realize the expected value, what would an enterprise architect do?
The other common clarification is explaining constraints. Many enterprises jump from an architecture to support strategy or portfolio directly to an implementation project. We call this jumping to G. Typically, when you jump to G there are far fewer well documented Gaps, Architecture Requirements Specifications and Controls. The enterprise architect needs to fill in the missing documentation.
The second key role of the enterprise architect is a non-compliance recommendation.
The role of the enterprise architect is to guard value, test the designer's and implementer's choices against documented Gaps, Architecture Requirements Specifications and Controls. They may need to rely on superior architecture, even stepping back to the enterprise architecture principles. They shouldn't invent new architecture during a project.
The implementation strategy from Phase E provides guidance and constraints on all implementation. It will state whether they expect the work to evolve the existing process and It systems, revolutionarily change them, or start afresh with a greenfield.
Continuous Assessment
Pull the Stop-Cord
The TOGAF ADM has several off-ramps. Phase G is the most expensive off-ramp. The value of a change is dependent on benefit, effort, and risk. The moment outstanding cost of change exceeds the expected benefit it is time to consider stopping.
Yes, STOP! Stop dead in your tracks.
Then celebrate that you have minimized the waste of scarce change resources.
Assessing Value
We introduced the value of the change in TOGAF ADM Phase A. In TOGAF ADM Phase E, we have confidence the benefits of the Architecture Vision are worth the work. In the TOGAF ADM Phase F, we developed the Architecture Contract. The Architecture contract defines expected value.
Keep in mind that project teams routinely confuse the potential outcomes of their change program with the value of the architecture. The more time you spend performing Implementation Governance, the more you will see implementation projects destroy the potential value of an architecture.
We always define value in the architecture. We use projects to realize the value. The architecture contract doesn't exist to make life easy for the project team, or to agree with their view of the world. It exists to ensure success improvement of the enterprise on the stakeholder's criteria.
Not all projects are successful. Not all solutions produce enough value. The sooner you know the cost exceeds the value stop. We spend a great deal of time on ITFM to ensure digital products and IT Services are cost optimized.
Align with Agile Development
Frankly, almost all Agile software development occurs inside TOGAF Phase G. Good enterprise architecture will focus on the strengths of enterprise architecture. They will allow an agile development team to focus on their strengths, incrementally delivering software that enables efficiency and customer delight.
Enterprise Architecture and Agile Development will interest on four areas. The enterprise architecture will
- define the agile approach
- guide the backlog in sprint
- constrain choices inside the sprints
- solve for cross product dependency
Enterprise architects will spend a lot of time executing implementation governance because developing an architecture takes a fraction of the time to execute a change. We do not review the architectural decisions made to guide the change. We follow them.
When we are developing enterprise architecture teams, we tell the enterprise architects two central facts about TOGAF Phase G. The first thing is that they will spend over 60% of their time in Phase G. Second, it will probably be the most difficult work they perform as an enterprise architect. Phase G will be difficult because their role is performing good architecture governance. They are not developing new architecture. They are not leading. Instead, they are guarding value realization and minimizing uncertainty of realizing the value.
Most enterprise architects spend most of their job performing implementation governance. Executing direction and control. Executing enterprise architecture governance.
Enterprise architects will spend a lot of time executing implementation governance because developing an architecture takes a fraction of the time to execute a change. We do not review the architectural decisions made to guide the change. We follow them.
Going Further into Enterprise Architecture Governance
TOGAF Phase G Tools
The TOGAF ADM Phase G is called Implementation Governance. The enterprise architect's role is to guard the expected value. There are four central architecture governance tools.
- Implementaion Checklist
- Architecture Contract
- Architecture Roadmap
- Architecture Requirement Specification
- TOGAF Compliance Assessment
Implementation Checklist
How do I use a TOGAF Architecture Contract?
An Architecture Contract identifies the responsibility of the implementation team to the architecture stakeholders. Not the project sponsor, the architecture stakeholders.
The most critical items to an implementer are:
- Implementation Project context
The contexts tells you where the project fits within the roadmap. It specifies the value or value dependency will the project provide.
- Scope
Scope tells you what work packages and gaps is the Implementation Project responsible for. As importantly, what gaps the project scope is the project not responsible for.
- Conformance
What set of architecture specifications and controls the Implementation Project will be assessed against?
How do I use a TOGAF Architecture Roadmap?
An Architecture Roadmap is a key deliverable of Architecture to support Strategy and architecture to support Portfolio. Good architecture roadmaps show how the change will be executed. In terms of Hambrick's Strategy Diamond the vehicle used to drive change will be identified. The enterprise architect will know which portfolio, program, or project is expected to deliver. They will know any transition states.
The Architecture Roadmap will also state synergies, terms of reference, and approaches. A simple example is knowing which projects are expected to evolve existing systems, which should take a revolutionary approach, and which should toss the existing environment and greenfield.
These elements allow the architect to help the stakeholders govern their execution of change projects. Consider a project expected to pursue a Greenfield. A project plan that is re-using and evolving the existing environment is non-compliant with the architecture.
How do I use a TOGAF Architecture Requirement Specification?
Architecture Specifications are constraints on the freedom of designers and implementers. They tell them things they must, or must not do. Every specification removes degrees of freedom from the project team. As a result they need to be used sparingly.
We strongly recommend John Carver’s policy governance approach. First, specifications should be exclusionary, highlighting what is prohibited, rather than mandating what is permitted. Second, specification compliance should be assessed through a reasonable interpretation test by a reasonable person.
Drafting specifications as exclusionary reduces the requirement for omniscience during architecture development and provides the maximum opportunity for creativity during implementation, whether the creativity comes from innovative thinking by the design team, new technology, new third-party services, or new processes.
The key concept is if the architecture does not constrain a choice, or prohibit a choice, the choice is allowed. Given that creativity is encouraged, enterprise architects cannot expect that an implementation team can read minds and implement in the same way as envisioned. This forces the compliance assessment to be a test of reasonable interpretation.
Best practices link specification to a requirement. This allows the design, or implementation, to be assessed against a requirement/specification pair. The specification is in the context of what motivated the specification. Following this practice, every specification exists to deliver something, and the implementation can be value tested.
How do I use a TOGAF Compliance Assessment?
A TOGAF Compliance Assessment is used to determine whether you need to develop a Non-Compliance Recommendation. If the project is reasonably interpreting the target architecture's guidance and constraints the enterprise architect can stop work.
When a project is failing to deliver value or not following the architecture the enterprise architect has work to do.
Every noncompliance results in a recommendation to the stakeholder to enforce the target, grant temporary relief, or change the architecture. Each of these options has different implications
Non-Compliance Recommendation Implications
- Enforcing the target means the project must do extra work and must change.
- Granting temporary relief means the benefit expected from the specification will be deferred and additional work in the future is required.
- Changing the architecture means either the architect was unreasonably constraining, there is a new way to meet the expected outcome, or the expected benefit will be abandoned.
In all cases, the choice of action belongs to a Stakeholder. Enterprise Architects can expect regular conflict with Project Sponsors, Project Managers, and Implementation Teams. Everyone on a project gets excited about Go Live Day. They think in terms of project completion and will loses sight of any other purpose.
Final Thoughts on TOGAF ADM Phase G
Enterprise architects deliver value in two ways in TOGAF ADM Phase G. First, the advise implementation teams. Implementation teams often need help understanding what a project is expected to deliver. Also, they will interpret the architecture, gaps, specifications, and controls in terms of a project. Second, they will advise stakeholders who need to decide what to do when an implementation project is failing to deliver value or not following the constraints in the architecture.
Implementation projects are required to creating success. This is where the improvement occurs. The enterprise architect's role is to focus on expected value.
Most enterprise architects will spend most of their time executing TOGAF Phase G. When performing implementation governance they provide direction and control to focus enterprise resources on the changes most likely to delver the most value.
Phase G is where to most important activity takes place. The rest of the ADM explores potential improvements. Use TOGAF Phase G to focus scarce change resources on gaining more enterprise value.
