When an automotive Tier‑1 supplier decides to deploy SAP ERP globally, the CIO and Enterprise Architect must act as “city planners” for the entire enterprise while simultaneously ensuring that each implementation project can succeed within realistic time and budget constraints.
If the distinction between Enterprise Architecture (EA) and Project Management (PM) is left ambiguous, typical failure patterns quickly appear: proliferating standards, a hollowed‑out global template, and uncontrolled local customizations at each plant or regional entity.
This article uses TOGAF® as a reference framework to clarify how CIOs, Enterprise Architects, and SAP project managers should design roles and responsibilities from the initial domestic SAP implementation through phased rollouts and full global deployment.
1. How TOGAF® Frames the Relationship Between EA and Projects
TOGAF® defines Enterprise Architecture as the structure of enterprise components, their interrelationships, and the principles and guidelines that govern their design and evolution over time, emphasizing long‑term transformation rather than short‑term delivery.
The TOGAF® ADM provides a method for developing architectures, but intentionally delegates project management practices to frameworks such as PMBOK or PRINCE2; ADM is an architecture development method, not a project management methodology.
For CIOs in manufacturing, this separation is crucial: EA is accountable for what is architected and governed at enterprise level, while PM is accountable for how that architecture is planned, executed, and controlled as concrete projects and programs.
2. Enterprise Architect as “City Planner,” SAP PM as “Construction Site Manager”
The TOGAF® Architecture Skills Framework compares the Enterprise Architect’s role to a city planner responsible for designing a planned community, rather than managing the construction of individual buildings.
In a SAP context for automotive Tier‑1 suppliers, that “planned city” corresponds to your global SAP template, standard process models, master data governance, and integration principles across PLM, MES, WMS, and other adjacent systems.
Program and Project Management skills are defined as a distinct category in TOGAF®, focusing on planning and controlling projects to meet time, cost, quality, scope, risk, and benefit objectives.
For SAP implementations, project managers own execution—mobilizing resources, coordinating fit‑to‑standard workshops, overseeing testing, migration, training, and go‑live—while Enterprise Architects own architectural integrity and the long‑term evolution of the SAP landscape.
3. Three‑Layer Governance Model for Tier‑1 SAP Global Rollouts
For a Tier‑1 automotive supplier that first implements SAP ERP domestically and then rolls it out to domestic and overseas plants, a three‑layer governance model is particularly effective.
| Layer | Main Focus | EA Roles | PM Roles |
| Enterprise / Program | Global SAP strategy, template, and rollout roadmap | Enterprise Architect, Architecture Board | Global Program Manager / PMO |
| Segment (Domain / Region) | Japan, Europe, North America business architecture and policies | Segment Architect | Segment / Regional Project Manager |
| Solution / Site | Individual plant or sales entity implementations | Solution Architect / Local IT Architect | Local Project Manager (site‑level PM) |
Within this structure, the CIO must explicitly define which decisions fall under EA responsibility (principles, standards, templates) and which fall under PM responsibility (scope, schedule, resourcing), and then formalize these boundaries in organizational charters.
4. Phase‑Based Role Split: Domestic First, Then Global
Phase 1: Domestic Head Office and Lead Plant (Pilot)
EA (Enterprise + Japan Segment)
- Define the global SAP target architecture across Business, Data, Application, and Technology domains, following TOGAF ADM Phases A to D, while clarifying how Japanese‑specific requirements will be handled.
- Design the global master data architecture (materials, customers, suppliers, plants, BOMs, etc.) and the MDG governance model, including ownership, approval flows, and data quality controls.
PM (Global PM + Domestic Pilot PM)
- Using the EA baseline, plan project scope, schedule, resources, and risk management approach, and agree pilot success criteria and go/no‑go thresholds with business stakeholders.
- Facilitate fit‑to‑standard and fit‑gap workshops, escalate gap requirements to EA, and jointly decide whether changes should be absorbed into the global template or implemented as controlled local add‑ons.
Phase 2: Sequential Rollout to Domestic Sites
EA
- Consolidate lessons learned from the pilot into a stable “domestic SAP template” and define the rollout roadmap, including rollout waves and prioritization of plants and legal entities.
- Establish rules for allowable deviations from standards and a feedback loop so that reusable improvements are systematically promoted from local solutions into the core template.
PM
- The global PM and domestic program PM plan rollout waves and coordinate dependencies, while each site‑level PM manages local adoption, data migration, training, and post‑go‑live stabilization.
- PMs collect site‑specific requirements and work with EA to classify them as template enhancements, regional variants, or strictly local solutions under clear governance.
Phase 3: Global Rollout to Overseas Plants and Entities
EA
- Extend the segment architectures to incorporate regional specifics such as tax rules, regulatory compliance, logistics constraints, and supply‑chain characteristics for Europe, North America, and other regions.
- Design the structure of the global SAP template into core, regional variants, and local extensions, and codify the principles that determine what must remain globally consistent versus what may differ by region.
PM
- The global PM oversees the end‑to‑end program, while regional PMs plan implementation waves, choose pilot sites, and manage local execution and stakeholder alignment.
- Project managers rely on EA’s architecture vision and template design as given constraints, managing risks, benefits, and timelines while ensuring adherence to architectural governance.
5. Five Design Principles for CIOs and Enterprise Architects
To make the EA–PM split actionable, CIOs and Enterprise Architects should anchor governance in five practical principles.
- Clarify Objects of Responsibility
- EA: enterprise‑wide structure, principles, standards, target architectures, and roadmaps.
- PM: project or program scope, timelines, budgets, resources, risks, and deliverables.
- Recognize Different Time Horizons
- EA: mid‑ to long‑term design and evolution of the SAP and digital landscape.
- PM: finite projects or programs with clearly defined start and end dates.
- Separate Key Deliverables
- EA: Architecture Definition Documents, target and transition architectures, roadmaps, reference models, and global templates.
- PM: project plans, status reports, risk registers, issue logs, and change management records.
- Define Decision Boundaries
- EA leads decisions on principles, standards, and template changes and exceptions.
- PM leads decisions on scope trade‑offs, schedule adjustments, and resource allocation within agreed architectural constraints.
- Integrate Governance Bodies
- Connect the Architecture Board and Steering Committee so that architectural decisions and project decisions reinforce each other instead of colliding in day‑to‑day execution.
Summary
For automotive Tier‑1 suppliers, SAP global rollouts are too complex to succeed without a clear separation of Enterprise Architecture and Project Management responsibilities, and TOGAF® provides a proven reference for designing that separation.
By combining a three‑layer operating model with phase‑based role definitions and explicit decision boundaries between CIO, Enterprise Architect, and project managers, organizations can protect the integrity of their SAP global template while still delivering local business value at each plant and region.
Reference Links
- The Open Group: The TOGAF® Standard
https://www.opengroup.org/togaf - The Open Group: Architecture Project Management
https://pubs.opengroup.org/togaf-standard/architecture-project-management/index.html - The Open Group: TOGAF® Standard — Introduction & Content
https://pubs.opengroup.org/togaf-standard/introduction/apdxa.html
https://pubs.opengroup.org/togaf-standard/architecture-content/chap04.html - TOGAF Architecture Skills Framework (QualiWare CoE)
https://coe.qualiware.com/resources/togaf/9-1/part7-capabilityframework/architectureskillsframework/ - Umbrex: TOGAF Framework for Digital, IT & Architecture
https://umbrex.com/resources/frameworks/project-management-frameworks/togaf/ - Umbrex: Project Management Frameworks Overview
https://umbrex.com/resources/frameworks/project-management-frameworks/
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