When an SAP S/4HANA implementation moves past basic design and build and starts gearing up for go-live, many PMs and Enterprise Architects (EAs) run into the same problem: the target architecture they worked so hard to define starts eroding under the weight of ad hoc local optimizations and add-on requests from the development team. TOGAF’s ADM (Architecture Development Method) Phase G: Implementation Governance was designed precisely to address this problem. Its purpose is not to carry out implementation itself, but to oversee and govern whether the implementation actually conforms to the architecture that has already been defined . For an automotive parts Tier 1 supplier rolling out SAP globally across multiple sites and modules, how well this governance is executed has a major impact on upgrade costs and maintainability years down the road.
Phase G’s Role: Overseeing Implementation, Not Performing It
The TOGAF® standard opens its Phase G chapter with the statement: “This chapter provides an architectural oversight of the implementation” . The actual development work proceeds in parallel with Phase G, following the organization’s own development processes — but Phase G’s role is not to run that development process. It is to continuously check whether that process is heading in the right direction .
TOGAF® goes further, stating: “A key aspect of Phase G is ensuring compliance with the defined architecture(s), not only by the implementation projects, but also by other ongoing projects within the enterprise” . This makes clear that governance is not confined to a single project. For an automotive parts Tier 1 supplier, MES integration, quality systems, and site-specific peripheral system renewals often run in parallel with the core SAP implementation — and every one of them is a potential source of drift from the target architecture.
Another point worth emphasizing is that Phase G assumes a staged migration rather than a single “big bang” cutover to the finished state. TOGAF® explains: “To enable early realization of business value and benefits, and to minimize the risk in the transformation and migration program, the favored approach is to deploy the Target Architecture as a series of transitions” . A global SAP rollout that proceeds through a domestic pilot, then an Asia expansion, then Europe and North America, follows exactly this logic — with Phase G compliance checks performed at the completion of each transition.
The mechanism that turns this governance into an institutional practice is the Architecture Contract. TOGAF® states: “Phase G establishes the connection between architecture and implementation organization, through the Architecture Contract” . In other words, agreements between the EA function and implementation vendors or delivery teams need to be documented as formal contracts — not left as unwritten conventions passed along verbally.
The Roles PMs and EAs Play in Phase G
Phase G is not something an EA carries out alone. It is collaborative work in which the PM and EA each take on distinct responsibilities. Following TOGAF’s description, the core activities break down as follows :
- Identifying gaps and Solution Building Blocks — the solution architect identifies gaps remaining in the existing solution landscape and defines the Solution Building Blocks (SBBs) needed to close them. Because an SBB can map one-to-one to a single project or serve multiple projects at once, this step also involves coordinating to avoid duplicate investment across projects .
- Educating project resources — development resources are briefed on the enterprise-wide EA deliverables and on what is expected from each implementation project. In an SAP rollout, this corresponds to making sure development vendors and offshore teams fully understand the enterprise’s architecture principles — such as prioritizing standard functionality and adhering to a Clean Core policy .
- Performing compliance reviews for each implementation and deployment project — each project runs through its own architecture-compliance review process .
- Closing Phase G — the current cycle of Phase G is considered complete once the target solution has been fully deployed .
For a PM, the practical takeaway is to build these activities explicitly into the project plan as milestones. Framing compliance reviews and architecture sign-offs as risk-management activities that reduce downstream rework costs — rather than as bureaucratic gates — makes them far easier to justify to a steering committee. For an EA, the practical takeaway is to document the review criteria (what gets approved, what gets rejected) up front. When criteria stay ambiguous and every case is judged one at a time, the EA function risks being seen as a bottleneck, which makes it harder to win cooperation from delivery teams.
Phase G Outputs: What Artifacts Actually Remain
| Output | What It Contains | What It Means for PM/EA |
| Architecture Compliance Determinations | The formal evaluation of whether each implementation project conforms to the defined architecture | The evidence trail that lets you explain, after the fact, why a given design was approved or rejected |
| Architecture Contract | The agreement between the EA function and the implementation organization on compliance obligations and areas of responsibility | The technical basis for vendor management and contract negotiations with the SI |
| Change Requests | Feedback triggered when implementation constraints require a revision of the architecture itself | Feeds back into Phases E/F, keeping the roadmap grounded in reality |
| Compliance Assessments | Periodic conformance evaluations for individual implementation and deployment projects | A health checkpoint at each staged migration (transition) |
What all of these outputs have in common is that they remain verifiable after the fact. Accumulating documented determinations, contracts, and assessments — rather than relying on individual judgment calls made verbally — is the real value of Phase G, and it becomes a critical asset during audits and upgrade planning.
Putting This into Practice in an Automotive Tier 1 SAP Rollout: Governing Clean Core and Fit-to-Standard
In an automotive parts Tier 1 supplier’s SAP S/4HANA implementation, the philosophy of Phase G shows up as two very concrete, day-to-day decision points: maintaining Fit-to-Standard and governing Clean Core.
SAP itself lists “Extensibility” as one of the five guiding principles for achieving Clean Core, stating: “A clear governance process ensures leveraging the best available extensibility option — on-stack and side-by-side with SAP BTP” . In other words, even in SAP’s own official methodology, Clean Core cannot be sustained without governance — a position that aligns directly with what TOGAF’s Phase G demands in terms of implementation-project compliance review.
A governance structure commonly adopted in practice is the Solution Standardization Board (SSB), proposed as part of SAP Activate. SAP’s guidance defines the SSB’s role as follows: “The role of the SSB is to act as a body overseeing the standardization of business processes and compliance with 5 Golden Rules,” and explains that “SSB evaluates, reviews, approves or rejects requests by project teams for… delta requirements addressed through in-app and side-by-side extensions” . This can be understood as the architecture-compliance review defined by TOGAF’s Phase G, translated directly into the language of an SAP project.
Mapping Phase G to an SAP Implementation Project
| TOGAF Phase G Element | Concrete Action in an SAP Project | Roles Involved |
| Architecture Contract | Formalize the principle “prioritize SAP standard functionality; limit extensions to on-stack or side-by-side on BTP” as a contract-level agreement between the EA function and the SI/development vendor | EA, PM, Procurement/Contracts |
| Compliance Review | At the completion of each module design (FI/CO, MM, SD, PP), route add-on requests through an SSB-style review body to assess whether standard functionality or a BTP extension can serve as an alternative | EA, Solution Architects, SSB |
| Educating Project Resources | Train development vendors and offshore teams on the five Clean Core principles (Extensibility, Process, Data, Integration, Operations) from the earliest stage of the project | EA, PMO |
| Architecture Compliance Determinations | Issue formal determinations — e.g., “this add-on is implemented loosely coupled on BTP and conforms to the Clean Core policy” — to serve as the baseline documentation for assessing technical debt at future upgrades | EA, Architecture Review Board |
| Change Requests | Feed requirements that cannot be met by standard functionality back into Phases E/F as input for the next roadmap cycle or template revision | PM, EA |
As this mapping shows, TOGAF’s Phase G is far from an abstract theoretical construct — its structure closely mirrors the governance practices SAP itself recommends (the SSB, Clean Core governance). This means that even organizations that have not formally adopted TOGAF can achieve substantially the same level of control by designing their SAP governance structure around Phase G’s principles.
Failure Patterns PMs and EAs Should Watch For
A common failure in Phase G execution is having a review body in place while the actual decision criteria remain person-dependent. When an SSB or Architecture Review Board approves requests simply because “the explanation from the development team sounded reasonable,” it fails to deliver the accountability that TOGAF® expects from a compliance determination — and a few years later, during an upgrade, no one can explain why a given add-on exists in the first place.
A second failure pattern is treating Phase G purely as a post-implementation check performed after the fact. As TOGAF® emphasizes, Phase G activities should run continuously, in parallel with the implementation project . For an SAP project, that means standing up an SSB-style governance body as early as the requirements-definition and Fit-to-Standard workshop stage . Waiting until the design is already locked in before applying scrutiny only drives up rework costs.
Summary
For an automotive parts Tier 1 supplier’s SAP implementation, Phase G should be understood not as a mechanism for stripping the implementation team of its freedom, but as an investment that prevents the organization from being paralyzed by technical debt at the next upgrade cycle, years down the road. The architecture-compliance review and Architecture Contract mechanisms defined by TOGAF® are, in substance, the same thing as the SSB and Clean Core governance practices used in the SAP world . PMs are responsible for making Phase G work by embedding it as an explicit gate in the project plan; EAs are responsible for making it work by documenting review criteria up front and applying them consistently. By building compliance checks into each milestone of a staged migration — pilot, domestic rollout, and international expansion — an organization can contain the add-on sprawl that tends to accumulate the further a global rollout progresses, stopping it at the earliest possible stage.
Reference Links
- The Open Group, “Phase G: Implementation Governance,” The TOGAF Standard, Version 9.2: https://pubs.opengroup.org/architecture/togaf9-doc/arch/chap14.html
- SAP, “RISE with SAP | ERP Clean Core Strategy”: https://www.sap.com/products/erp/rise/methodology/clean-core.html
- SAP Community, “Practical governance to drive fit-to-standard mindset in your SAP S/4HANA implementation”: https://community.sap.com/t5/enterprise-resource-planning-blog-posts-by-sap/practical-governance-to-drive-fit-to-standard-mindset-in-your-sap-s-4hana/ba-p/13429974
Disclaimer
Parts of this article were developed with reference to generative AI suggestions and were reviewed, refined, and supplemented based on the author’s professional expertise and judgment.
Leave a Reply