Architecture often becomes nothing more than a polished set of documents in SAP implementations and global rollouts because the gap between design and implementation is not managed in a way that executives can govern. When a local requirement falls outside the global template, projects often collapse into a false choice: prioritize standardization or accept the business request.
In practice, a binary choice is not what is needed. Organizations need to distinguish between planned differences in rollout scope, value-creating additions, and deviations that undermine future maintainability and governance. They then need to make the right decision for each type of difference.
TOGAF’s Levels of Conformance provide an effective framework for doing this. This article translates the concept into practical governance for SAP S/4HANA implementations, global-template rollouts, local delta management, and Architecture Compliance Reviews.
The conclusion is straightforward: the goal is not to make every country or legal entity Fully Conformant at all times. The goal is to make the expected conformance level explicit for each scope and implementation stage, while ensuring that genuinely Non-conformant deviations are consistently identified and governed.
Why Architecture Conformance Becomes an SAP Implementation Issue
Global standardization and local requirements do not have to conflict
Global SAP rollouts inevitably produce a broad range of requirements from countries and legal entities. E-invoicing, tax reporting, bank connectivity, local business practices, existing surrounding systems, and migration constraints arising from acquisitions are typical sources of local differences.
If every requirement outside the global standard is prohibited, the organization loses its ability to respond to business realities and regulation. If every country is free to add whatever it needs, the global template becomes hollow in a short time. The key is not to deny the existence of differences, but to classify their nature and govern them accordingly.
Binary compliance assessments do not reflect reality
At least three types of differences can exist between an implementation and the architecture:
- Not implemented: A defined function or capability has not yet been implemented.
- Additional implementation: A function, add-on, integration, or data element that is not described in the architecture has been added.
- Implementation in conflict: The implementation conflicts with defined principles, standards, or functional requirements.
Treating all three as “non-compliant” puts an unimplemented capability in a phased rollout on the same footing as a serious deviation such as a bespoke point-to-point integration. The review then becomes a formal approval exercise for delivery teams, while the risks that actually need to be managed disappear into the background.
TOGAF’s conformance levels offer a common language for expressing the relationship between implementation and specification in degrees rather than as a simple pass-or-fail judgment. The Open Group notes that terminology may differ across organizations, while positioning these concepts as useful when formulating an IT compliance strategy. (The Open Group: IT Architecture Compliance)
Understanding the Levels of Conformance at a Glance
Think of the architecture specification as the set of capabilities to be implemented, design principles, standards, and guardrails. Its relationship to an implementation can be classified in six ways.
| Level | Relationship between specification and implementation | Management implication for an SAP implementation |
| Irrelevant | No elements are shared. | The solution is not yet a meaningful comparison target. Confirm its scope and future integration direction. |
| Consistent | Some common elements are correct, but unimplemented requirements and out-of-specification additions both exist. | The delta is still being clarified. This should not be the target for design completion or production acceptance. |
| Compliant | Everything that has been implemented is correctly covered by the specification, but some specified elements are not implemented. | This can be acceptable for a phased implementation or a deliberately limited rollout scope. |
| Conformant | Every specified requirement is implemented, and additional elements also exist outside the specification. | The core is protected. Additional elements must be governed and assessed for reuse. |
| Fully Conformant | Specification and implementation correspond completely, with neither omissions nor additions. | The appropriate target for core areas where standardization and reuse should be maximized. |
| Non-conformant | Something specified by the architecture has been implemented in a way that differs from the specification. | A decision is required: remediate, change the specification, or approve a time-bound exception. |
The most important point is that Compliant and Conformant may sound similar, but describe the reverse relationship between implementation and specification.
- Compliant means the implementation is a subset of the specification: all implemented elements meet the specification, but some specified elements are not yet implemented.
- Conformant means the full specification has been implemented and additional elements also exist. What is required has been met, but the additions need governance.
Non-conformant also represents contradiction, not merely absence. Even if the implementation scope is small, it is not automatically Non-conformant if it does not violate defined design principles. Conversely, an implementation may contain every required function and still be Non-conformant if it breaks a mandatory control principle.
What Should Be Compared as the Architecture Specification?
Whether a conformance review works depends on the quality of the architecture specification used as the comparison baseline. Abstract slogans such as “use SAP standard” or “protect the Clean Core” are not sufficient for a defensible assessment.
For SAP implementations and rollouts, at least the following concrete decisions should be defined as reviewable specifications.
| Domain | What the specification should make explicit | Representative evidence |
| Business processes | Standardized processes, permitted local variations, and approval authority | Global Process Design, Fit-to-Standard results |
| Organization and finance | Company codes, profit centers, chart of accounts, and policies for costing and profitability analysis | Organization Design, Global CoA, accounting design documents |
| Master data | System of record, data owners, create/change approvals, and quality rules | Data Ownership Matrix, MDG workflows |
| Integration | API and middleware standards, prohibited connection patterns, and monitoring accountability | Integration Principles, Interface Inventory |
| Extensions | Priority order for standard functionality, configuration, key-user extensibility, ABAP, and SAP BTP | Extension Policy, Extension Register |
| Security | Fiori roles, segregation of duties, privileged IDs, audit logs, and access reviews | Role Matrix, SoD analysis, audit evidence |
| Operations | Jobs, incident monitoring, change management, releases, and data archiving | Operations Model, runbook, SLA |
In TOGAF®, “in accordance with” means more than the mere existence of functionality. It includes supporting the stated strategy and future direction, adhering to defined standards, providing the required functionality, and following design principles and component-reuse policies. (The Open Group: IT Architecture Compliance)
Accordingly, an SAP program is not necessarily conformant simply because it has implemented Business Partner. The review must also confirm whether Business Partner actually operates as the master-data foundation, whether responsibility boundaries for customer, supplier, credit, and integration data are respected, and whether a local custom table has become a competing system of record. Only then can conformance be assessed.
Practical Examples in an SAP Global Rollout
The following examples assume a company with a global SAP architecture in which:
- SAP S/4HANA is the global ERP core.
- Business Partner is the foundational model for customers and suppliers.
- A global chart of accounts and common management-accounting policies are used.
- External integrations use approved APIs and an approved integration platform.
- Standard functionality and standard extensibility are preferred, while core modification is minimized.
- Access control is based on Fiori roles and segregation-of-duties principles.
- Country-specific regulatory differences are registered and governed as approved local requirements.
Irrelevant: Do not start with the wrong scope
Consider a recently acquired overseas subsidiary that will retain its existing ERP for a short period. The initiative has no point of contact with S/4HANA, Business Partner, the global chart of accounts, or the integration platform, and no global-template capabilities are being applied.
This situation is Irrelevant in relation to the global SAP architecture. That is not a negative assessment. It means that there are no common elements on which a conformance assessment can reasonably be based.
However, the CIO and enterprise architecture team should not stop there. They still need to clarify the ERP’s future approach to integration, data migration, cybersecurity, identity management, and reporting, and decide how long it will remain outside the architecture scope.
Consistent: Correct elements do not mean the rollout is complete
Assume that an initial rollout to a sales subsidiary implements Business Partner, the global chart of accounts, and the standard order-to-cash process. Central procurement, Advanced ATP, and the global analytics platform are planned for a later wave and have not yet been implemented.
The country also adds a local vendor service for e-invoicing, but the integration approach and operational accountability have not been documented in the global specification. The common elements are correctly implemented, but unimplemented requirements coexist with additions outside the specification. This is therefore Consistent.
Consistent is a natural state during Fit-to-Standard workshops and design elaboration. It should not, however, be accepted at go-live merely because the solution is “partially aligned.” Unimplemented items need to be tied to the subsequent plan, additional elements need to be registered as local deltas, and future maintenance accountability needs to be clear.
Compliant: Explain phased implementation correctly
Consider the rollout of FI, SD, and basic MM to a small sales company. The organization adopts the global chart of accounts, Business Partner, standard pricing conditions, Fiori roles, and approved EDI integration. It adds neither bespoke add-ons nor its own chart of accounts.
Production planning, EWM, central procurement, and Group Reporting are either outside the company’s scope or planned for future deployment. Everything that has been implemented follows the specification, but part of the overall global architecture is not yet implemented. This is Compliant.
Compliant does not mean “incomplete.” If the limited rollout is intentional in light of the legal entity’s business scope and deployment plan, it is an appropriate state. The wave’s mandatory scope must nevertheless be explicitly defined; otherwise, intentional phasing cannot be distinguished from a delivery omission.
Conformant: Separate value-creating functionality from future debt
Consider a country that has implemented all mandatory elements of the global template and added a country-specific e-invoicing capability. The added capability uses the approved integration platform and follows global policies for master data, authorization, and audit logging.
This is Conformant. All mandatory architectural requirements have been met, while additions outside the specification also exist.
The issue is not whether additions should be allowed. The CIO, program manager, and enterprise architect need to answer the following questions:
- Is the addition required for regulation, local business practice, competitive advantage, or a temporary migration measure?
- Is it a country-specific delta, or a capability that can be reused in other countries?
- Should it be incorporated into the template or isolated as a local extension?
- What is its impact on S/4HANA upgrades, testing, operations, licensing, and vendor management?
- Are the owner, funding model, retirement conditions, and review date clear?
If an addition is accepted without visibility, it will not remain a valuable local capability. It will become future technical debt.
Fully Conformant: Protect the core standard and maximize reuse
Imagine a standard sales company receiving Release 4.0 of the global template. Business Partner, the chart of accounts, organizational structure, standard order management, pricing conditions, credit management, finance and profitability analysis, Fiori roles, and integration patterns are all implemented exactly as prescribed. No bespoke add-ons, master-data structures, or integrations are introduced.
This is Fully Conformant. The specification and implementation align completely for the defined scope.
Fully Conformant is a powerful target for maximizing standardization, deployment speed, operational integration, upgradeability, and reuse. It is not necessarily rational, however, to impose the same target on every region and business domain.
If legal requirements, industry-specific demands, and legitimate sources of business differentiation are all excluded, the architecture ceases to support the business and becomes a constraint on business change. Fully Conformant should not be a universal absolute target. It should be set only after the organization has made clear which domains belong to the standardized core.
Non-conformant: Identify contradiction, not just addition
The most important state to manage is Non-conformant. It means that something defined in the architecture specification has been implemented in a different way.
| Architectural decision | Example implementation | Why it is a problem |
| External integrations use the approved integration platform. | A plant independently builds point-to-point RFC or file integrations. | Governance over monitoring, incident response, security, and change impact breaks down. |
| Business Partner is the foundation of common master data. | A custom table based on legacy Customer/Vendor logic is retained as the system of record. | Systems of record are fragmented, destabilizing integration, analytics, and auditability. |
| Standard extensibility is preferred and core modification is minimized. | A large modification is made without first evaluating standard functionality or BAdIs. | Upgrade effort and maintenance risk increase. |
| The global chart of accounts is used. | A local team introduces an unapproved chart of accounts and mapping logic. | Consolidation, comparative analysis, and internal-control consistency are weakened. |
| Segregation-of-duties principles are followed. | Permanent excessive access is granted for operational convenience. | The risk of fraud, processing errors, and audit findings increases. |
When an implementation is judged Non-conformant, the architect’s role is not simply to reject it. There are four practical options:
- Remediate: Change the implementation so that it follows the specified approach.
- Change the specification: Update the architecture itself if the business need is broadly applicable.
- Approve a time-bound exception: Document compensating controls, a resolution date, the accountable owner, and residual risk.
- Withdraw the implementation: Remove the requirement when its risks outweigh its benefits.
Even when an exception is approved, it must not be an invisible permission. It must be a managed item with a clear risk owner and a resolution plan.
Conformance Targets for CIOs, Program Managers, and Enterprise Architects
Conformance levels are not evaluation labels. They provide a governance framework. The expected target should therefore be agreed for each type of scope at the start of the program.
| Scope | Recommended target | Purpose |
| Core global-template processes | Fully Conformant | Maximize reuse, rollout speed, and control. |
| Accounting policies, audit, security, and common master data | Fully Conformant as the default | Local deviations have low tolerance because of enterprise-control requirements. |
| Country or legal-entity rollouts | Fully Conformant against the Wave Architecture, or Compliant against the enterprise-wide specification | Manage phased rollout as a legitimate scope difference. |
| Regulatory extensions | Conformant | Allow necessary additions while making deltas visible and assessing reuse. |
| Digital capabilities that support business differentiation | Conformant | Govern value-creating extensions without damaging the core. |
| Fit-to-Standard and early design | Temporarily allow Consistent | Surface open issues and deltas, then resolve them before design completion. |
| Guardrail violations that are prohibited without exception | Non-conformant is not normally acceptable | Prevent material integration, security, data, and audit risks. |
Separate the enterprise architecture from the Wave Architecture
A common rollout mistake is to use the enterprise-wide Target Architecture directly as the acceptance criterion for every country and legal entity. This makes a phased implementation appear to be deficient by definition.
A more effective approach is to define a Wave Architecture, or Project Slice, by extracting the portion of the enterprise Target Architecture that is relevant to the project. The Open Group describes project-specific views that show the impact of the architecture on major projects as Project Impact Assessments, which are sometimes called project slices. (The Open Group: IT Architecture Compliance)
For example, a sales-company wave may exclude production, warehousing, and advanced planning while including FI, SD, basic MM, master data, integration, and authorization. Targeting Fully Conformant against that Wave Architecture creates clear and strong governance even within a deliberately limited scope.
Embed Architecture Compliance Reviews in SAP Activate
If an Architecture Compliance Review is conducted only once, immediately before go-live, the cost of rework becomes high. Reviews should not be positioned merely to find problems. They should be placed at points where decisions can still be made and corrections are still feasible.
The Open Group describes an Architecture Compliance Review as an assessment of a project against established architectural criteria, intent, and business objectives. It also identifies early discovery of major design errors, in order to reduce the cost and risk of change, as one of its key purposes. (The Open Group: IT Architecture Compliance)
When combined with SAP Activate, the following operating model is practical.
| Phase | Review question | Primary deliverables | Main decision-makers |
| Discover / Prepare | What is in scope? How much of the global standard applies? | Project Slice, scope, initial principles | CIO, Enterprise Architect, program sponsor |
| Explore | What are the Fit-to-Standard deltas? Are they unimplemented items, additions, or contradictions? | Fit-to-Standard delta list, Delta Register, initial conformance assessment | Program manager, solution architect, business owner |
| Realize | Do design, extensions, integrations, data, and authorization follow the principles? | Solution design, interface design, Extension Register, exception requests | Enterprise Architect, domain architects, security owner |
| Deploy | Has the solution been implemented as designed, with operational and control evidence? | Test results, configuration evidence, migration results, operating procedures | Program manager, QA, business owner, Enterprise Architect |
| Run / Hypercare | Are exceptions being resolved on time? Should lessons be reflected in the template? | Exception register, improvement backlog, template change proposals | Application owner, Enterprise Architect, Architecture Board |
Make the review a learning loop, not merely a gate
Deltas identified by a review should not simply be approved or rejected. Repeated local requirements or recurring design challenges may indicate that the template or its principles are incomplete.
For example, if multiple countries raise similar additional requirements for e-invoicing, bank connectivity, or tax reporting, the organization should not simply accumulate individual exceptions. It should assess whether the global template needs a localization-services layer. An architecture review is both an activity for protecting the standard and an activity for learning from and evolving the standard.
A Governance Design That Can Actually Be Operated
Use one Delta Register as the source of truth
When each country, legal entity, and vendor manages deltas in separate spreadsheets, the organization cannot understand the true state of the global template. Operate a Delta Register as a common source of truth containing at least the following fields.
| Management field | Description |
| Delta ID | A unique identifier that makes requirements, design, testing, and exceptions traceable. |
| Country, legal entity, and wave | Where the delta applies. |
| Classification | Regulation, local business practice, business differentiation, temporary migration measure, technical constraint, or other. |
| Conformance level | Consistent, Compliant, Conformant, Non-conformant, and so on. |
| Impact areas | Process, data, integration, extension, security, operations, and cost. |
| Decision | Approve, reject, remediate, promote to template, or grant a time-bound exception. |
| Owner | The accountable business, IT, data, security, or vendor representative. |
| Deadline and exit conditions | When and how an exception will be resolved. |
| Reusability | Applicability to other countries, legal entities, or future releases. |
Preserve Architecture Decision Records
The context explaining why a decision was made is one of the first things lost in delta management. Important architectural decisions should therefore be preserved as Architecture Decision Records.
Do not record only the decision. Record the options, the alternatives not chosen, business and technical rationale, impacts, risks, and conditions for reconsideration. This prevents the next country or legal entity from having to repeat the same discussion from the beginning.
Clarify roles
| Role | Primary responsibility |
| CIO / Sponsor | Decide the boundary between standardization and business flexibility, material exceptions, and investment priorities. |
| Program Manager | Plan conformance reviews and integrate the management of issues, exceptions, and dependencies. |
| Enterprise Architect | Design and maintain principles, guardrails, conformance criteria, and the exception process. |
| Solution Architect | Map each wave’s design to the specification and prepare evidence. |
| Global Process Owner | Assess the validity of business standards and local requirements. |
| Data Owner / Security Owner | Confirm conformance to systems of record, data quality, access control, and audit requirements. |
| Architecture Board | Approve material deltas, exceptions, template changes, and investment decisions. |
The enterprise architect is not the person who approves everything. The role is to structure options and impacts so that decision-makers can decide with a clear understanding of business value, risk, reusability, and future cost.
Common Failure Modes and How to Avoid Them
Failure 1: Require Fully Conformant for every initiative
This policy appears reasonable, but it drives regulatory and business-critical deltas underground. When teams bypass formal delta management through local configuration, spreadsheets, surrounding systems, or manual workarounds, governance actually becomes weaker.
The alternative is to require Fully Conformant in core domains while allowing Conformant for justified local deltas. In return, the rationale, owner, operating model, and reusability of every addition must be explicit.
Failure 2: Treat Compliant as a low assessment
Phased implementation may deliberately leave some capabilities out of an initial wave. Treating that as a deficiency pushes projects toward unnecessary scope expansion.
The alternative is to clearly extract the architecture specification for each wave. A rollout can be Compliant against the enterprise-wide specification and Fully Conformant against its Project Slice. In that case, its implementation governance is sound.
Failure 3: Forget an exception after approving it
An exception without a deadline will almost certainly become permanent technical debt. Exceptions involving interfaces, authorization, master data, or custom code are particularly likely to amplify costs in later waves and upgrades.
The alternative is to give every exception an exit condition. Record at the time of approval when it must be resolved, who is accountable, what constitutes resolution, and the standard state to which the solution will return.
Failure 4: Conduct one review only, immediately before go-live
If a material design deviation is discovered just before production deployment, it often cannot realistically be corrected, and exception approvals proliferate. The issue is not that the review failed; it is that the review happened too late.
The alternative is to conduct reviews at Fit-to-Standard, design sign-off, build completion, go-live decision, and operational transition, changing the review questions at each milestone.
Five Actions to Start Tomorrow
- Inventory the mandatory requirements in the global template. Rewrite principles, standards, mandatory capabilities, and prohibitions as statements that can be reviewed.
- Define the Wave Architecture. Extract the scope that applies to each country and legal entity from the enterprise Target Architecture.
- Standardize the Delta Register. Use a Delta ID to connect Fit-Gap items, design issues, exceptions, and test evidence rather than managing them in isolation.
- Agree the criteria for Non-conformant in advance. Explicitly define unacceptable contradictions in integration, security, master data, finance, and extensions.
- Embed Architecture Reviews in the project plan. Put the required decisions and evidence into milestones, rather than simply scheduling review meetings.
Summary
TOGAF® Levels of Conformance are not labels for scoring the gap between architecture and implementation. In SAP implementations and global rollouts, they are a decision-making framework for balancing standardization with business flexibility.
Successful organizations do not attempt to reduce every difference to zero. Instead, they distinguish among unimplemented capabilities that should be accepted as part of a phased rollout, extensions that should be developed as valuable additions, and deviations that should be corrected quickly. They do not leave these decisions to individual experience or political influence. They operationalize them through architecture principles, reviews, evidence, and exception management.
To turn a global SAP template from a one-time rollout deliverable into a continuously evolving management platform, begin by asking the following question across the project:
Against which architecture specification, and at which level of conformance, should this implementation be assessed?
When the organization can answer that question clearly, Architecture Compliance Reviews stop being approval rituals and become practical governance that balances business value with control.
Reference Links
The discussion of Architecture Compliance, Levels of Conformance, Project Slices, and Architecture Compliance Reviews in this article is primarily based on the following official resources.
– **The Open Group: IT Architecture Compliance**
Primary reference for Levels of Architecture Conformance, Project Impact Assessments, and Architecture Compliance Reviews.
https://www.opengroup.org/architecture/togaf7-doc/arch/p4/comp/comp.htm
– **SAP Activate Methodology**
SAP’s official overview of the Discover, Prepare, Explore, Realize, Deploy, and Run phases, including fit-to-standard, extensibility, testing, and continuous improvement.
https://www.sap.com/products/erp/activate-methodology.html
– **SAP Learning: Describing the Methodology Structure**
Detailed guidance on the purpose of the SAP Activate phases, fit-to-standard workshops, backlog management, configuration, development, testing, and deployment.
– **SAP: Clean Core Extensibility for SAP S/4HANA Cloud**
SAP’s official paper on using the clean core strategy and extensibility model to extend SAP S/4HANA while preserving upgrade stability.
https://www.sap.com/documents/2024/09/20aece06-d87e-0010-bca6-c68f7e60039b.html
– **SAP Learning: Exploring Clean Core Extensibility Best Practices**
Guidance on clean core extensibility levels, ABAP Cloud, released APIs, classic APIs, internal objects, and upgrade stability.
– **SAP Help Portal: Business Partner Master Data Structure**
Official documentation on the Business Partner master data model and the management of customer and supplier data across organizational levels.
– **SAP Learning: Creating Business Partners**
SAP learning content explaining the role of Business Partner as the central master data object for customers and suppliers in SAP S/4HANA.
https://learning.sap.com/courses/purchasing-in-sap-s-4hana/creating-business-partners
– **SAP Help Portal: SAP Integration Suite API Management**
Official SAP documentation on API publication, security, policy management, lifecycle management, and API governance in SAP Integration Suite.
https://help.sap.com/docs/integration-suite/sap-integration-suite/api-management-capability
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