This infographic distinguishes outputs, deliverables, artifacts, and outcomes in automotive Tier 1 SAP transformations.
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:
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.
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.
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:
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.
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:
These activities may produce:
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?
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:
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?
An Artifact represents a specific aspect of the architecture.
In TOGAF®, common forms of architecture artifacts include:
For an automotive Tier 1 SAP transformation, possible Artifacts include the following.
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.
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:
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?
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:
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.
SAP implementation programs can easily become focused on implementing systems rather than achieving business outcomes.
Typical objectives may be expressed as:
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.
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.
For an automotive Tier 1 supplier, Outcomes should not be defined using only one KPI.
They should reflect the concerns of multiple stakeholders.
The Enterprise Architect therefore needs to connect:
Stakeholder Concern → Business Requirement → Architecture → Transformation → Outcome
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:
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:
Only when this traceability exists can Enterprise Architecture clearly demonstrate the relationship:
Architecture → Business Value
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.
The Open Group – TOGAF Template Deliverables
Supports: Deliverables, Artifacts, Architecture Work Products and the TOGAF content structure.
The Open Group – ADM Input and Output Descriptions
Supports: Architecture Activities → Outputs and examples of formal architecture outputs.
SAP – Automotive Industry Software
Supports: SAP-enabled automotive transformation, supply chain, manufacturing and logistics.
SAP Learning – SAP for Automotive Supply Chain and Manufacturing
Supports: SAP automotive supply-chain architecture, manufacturing, supply-chain execution and industry-specific capabilities.
SAP Help – Automotive Supplier Extensions
Supports: Tier-1 automotive supplier processes, scheduling agreements, forecast delivery schedules, JIT delivery schedules and EDI.
SAP Help – Next Generation Just-In-Time Supply to Production
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.
Global SAP transformation requires more than an implementation team. This article explains how CIOs can…
Learn how the four Enterprise Domains in SAP Reference Business Architecture—Product & Service, Customer, Supply,…
Learn how automotive Tier 1 suppliers can use the APQC Process Classification Framework (PCF) to…
Successful SAP S/4HANA transformation requires more than an implementation methodology. This practical guide explains how…
Every TOGAF ADM phase, from Preliminary through Requirements Management, translated into an input/task/output/outcome checklist you…
BTEP (Business Transformation Enablement Program) provides important foundations for understanding TOGAF Business Transformation Readiness Assessment.…