When an automotive Tier 1 supplier implements and rolls out SAP S/4HANA globally, the role of an Enterprise Architect (EA) goes far beyond designing a target system architecture.
Enterprise Architects must take a cross-functional view of business strategy, OEM customer requirements, plant operations, legacy ERP systems, MES, EDI, supply chains, data, applications, and technology infrastructure. They must define the Target Architecture and ensure that it can be translated into an executable transformation.
In this context, four terms frequently appear in Enterprise Architecture:
- Output
- Deliverable
- Artifact
- Outcome
Although these terms are sometimes used interchangeably, they represent different concepts in Enterprise Architecture.
One of the most important distinctions is between what the architecture work produces and what the enterprise ultimately achieves as a result of the transformation.
This article explains these differences from a practical perspective, using the global rollout of SAP S/4HANA at an automotive Tier 1 supplier as an example.
1. Understanding Outputs, Deliverables, Artifacts, and Outcomes
The four concepts can first be summarized as follows.
| Term | Meaning in Enterprise Architecture | Example in an SAP Transformation |
| Output | Something produced through EA activities | Architecture Vision, Gap Analysis, Roadmap |
| Deliverable | A formal work product that is reviewed, agreed upon, and approved | Architecture Definition Document, Implementation and Migration Plan |
| Artifact | A specific representation of an aspect of the architecture | Capability Map, Application Portfolio Catalog, Architecture Diagram |
| Outcome | A result achieved by the enterprise through architecture and transformation | Inventory reduction, process standardization, OTIF improvement, IT TCO reduction |
Put simply:
Output = What does the architecture work produce?
Deliverable = What is formally delivered, reviewed, and approved?
Artifact = How is the architecture represented?
Outcome = What does the enterprise ultimately achieve?
Understanding these distinctions helps Enterprise Architects avoid a common problem in large SAP programs: confusing the completion of architecture documents with the realization of business value.
2. An Automotive Tier 1 SAP Transformation Example
Consider an automotive Tier 1 supplier operating manufacturing plants across multiple countries and regions.
The company plans to consolidate various legacy ERP systems into SAP S/4HANA.
The organization may be facing challenges such as:
- Different ERP systems across plants and regions
- Inconsistent master data for materials, BOMs, customers, and suppliers
- Different approaches to customer forecasts, delivery schedules, and firm orders depending on the OEM
- Region-specific EDI and JIT/JIS processes
- Different production planning and manufacturing execution processes across plants
- Limited global visibility into inventory and production capacity
- Non-standardized financial closing and management processes
- Complex interfaces between ERP, MES, EDI, and other applications
Management therefore establishes a transformation objective:
“Implement SAP S/4HANA as the Global Core ERP and standardize business processes, data, and systems across the enterprise.”
The Enterprise Architect performs a variety of architecture activities to support this transformation.
This is where the distinction between Outputs, Deliverables, Artifacts, and Outcomes becomes particularly important.
3. Output: What Does the EA Work Produce?
An Output is something produced as a result of architecture activities.
For example, during the early stages of an SAP transformation, an Enterprise Architect may perform activities such as:
- Identifying stakeholders
- Understanding stakeholder concerns
- Analyzing business capabilities
- Assessing the Current Architecture
- Defining the Target Architecture
- Performing Gap Analysis
- Designing Transition Architectures
- Developing the Implementation Roadmap
These activities may produce:
- Architecture Vision
- Stakeholder Map
- Business Capability Map
- Baseline Architecture
- Target Architecture
- Gap Analysis
- Transition Architecture
- Architecture Roadmap
These can broadly be considered Outputs of the architecture work.
For example:
Activity
Define the Target Application Architecture for the SAP transformation.
↓
Output
Global Target Application Architecture.
The key question for an Output is therefore:
What did the architecture work produce?
4. Deliverable: What Must Be Formally Reviewed and Approved?
A Deliverable is a more formal concept.
Large SAP transformation programs generate a significant amount of architecture content, but not every diagram, matrix, or working document needs to be formally approved by executive management or an Architecture Board.
For example, an organization may define an:
Architecture Definition Document
as a formal Deliverable.
This document may include:
- Business Architecture
- Data Architecture
- Application Architecture
- Technology Architecture
- Baseline Architecture
- Target Architecture
- Gap Analysis
The document may then be reviewed by an Architecture Board or Transformation Steering Committee.
The stakeholders formally agree that:
“This architecture will be adopted as the Target Architecture for the Global SAP Transformation.”
The Architecture Definition Document therefore becomes a formal Deliverable.
The key question for a Deliverable is:
What must be formally reviewed, agreed upon, approved, and delivered?
5. Artifact: How Is the Architecture Represented?
An Artifact represents a specific aspect of the architecture.
In TOGAF®, common forms of architecture artifacts include:
- Catalogs
- Matrices
- Diagrams
For an automotive Tier 1 SAP transformation, possible Artifacts include the following.
Catalogs
- Business Capability Catalog
- Application Portfolio Catalog
- Interface Catalog
- Data Entity Catalog
- Technology Portfolio Catalog
Matrices
- Business Process / Application Matrix
- Business Capability / Application Matrix
- Organization / Business Function Matrix
- Application / Data Matrix
- Application / Technology Matrix
Diagrams
- Business Capability Map
- Business Process Diagram
- Application Communication Diagram
- Data Flow Diagram
- System Landscape Diagram
- Target Architecture Diagram
For example, an Enterprise Architect may need to represent how OEM demand information flows through SAP and ultimately drives production and shipment.
The architecture might be represented as:
OEM
↓
EDI / Business Network
↓
SAP S/4HANA
↓
Supply Chain Planning
↓
Production Planning
↓
MES / Manufacturing Execution
↓
Warehouse / Logistics
↓
OEM
This Architecture Diagram is an Artifact.
6. What Is the Difference Between a Deliverable and an Artifact?
Deliverables and Artifacts are particularly easy to confuse.
Suppose the organization defines the:
Architecture Definition Document
as a Deliverable.
That Deliverable may contain a number of Artifacts, including:
- Business Capability Map
- Application Portfolio Catalog
- Business / Application Matrix
- Application Communication Diagram
- Target Architecture Diagram
- Gap Analysis
Conceptually, the relationship may look like this:
Architecture Definition Document
├── Business Capability Map
├── Application Portfolio Catalog
├── Business / Application Matrix
├── Target Application Architecture Diagram
└── Gap Analysis
A useful way to distinguish them is:
Deliverable = A formal architecture work product that is submitted and approved
Artifact = A specific representation used to describe the architecture
For an Enterprise Architect, the important question is therefore not how many PowerPoint slides have been created.
The more important questions are:
Which Artifacts support the required Architecture Decisions?
and
Which Deliverables need to be formally agreed upon to govern the transformation?
7. Outcome: What Does the Enterprise Actually Achieve?
Outcome is perhaps the most important concept among the four.
An Outcome is not an architecture document.
For example:
“We created an SAP S/4HANA Global Template.”
This alone should not be considered a business Outcome. It is closer to an Output or Deliverable of the transformation.
An Outcome describes the business result ultimately achieved through the transformation.
For an automotive Tier 1 supplier, potential Outcomes could include:
- Higher Global Process Standardization
- Lower inventory
- Higher OTIF
- Improved Production Schedule Adherence
- Shorter Planning Cycle Time
- Faster financial closing
- Lower IT TCO
- Fewer legacy applications
- Fewer interfaces
- Higher Master Data quality
For example:
Output
Global Target Architecture defined
↓
Deliverable
Architecture Definition Document approved by the Architecture Board
↓
Implementation
SAP S/4HANA Global Template rolled out across plants in Japan, North America, Europe, and Asia
↓
Outcomes
Global Process Standardization: 60% → 90%
Inventory: -15%
OTIF: 92% → 98%
Financial Closing: 7 days → 4 days
Legacy Applications: 120 → 50
This is where Enterprise Architecture becomes connected to measurable Business Value.
8. Why Outcomes Matter for Enterprise Architects in Automotive Tier 1 SAP Transformations
SAP implementation programs can easily become focused on implementing systems rather than achieving business outcomes.
Typical objectives may be expressed as:
- Implement SAP S/4HANA
- Implement SAP Integrated Business Planning
- Implement SAP Extended Warehouse Management
- Modernize the MES landscape
- Build a Global Template
However, these are primarily means of enabling transformation.
Enterprise Architects should look beyond the implementation itself and define the business Outcomes that these solutions are expected to enable.
For example:
Instead of:
Implement SAP IBP
consider:
Improve supply chain responsiveness to changes in OEM demand.
Instead of:
Implement SAP EWM
consider:
Improve inventory accuracy and stabilize JIT/JIS supply.
Instead of:
Implement SAP S/4HANA
consider:
Standardize global business processes and improve real-time management visibility.
The role of Enterprise Architecture is to connect technology and applications to measurable Business Outcomes.
9. Establishing Traceability from Outputs to Outcomes
In practice, establishing traceability across architecture and business value can be extremely useful.
For example:
| Business Goal | Outcome | Capability | Architecture Change | Artifact / Deliverable |
| Stabilize OEM supply | OTIF 98% | Supply Chain Planning | Global Planning Platform | Target SCM Architecture |
| Optimize inventory | Inventory -15% | Inventory Planning | Integrated IBP/S&OP | Capability / Application Matrix |
| Stabilize production | Improve Schedule Adherence | Production Planning | S/4HANA PP/DS | Target Application Architecture |
| Improve logistics efficiency | Reduce Logistics Cost | Warehouse Management | SAP EWM | Logistics Architecture |
| Improve management effectiveness | Financial Closing 7 → 4 days | Financial Management | S/4HANA Finance | Finance Target Architecture |
| Rationalize IT | IT TCO -20% | Application Management | Legacy ERP Consolidation | Application Portfolio Roadmap |
The important point is the direction of thinking:
Business Goal → Outcome → Capability → Architecture → SAP Solution
This is fundamentally different from beginning with:
SAP Product → Functionality → Business Application
If architecture work begins only with SAP products and functions, it can easily become Solution Design rather than Enterprise Architecture.
10. Outcomes Should Be Considered from OEM, Management, Plant, and IT Perspectives
For an automotive Tier 1 supplier, Outcomes should not be defined using only one KPI.
They should reflect the concerns of multiple stakeholders.
OEM / Customer Perspective
- Higher OTIF
- More stable JIT/JIS supply
- Faster response to demand changes
- Improved traceability
Corporate Management Perspective
- Higher ROIC
- Lower inventory
- Improved Working Capital
- Better Global Management Visibility
- Higher profitability
Plant / Supply Chain Perspective
- Higher Production Schedule Adherence
- Shorter Planning Cycles
- Higher Inventory Accuracy
- Better Capacity Visibility
- Stronger response to supplier risks
IT Perspective
- Fewer legacy applications
- Fewer interfaces
- Higher Global Template adoption
- Lower IT TCO
- Reduced Architecture Complexity
The Enterprise Architect therefore needs to connect:
Stakeholder Concern → Business Requirement → Architecture → Transformation → Outcome
11. Avoid Treating “Deliverable Completed” as “Transformation Successful”
A common risk in SAP transformation programs is to assume that the Enterprise Architecture work is complete once the architecture documentation has been delivered.
For example:
- Architecture Vision completed
- Capability Map completed
- Target Architecture completed
- Roadmap completed
These are Outputs or Deliverables.
The more important question is:
Did the Architecture Decisions actually produce the intended Outcomes?
For example, if an Architecture Decision was made to consolidate multiple ERP systems into a Global SAP environment, the organization should subsequently evaluate:
- How many legacy ERP systems were eliminated?
- How many interfaces were eliminated?
- How much did Global Process Standardization improve?
- Did Master Data quality improve?
- Was IT TCO reduced?
Only when this traceability exists can Enterprise Architecture clearly demonstrate the relationship:
Architecture → Business Value
12. Summary: Enterprise Architects Must Design Not Only What to Produce, but What the Enterprise Should Achieve
The distinction between Outputs, Deliverables, Artifacts, and Outcomes is more than Enterprise Architecture terminology.
For an automotive Tier 1 SAP transformation, the concepts can be understood as follows:
Output
= What is produced through EA activities
Deliverable
= What is formally reviewed and approved as an architecture work product
Artifact
= How the architecture is represented through Catalogs, Matrices, Diagrams, and other architecture content
Outcome
= What the enterprise ultimately achieves through the architecture and transformation
Applied to an SAP transformation, the overall flow becomes:
Stakeholder Concerns
↓
Business Requirements
↓
Architecture Activities
↓
Artifacts / Outputs
↓
Formal Deliverables
↓
Architecture Decisions
↓
SAP Implementation & Global Rollout
↓
Business Outcomes
For Enterprise Architects working with automotive Tier 1 suppliers, one of the most important principles is therefore:
Do not treat the implementation of SAP S/4HANA, SAP IBP, SAP EWM, or MES as the Outcome itself.
SAP is an enabler of transformation.
What an Enterprise Architect ultimately needs to explain is:
“Which Architecture Decisions contribute to which Business Outcomes?”
For example:
To improve responsiveness to changes in OEM demand, which Business Capabilities need to be strengthened, which Architecture components need to change, where should SAP solutions be applied, and how much should OTIF, inventory, and lead time improve as a result?
The ability to design and maintain this end-to-end traceability is one of the most important roles of an Enterprise Architect in a large-scale SAP transformation.
Reference Links
1. The Open Group — TOGAF Template Deliverables
The Open Group – TOGAF Template Deliverables
Supports: Deliverables, Artifacts, Architecture Work Products and the TOGAF content structure.
2. The Open Group — ADM Inputs and Outputs
The Open Group – ADM Input and Output Descriptions
Supports: Architecture Activities → Outputs and examples of formal architecture outputs.
3. SAP — Automotive Industry Software
SAP – Automotive Industry Software
Supports: SAP-enabled automotive transformation, supply chain, manufacturing and logistics.
4. SAP Learning — Automotive Supply Chain and Manufacturing
SAP Learning – SAP for Automotive Supply Chain and Manufacturing
Supports: SAP automotive supply-chain architecture, manufacturing, supply-chain execution and industry-specific capabilities.
5. SAP Help — Automotive Supplier Extensions
SAP Help – Automotive Supplier Extensions
Supports: Tier-1 automotive supplier processes, scheduling agreements, forecast delivery schedules, JIT delivery schedules and EDI.
6. SAP Help — JIT/JIS Processes
SAP Help – Next Generation Just-In-Time Supply to Production
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