TOGAF ADM Phase G - Ensure Value with Implementation Governance
At a Glance
- TOGAF ADM OverView
- What is TOGAF Phase G?
- TOGAF ADM Phase G Deliverables
- What is the Role of the Enterprise Architect in Phase G?
- Using the Architecture Governance Tools
- How does Phase G of TOGAF align with Agile?
- Final Thoughts on TOGAF ADM Phase G
TOGAF ADM Overview
The TOGAF ADM is a method to develop knowledge. We focus every ADM Phase on developing specific knowledge required for an enterprise architecture. TOGAF ADM is the core of the TOGAF Standard. It is the only scalable universal method to develop enterprise architecture appropriate for every level of detail. Like all logical models, it needs to be expanded upon for different levels of detail - strategy, portfolio, project, and solution delivery.
We have an overview of the TOGAF ADM.
What is TOGAF Phase G?
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.
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.
What is the Objective of TOGAF ADM Phase G?
In Phase A, you set yourself up for success. In Phase G, you are reaching that success. Success requires:
- You solve the problem
- You serve the stakeholders with interests fundamental to the problem
- You guard your stakeholders' interests, priority, and any preference
- You govern the implementation project to the architecture constraints
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 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.
Remember, the TOGAF ADM has several off-ramps. Phase G is the most expensive off-ramp. An architecture defines the changes to deliver an improvement. Every change carries cost and a risk of failure. The moment the cost of the change exceeds the expected value is the moment to stop. Yes, STOP! Stop dead in your tracks. Then celebrate that you have minimized the waste of scarce change resources.
Not all projects are successful. Not all solutions produce enough value. The sooner you know the cost exceeds the value stop.
How to Define 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.
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.
Completion of Phase G
All TOGAF ADM Phases lead you to developing the knowledge you need. The Outcome of Phase A is permission to proceed.
| Output & Outcome | Essential Knowledge |
| Completion of the projects to implement the changes necessary to reach the adjusted target state. |
|
Table from TOGAF 10 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:
- What is the project's purpose?
Architecture to support Strategy and architecture to support Portfolio will both have an Architecture Roadmap. The roadmap will identify change initiatives, portfolio, program, and project. It will clearly state synergies, terms of reference, and approaches. The Roadmap will govern their execution of change projects.
Guarding the value, or expected outcome, of an implementation project is the primary accountability of an enterprise architect.
- What are 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:
- 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. Extend the expected value, or pull it in to what we can realize. Relax or tighten constraints.
The enterprise architecture stakeholders own all decisions for the second and third outcomes.
TOGAF Phase G Compliance Assessment
The most important part of the Compliance Assessment is the recommendation of what to do when faced with non-compliance.
| 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 from TOGAF 10 TOGAF Series Guide: Enterprise Architect's Guide to Developing Architecture
What is the role of the Enterprise Architect in Phase G?
In TOGAF Phase G, the enterprise architect's role is to guard the expected value. They do this by clarifying ambiguity in the target architecture.
One of the most common clarifications is reminding everyone what the expected outcome is. Implementation teams routinely lose sight of the project's value.
In one of our enterprise architecture training case studies, the project team is implementing SAP. Their measurable outcome is simplifying the application portfolio and updating financial accounting and human resources. The architecture value of the project was providing modern information-based project controls. The implementation team constantly tried to focus the project on Finance and HR. The enterprise architect's role was to re-focus on information-based project controls. In the real-world, the project controls generated a couple of billion dollars benefit. Finance and HR improvements generated a hundred million.
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.
What is Architecture Oversight?
Architecture oversight 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.
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.
Architecture oversight requires using the Architecture Governance Tools.
Implementation Governance Checklist
The Architecture Governance Checklist provides a set of tests to apply to the enterprise architect's compliance assessment and non-compliance recommendation.
- Did the organization embarking on a change reasonably interpret the target architecture’s guidance and constraints? Yes/No?
- If yes, we should accept their interpretation as compliance and any issues addressed through a change to the architecture
- If not, proceed with developing a non-compliance recommendation.
- Do subject matter experts agree with the facts and interpretation of the facts in the impact assessment? Yes/No?
- If yes, proceed
- If not, either direct the architect to engage with the subject matter experts or develop a recommendation for the Stakeholders that they should have limitations in confidence
- Do subject matter experts agree with the recommendation to enforce the target, grant time-bound relief, or change the architecture? Yes/No?
- If yes, proceed
- If not, either direct the architect to engage with the subject matter experts or develop a recommendation for the Stakeholders that they should have limitations in confidence
- Do the Views produced for the Stakeholders reflect the impact assessment and reflect any underpinning architecture models and analysis? Yes/No?
- If yes, proceed to the Stakeholders for approval
- If not, direct the architect to develop Views
- Do the Stakeholders understand any limitations in confidence they should have in the impact assessment? Yes/No?
- If yes, proceed
- If not, direct the architect to develop Views and return to the Stakeholders
- Do the Stakeholders understand the impact on prior expected Value, and any change in certainty in achieving the Value, provided by reaching the target state? Yes/No?
- If yes, proceed
- If not, direct the architect to develop Views and return to the Stakeholders
- Has the Stakeholders approved the recommendation to enforce the target, grant relief, or change the architecture? Yes/ No
- If yes, the Enterprise Architecture Board should approve the non-compliance action recommendation for publication in the EA repository
- If not, the Enterprise Architecture Governance board has a tough decision. In short, either direct the enterprise architect to expand the information provided to the Stakeholder to get a different decision, or re-work the recommendation to embrace the Stakeholder’s preferences.
The Implementation Strategy Model from TOGAF Phase E - Architecture Roadmap 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.
Using the Architecture Governance 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.
- Architecture Contract
- Architecture Roadmap
- Architecture Requirement Specification
- TOGAF Compliance Assessment
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.
How does Phase G of TOGAF align with Agile?
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
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.