Contents

Foreword by Thomas Saueressig ...................................................................................................... 17

Foreword by André Christ ................................................................................................................... 19
Preface ....................................................................................................................................................... 21

Part I SAP Enterprise Architecture Framework

1 Introduction to Enterprise Architecture with SAP 29

1.1 What Is Enterprise Architecture? .................................................................................... 30

1.2 How Is Enterprise Architecture Relevant in SAP Landscapes? ........................... 33

1.3 Evolution of Enterprise Architecture and the Enterprise Architect Role ...... 35

1.4 Challenges and Obstacles When Implementing Enterprise Architecture .... 38

1.5 Summary ................................................................................................................................... 40

2 The SAP Enterprise Architecture Framework 43

2.1 Overview of Enterprise Architecture Frameworks ................................................. 44

2.2 Enterprise Architecture Methodology ......................................................................... 46

2.2.1 Architecture Vision ................................................................................................ 49
2.2.2 Strategy and Motivation ...................................................................................... 53
2.2.3 Business Architecture ........................................................................................... 58
2.2.4 Solution Architecture ............................................................................................ 69
2.2.5 Technology Architecture ...................................................................................... 80
2.2.6 Roadmap and Transition ...................................................................................... 81
2.2.7 Requirements and Governance ......................................................................... 84
2.3 SAP’s Reference Content .................................................................................................... 89
2.3.1 SAP Reference Business Architecture .............................................................. 90
2.3.2 SAP Reference Solution Architecture ............................................................... 93
2.3.3 Additional Reference Content ............................................................................ 96
2.4 Preview of Tools and Practice .......................................................................................... 100

2.5 SAP’s Enterprise Architecture Services ......................................................................... 102

2.5.1 SAP's Enterprise Architecture Service Approach .......................................... 103

7
Contents Contents

2.5.2 Patterns and Modularization ............................................................................. 103

2.5.3 Applying the Service Methodology .................................................................. 106
2.6 Summary .................................................................................................................................. 107

3 Functional Integration of Enterprise Architecture 109

3.1 Business Process Management ....................................................................................... 110

3.2 Data Management ................................................................................................................ 115

3.3 Application Management .................................................................................................. 119

3.4 System versus Enterprise Architecture ........................................................................ 120

3.5 Additional Functions and Practices ............................................................................... 122

3.5.1 Portfolio Management ......................................................................................... 122
3.5.2 Requirements Management .............................................................................. 124
3.5.3 Strategy Management .......................................................................................... 125
3.5.4 Innovation Management ..................................................................................... 126
3.5.5 Risk Management .................................................................................................. 128
3.5.6 Value Management ............................................................................................... 129
3.5.7 Organizational Change Management ............................................................. 129
3.6 Isolated versus Integrated Functions ........................................................................... 130

3.7 Summary ................................................................................................................................... 131

4 Tool Capabilities for Enterprise Architecture 133

4.1 Generic Reference Architecture ...................................................................................... 134

4.2 Architecture Model ............................................................................................................... 135

4.3 Architecture Artifacts .......................................................................................................... 135

4.3.1 Representing Relationships in Artifacts ......................................................... 136
4.3.2 Representing Attribute Values in Artifacts .................................................... 138
4.4 Features and Capabilities ................................................................................................... 139

4.5 Integrations .............................................................................................................................. 140

4.6 Comparing Different Types of Enterprise Architecture Tools ............................ 141

4.7 Summary ................................................................................................................................... 143

8 8
 Contents

Part II SAP Enterprise Architecture Use Cases and Patterns

5 Cloud Transformation 147

5.1 Business and IT Context ..................................................................................................... 148

5.1.1 Business Context .................................................................................................... 149
5.1.2 IT Context .................................................................................................................. 154
5.2 Problem Statement .............................................................................................................. 160
5.2.1 Company Profile ..................................................................................................... 160
5.2.2 IT Landscape ............................................................................................................. 161
5.2.3 Organizational Aspects ........................................................................................ 164
5.3 Applying the Enterprise Architecture Transformation Approach .................... 166

5.4 Key Deliverables and Outcomes ..................................................................................... 171

5.4.1 Transformation Readiness .................................................................................. 172
5.4.2 Business Process ..................................................................................................... 174
5.4.3 Business Process Intelligence ............................................................................. 179
5.4.4 Application Architecture ...................................................................................... 182
5.4.5 Instance Strategy .................................................................................................... 187
5.4.6 Artificial Intelligence and Automation ............................................................ 190
5.4.7 Integration ................................................................................................................ 192
5.4.8 Extensibility .............................................................................................................. 197
5.4.9 Initiatives and Roadmap ...................................................................................... 200
5.4.10 Transition Scenario Evaluation .......................................................................... 205
5.5 Summary ................................................................................................................................... 210

6 Business Transformation 211

6.1 Business and IT Context ..................................................................................................... 211

6.1.1 Business Context .................................................................................................... 212
6.1.2 IT Context .................................................................................................................. 214
6.2 Problem Statement .............................................................................................................. 216
6.2.1 Company Profile ..................................................................................................... 216
6.2.2 IT Landscape ............................................................................................................. 219
6.3 Applying the Enterprise Architecture Transformation Approach .................... 220

6.4 Key Deliverables and Outcomes ..................................................................................... 222

6.4.1 Strategy Mapping ................................................................................................... 223
6.4.2 Business Model Patterns ...................................................................................... 230
6.4.3 Business Capability Map ...................................................................................... 233

9
Contents Contents

6.4.4 Application Architecture ...................................................................................... 238

6.4.5 Initiatives and Roadmap ...................................................................................... 241
6.4.6 Organizational Change Management ............................................................. 244
6.5 Summary ................................................................................................................................... 245

7 Sustainability 247

7.1 Business and IT Context ..................................................................................................... 248

7.1.1 Business Context .................................................................................................... 249
7.1.2 IT Context .................................................................................................................. 250
7.2 Problem Statement .............................................................................................................. 253
7.2.1 Company Profile ..................................................................................................... 254
7.2.2 IT Landscape ............................................................................................................. 254
7.3 Applying the Enterprise Architecture Transformation Approach .................... 256
7.4 Key Deliverables and Outcomes ..................................................................................... 260
7.4.1 Strategy Mapping ................................................................................................... 261
7.4.2 Business Capability Heatmap ............................................................................ 262
7.4.3 High-Level Solution Component Map ............................................................. 263
7.4.4 Application Architecture ...................................................................................... 264
7.4.5 Sustainability Roadmap ....................................................................................... 268
7.5 Summary ................................................................................................................................... 269

8 Mergers, Acquisitions, and Divestitures 271

8.1 Business and IT Context ..................................................................................................... 272

8.1.1 Business Context .................................................................................................... 272
8.1.2 IT Context .................................................................................................................. 274
8.2 Problem Statement .............................................................................................................. 277
8.2.1 Divestiture Use Case: Company Profile and IT Landscape ....................... 278
8.2.2 Acquisition Use Case: Company Profile and IT Landscape ....................... 279
8.3 Applying the Enterprise Architecture Transformation Approach .................... 280
8.3.1 Divestiture Use Case ............................................................................................. 280
8.3.2 Acquisition Use Case ............................................................................................. 281
8.4 Key Deliverables and Outcomes ..................................................................................... 283
8.4.1 Divestiture Use Case ............................................................................................. 283
8.4.2 Acquisitions Use Case ........................................................................................... 287
8.5 Summary ................................................................................................................................... 292

10 10
 Contents

9 Reducing Total Cost of Ownership 293

9.1 Understanding Total Cost of Ownership .................................................................... 293

9.1.1 Types of Costs .......................................................................................................... 293
9.1.2 Capital versus Operational Expenditures ....................................................... 297
9.2 Business and IT Context ..................................................................................................... 298
9.2.1 Business Context .................................................................................................... 298
9.2.2 IT Context .................................................................................................................. 301
9.2.3 Total Cost of Ownership Analysis ..................................................................... 304
9.3 Problem Statement .............................................................................................................. 306
9.3.1 Company Profile ..................................................................................................... 306
9.3.2 IT Landscape ............................................................................................................. 307
9.4 Applying the Enterprise Architecture Transformation Approach .................... 309

9.5 Key Deliverables and Outcomes ..................................................................................... 313

9.5.1 Business Process ..................................................................................................... 313
9.5.2 Business Capability ................................................................................................ 314
9.5.3 Template Assessment and Guidelines ............................................................ 315
9.5.4 Instance Strategy .................................................................................................... 317
9.5.5 Application Architecture ...................................................................................... 319
9.5.6 Transition Scenario and Evaluation ................................................................. 322
9.5.7 Initiatives and Roadmap ...................................................................................... 324
9.6 Summary ................................................................................................................................... 326

10 Patterns for Additional Use Cases 329

10.1 Rollout Strategy Assessment ........................................................................................... 330

10.1.1 Business Context .................................................................................................... 330
10.1.2 IT Context .................................................................................................................. 330
10.1.3 Problem Statement ................................................................................................ 331
10.1.4 Applying the Enterprise Architecture Transformation Approach .......... 331
10.1.5 Key Deliverables and Outcomes ........................................................................ 332
10.2 Two-Tier Architecture .......................................................................................................... 334
10.2.1 Business Context .................................................................................................... 334
10.2.2 IT Context .................................................................................................................. 335
10.2.3 Problem Statement ................................................................................................ 336
10.2.4 Applying the Enterprise Architecture Transformation Approach .......... 337
10.2.5 Key Deliverables and Outcomes ........................................................................ 338
10.3 Split Architecture ................................................................................................................... 339

11
11
Contents Contents

10.3.1 Business Context .................................................................................................... 339

10.3.2 IT Context .................................................................................................................. 340
10.3.3 Problem Statement ............................................................................................... 340
10.3.4 Applying the Enterprise Architecture Transformation Approach .......... 340
10.3.5 Key Deliverables and Outcomes ........................................................................ 341
10.4 Summary ................................................................................................................................... 342

Part III SAP LeanIX

11 SAP LeanIX Overview 345

11.1 SAP LeanIX as Part of an End-to-End Toolchain ....................................................... 345

11.2 Fact Sheets and Meta Model ............................................................................................ 347

11.2.1 Relationships among Fact Sheets ..................................................................... 348
11.2.2 Fact Sheet Subtypes .............................................................................................. 350
11.2.3 Fields and Tagging ................................................................................................. 351
11.3 The SAP LeanIX Application .............................................................................................. 351

11.4 The Time Dimension: Lifecycles and Transformations ......................................... 354

11.4.1 Lifecycle Fields ......................................................................................................... 354
11.4.2 Transformations ..................................................................................................... 355
11.5 Workspace Setup ................................................................................................................... 357

11.6 Summary ................................................................................................................................... 358

12 Working with SAP LeanIX 361

12.1 Dashboards ............................................................................................................................... 361

12.2 Common Tasks ........................................................................................................................ 362

12.2.1 Filters .......................................................................................................................... 362
12.2.2 Exploration ............................................................................................................... 363
12.2.3 Structuring Dashboards, Reports, and Diagrams ........................................ 365
12.3 Inventory ................................................................................................................................... 366

12.4 Tagging ...................................................................................................................................... 367

12.5 Reports ....................................................................................................................................... 370

12.5.1 Landscape Reports ................................................................................................. 371
12.5.2 Matrix Reports ......................................................................................................... 372

12 12
 Contents

12.5.3 Roadmaps ................................................................................................................. 375

12.5.4 Portfolio Reports ..................................................................................................... 379
12.5.5 Interface Circle Maps ............................................................................................ 380
12.6 Diagrams ................................................................................................................................... 381
12.6.1 Creating and Editing Diagrams ......................................................................... 381
12.6.2 Data Flow Diagrams .............................................................................................. 384
12.6.3 Free Draw Diagrams .............................................................................................. 386
12.7 Artificial Intelligence ............................................................................................................ 387

12.8 Presentations .......................................................................................................................... 388

12.9 Subscriptions, User Roles, and Authorizations ........................................................ 390

12.10 Collaboration ........................................................................................................................... 391

12.10.1 Favorites and Sharing ........................................................................................... 392
12.10.2 Comments ................................................................................................................ 392
12.10.3 Action Items and Questions ............................................................................... 393
12.10.4 Surveys ....................................................................................................................... 394
12.11 Quality Management and Governance ....................................................................... 396

12.12 Summary ................................................................................................................................... 398

13 Integration and Extensibility with SAP LeanIX 399

13.1 Export and Import ................................................................................................................. 399

13.2 Reference Catalogs ............................................................................................................... 402

13.3 Extending the Meta Model ............................................................................................... 406

13.4 Integrations .............................................................................................................................. 408

13.4.1 Autodiscovery of SAP Landscapes ..................................................................... 410
13.4.2 Prebuilt Integrations ............................................................................................. 410
13.4.3 Custom Integrations ............................................................................................. 411
13.5 Advanced Customization ................................................................................................... 413
13.5.1 Key Performance Indicators ................................................................................ 413
13.5.2 Automations ............................................................................................................ 415
13.5.3 Metrics ....................................................................................................................... 416
13.6 Summary ................................................................................................................................... 417

13
13
Contents Contents

14 SAP LeanIX in Practice 419

14.1 Application Portfolio Management .............................................................................. 419

14.2 Roadmap and Transformation Management ........................................................... 423

14.2.1 Use Case Description ............................................................................................. 423
14.2.2 Modeling the Baseline .......................................................................................... 425
14.2.3 Creating Program Structures and Milestones .............................................. 427
14.2.4 Modeling the Transformations .......................................................................... 429
14.2.5 Simulating Transformation in Reports ........................................................... 433
14.2.6 Executing Transformations ................................................................................ 434
14.3 Clean Core Modeling ............................................................................................................ 435

14.4 Summary ................................................................................................................................... 437

Part IV Enterprise Architecture Practice

15 Setting Up an Enterprise Architecture Practice 441

15.1 Enterprise Architecture Practice Overview ................................................................ 442

15.2 Enterprise Architecture Maturity ................................................................................... 445

15.3 Organizational Setup ........................................................................................................... 448

15.4 Enterprise Architecture Processes .................................................................................. 455

15.4.1 Architecture Development .................................................................................. 456
15.4.2 IT Investments and Program Portfolio ............................................................ 457
15.4.3 Alignment of Business with IT ........................................................................... 460
15.4.4 Solution and Process Documentation ............................................................. 460
15.5 Enterprise Architecture Governance ............................................................................. 461
15.5.1 Architecture Board ................................................................................................. 461
15.5.2 Architecture Principles and Guardrails ........................................................... 463
15.5.3 Planning and Change Management ................................................................ 466
15.5.4 Linking to Other Governance Layers ................................................................ 467
15.6 Enterprise Architecture Skills and Enablement ....................................................... 469
15.6.1 Business-Related Skills ......................................................................................... 470
15.6.2 IT-Related Skills ....................................................................................................... 471
15.6.3 Enterprise Architecture-Related Skills ............................................................. 472
15.6.4 General Skills ............................................................................................................ 472
15.6.5 Learning and Enablement ................................................................................... 474
15.6.6 Conferences .............................................................................................................. 474

14 14
 Contents

15.7 Hiring an Enterprise Architecture Team ...................................................................... 476

15.8 Enterprise Architecture Communication and Communities .............................. 477

15.8.1 Internal Community .............................................................................................. 477
15.8.2 External Communities and User Groups ........................................................ 479
15.8.3 Communication ...................................................................................................... 479
15.9 Use Cases for Practice Evolution ..................................................................................... 480
15.9.1 Establishing an Enterprise Architecture Practice ......................................... 480
15.9.2 Combining Two Architecture Practices of Different Maturities ............. 482
15.10 Summary ................................................................................................................................... 484

16 Enterprise Architecture at SAP 487

16.1 Overview of Enterprise Architecture Practices at SAP .......................................... 487

16.2 Enterprise Architecture in Advisory and Services ................................................... 490

16.2.1 Architecture Advisory (Discover and Select Phases) ................................... 490
16.2.2 Architecture Service Delivery (Select, Adopt, and Derive Phases) .......... 491
16.2.3 Scaling via SAP Transformation Hub (Internal Scaling) ............................. 492
16.3 Enterprise Architecture in SAP Product Development .......................................... 495
16.3.1 Technical Component Architecture ................................................................. 495
16.3.2 Business Function Architecture ......................................................................... 497
16.4 Enterprise Architecture in Internal IT at SAP ............................................................. 498
16.4.1 Architecture Services ............................................................................................. 498
16.4.2 Collaboration with Development ..................................................................... 500
16.4.3 SAP’s Strategic Transformation Portfolio ....................................................... 501
16.4.4 SAP’s In-House Use of SAP LeanIX .................................................................... 502
16.5 Summary ................................................................................................................................... 507

Part V Outlook and Conclusion

17 Next Big Trends in Architecture 511

17.1 AI-Supported Enterprise Architecture Transformation ........................................ 512

17.1.1 Relevance of AI ........................................................................................................ 513
17.1.2 Outlook ...................................................................................................................... 516

15
15
Contents Contents

17.2 The Enterprise Architecture Network ........................................................................... 517

17.2.1 Relevance of Enterprise Architecture Networks .......................................... 518
17.2.2 Outlook ...................................................................................................................... 520
17.3 Enterprise Architecture-Driven Innovation ............................................................... 520
17.3.1 Relevance of Enterprise Architecture-Driven Innovation ......................... 520
17.3.2 Outlook ...................................................................................................................... 521
17.4 Continuous Clean Architecture ....................................................................................... 521
17.4.1 Relevance of Continuous Clean Architecture ............................................... 522
17.4.2 Outlook ...................................................................................................................... 524
17.5 Global Networks for Enterprise Architecture ........................................................... 524
17.5.1 Relevance of the Metaverse ................................................................................ 525
17.5.2 Outlook ...................................................................................................................... 526
17.6 Agile and Iterative Architecture ...................................................................................... 526
17.6.1 Relevance of Agile and Iterative Architecture ............................................... 527
17.6.2 Outlook ...................................................................................................................... 529
17.7 Quantum Computing ........................................................................................................... 529
17.7.1 Relevance of Quantum Computing .................................................................. 530
17.7.2 Outlook ...................................................................................................................... 533
17.8 Summary ................................................................................................................................... 534

18 Conclusion, Summary, and Key Takeaways 535

Appendices 545

A Abbreviations and Glossary .............................................................................................. 545

B The Authors .............................................................................................................................. 551

Index .......................................................................................................................................................... 553

16 16
 Chapter 2
2
The SAP Enterprise Architecture
Framework
With its own enterprise architecture framework, SAP empowers busi-
nesses to gain comprehensive control over their IT landscape, facilitates
agile decision-making, and accelerates digital transformation journeys.
Delve deeply into this chapter, where we explore SAP EA Framework and
its five primary components: methodology, reference content, tools,
practice, and services.

SAP offers its own enterprise architecture framework, SAP EA Framework, which we
introduce in this chapter. With many frameworks already available in the market, one
might wonder why SAP introduced yet another one. SAP EA Framework stands out as a
comprehensive framework encompassing methodology (with a practitioner focus),
reference content, tooling, and practice. In this chapter, we’ll explore all the compo-
nents of this framework.
In general, we define an enterprise architecture framework as a well-structured, holistic
approach that provides a comprehensive view of the key components of an organiza-
tion, their interrelationships, and the principles guiding their design and evolution. It’s
essentially a blueprint that defines the structure and operation of an organization,
integrating strategic, business, and technology planning. An enterprise architecture
framework provides a standardized methodology for organizing the complex systems
and processes of an enterprise into a coherent and understandable structure, enabling
effective decision-making and strategic alignment.
The need for an enterprise architecture framework arises from the complexities inher-
ent in managing large-scale organizations. With the rapid pace of technological ad-
vancements and growing business demands, organizations often grapple with the
challenge of integrating and aligning their IT systems with business goals. An enter-
prise architecture framework helps mitigate these challenges by providing a clear view
of the organization’s structure and operations. It helps identify redundancies, inconsis-
tencies, and gaps in the organizational structure and processes, facilitating their timely
resolution.
Looking back, the importance of enterprise architecture frameworks has grown with
the increasing complexity of business and IT landscapes. In the past, many organiza-
tions suffered from poor decision-making and inefficient business processes due to

43
2 2 The SAP Enterprise Architecture Framework
The SAP Enterprise Architecture Framework

their lack of a clear understanding of their organizational structures and operations.

Without an enterprise architecture framework, it was difficult for organizations to
align their IT systems and processes with their business goals, leading to wastage of
resources and missed opportunities. Moreover, the absence of a standardized method-
ology for organizing and managing the organizations’ structure and operations often
resulted in chaos and confusion.
Moving forward, the requirements for an enterprise architecture framework are set to
increase even further. With the advent of digital transformation, cloud computing, AI,
and other technological advancements, managing an organization is expected to get
dramatically more complicated. Having an enterprise architecture framework will be
crucial in helping organizations navigate this complexity by providing a clear, compre-
hensive, and standardized view of their organizational structures and operations. It
will play a key role in aligning IT systems and processes with business goals, facilitating
strategic planning and decision-making, and optimizing resource utilization. By doing
so, enterprise architecture frameworks will enable organizations to stay agile, compet-
itive, and relevant in the fast-paced business environment of the future.

2.1 Overview of Enterprise Architecture Frameworks

There are several main enterprise architecture frameworks available on the market,
and each has its own strengths and areas of focus (see Figure 2.1).

TOGAF Zachman Gartner

Scope and Coverage

Flexibility and Adaptability

Maturity and Adoption

Reference Models and Content

Ease of Use and Practicality

Figure 2.1 Comparison of Important Enterprise Architecture Frameworks

The Zachman Framework is one of the earliest and most influential. It provides a struc-
tured way of viewing and defining an enterprise, focusing on six different perspectives
(planner, owner, designer, builder, subcontractor, and functioning enterprise) across
six different categories (data, function, network, people, time, and motivation).

44 44
 2.1 2 The SAP
Overview EnterpriseArchitecture
of Enterprise ArchitectureFrameworks
Framework

The Open Group Architecture Framework (TOGAF), on the other hand, provides a more
detailed approach, offering a methodology for designing, planning, implementing, and
governing an enterprise’s IT architecture. Other notable enterprise architecture frame- 2
works include the Federal Enterprise Architecture (FEA), which is used by the US federal
government, and the Gartner Enterprise Architecture Framework, which emphasizes
the strategic role of enterprise architecture frameworks in achieving business out-
comes. Each of these frameworks offers its own unique approach to managing enter-
prise architecture, and the choice among them often depends on the specific needs and
context of the organization.
Note that the choice of a particular enterprise architecture framework often depends
on the specific requirements of the organization, the nature of its IT infrastructure, and
the expertise of its staff. It is notable that most of SAP’s customers who seek an enter-
prise architecture framework have embraced TOGAF.
However, SAP has introduced its own framework: SAP EA Framework. This framework
doesn’t aim to reinvent the wheel or propose a completely different approach to enter-
prise architecture, compared with established frameworks such as TOGAF. On the con-
trary, SAP EA Framework aligns closely with the TOGAF framework, incorporating
many of its terminologies and concepts. Rather than focusing heavily on theoretical
concepts, SAP EA Framework emphasizes practicality. It’s specifically designed for prac-
titioners who wish to conduct enterprise architecture planning activities within their
SAP-focused architecture.
One of the significant advantages of using SAP EA Framework is its tight integration of
SAP reference content and SAP enterprise architecture tools within the enterprise
architecture framework. This is a distinct advantage over frameworks like TOGAF and
others that introduce the concept of reference content and tooling to be used in the
development process of enterprise architecture artifacts. Unlike these other frame-
works, the SAP EA Framework provides out-of-the-box content that can be used imme-
diately, offering practical utility to its users.
Figure 2.2 illustrates the five foundational elements of SAP EA Framework: methodol-
ogy, reference content, tools, practice, and services.
The methodology encompasses the core principles of SAP EA Framework, such as the
architecture domains, elements of the meta model, terminologies, and artifacts. The
reference content primarily concentrates on strategy, business architecture, and solu-
tion architecture. With SAP’s recent acquisition of LeanIX, the tooling component has
become even more integral to SAP EA Framework, with SAP Signavio and SAP Cloud
ALM emerging as key resources for the enterprise architect. Enterprise architecture
practice is organizational implementation by adopting the methodology and setting
up appropriate governance and change management processes. Finally, the services
outline how the methodology, reference content, and tools can be utilized in real-world
enterprise architecture planning activities and can be sourced internally or externally.

45
2 2 The SAP Enterprise Architecture Framework
The SAP Enterprise Architecture Framework

Methodology

Reference
Services Architecture
SAP
Content
Enterprise
Architecture
Framework

Practice Tooling

Figure 2.2 SAP EA Framework and Its Components

Continuously growing the amount of reference architecture content and its availabil-
ity in the end-to-end transformation toolchain will make the adoption of SAP EA
Framework more attractive, as reference content will be able to blend with customer-
specific content.
The following sections will delve deeper into each of these five foundational elements
of SAP EA Framework.

2.2 Enterprise Architecture Methodology

The first pillar of SAP EA Framework is the methodology for developing enterprise
architecture artifacts. Figure 2.3 highlights this overall approach and the relationships
among the different domains, including some high-level meta model connections
between selected enterprise architecture artifacts like the business strategy model and
the business capability model.
Let’s take a closer look at each section of the methodology:
1. Architecture vision
The architecture vision domain outlines the expected outcomes of the architecture
work. It includes identifying stakeholders, gathering business and IT contexts, and
defining the scope and requirements of the next project phases.
2. Strategy and motivation
The strategy and motivation domain derives objectives from company priorities and
long-term goals. It aligns enterprise architecture with business strategy and clearly
communicates the benefits and rationales behind architectural decisions to moti-
vate stakeholders.

46 46
 2 The
2.2 SAP Enterprise
Enterprise Architecture
Architecture Framework
Methodology

Architecture Strategy and Business Architecture Solution Architecture Technology Roadmap and
Vision Motivation Architecture Transition

Business Solution
2
Capability Capability Capability
View Model Model
b
Business
Strategy
Model
Business Transition
Process Model
View Process Solution
Model Process
Model

Business
Context Technology
Model Business Solution Model
Data Data Data
View Model Model

Business Application
Organization Role
View Role
Model Model

Requirements and Governance

Figure 2.3 SAP EA Framework Methodology Overview

3. Business architecture
The business architecture domain includes all business aspects, including capabili-
ties, processes, data, and organizational structure. It facilitates stakeholder discus-
sions and decisions based on agreed-upon business terms.
4. Solution architecture
The solution architecture domain focuses on aligning technology solutions with
business goals and requirements. It serves as a bridge between the business and
technical sides of an organization to ensure effective technology implementations.
5. Technology architecture
The technology architecture domain documents the delivery of target solution archi-
tecture through technology components like operating systems, hardware, and net-
works. It details the deployment of IT systems in specific data center locations.
6. Roadmap and transition
The roadmap and transition domain uncovers project growth opportunities and
manages system or process transitions. It involves planning migrations and execut-
ing changes to achieve project objectives efficiently.
7. Requirements and governance
The requirements and governance domain encompasses governance artifacts like
risk catalogs and architecture principles. It captures important architecture deci-
sions and manages requirements across all architecture domains.

Within each distinct enterprise architecture domain, SAP EA Framework outlines the
development of specific artifacts. These artifacts are similar in function to some of the
artifacts in TOGAF, but SAP EA Framework consistently emphasizes practicality in the
context of SAP during artifact development. SAP EA Framework also concentrates

47
 2 2 The SAP Enterprise Architecture Framework
The SAP Enterprise Architecture Framework

solely on the critical artifacts necessary for architectural planning. Figure 2.4 provides a
detailed overview of the artifacts as per the enterprise architecture domain.

Architecture Strategy and Business Architecture Solution Technology Roadmap and

Vision Motivation Architecture Architecture Transition

Stakeholder Business Context Business Product Map Environments and Architecture

Map Diagram Capability Map Location Diagram Roadmap
Solution
Statement of Business Strategy Business Component Work Breakdown
Architecture Work Map Process Catalog Diagram Structure

Solution Context Business Model Business Value Solution Value

Diagram Canvas and Flow Diagram Flow Diagram
Patterns
Solution Concept Organization Solution Process
Diagram Map Flow Diagram

Business Solution Data Flow

Data Catalog Diagram

Business Software
Role Catalog Distribution
Diagram
Business Footprint
Diagram Application
Architecture
Overview Diagram

Conceptional Data
Diagram

Requirements and Governance

Architecture Principles Architectural Decision

Requirements Catalog Risk Catalog
Catalog Catalog

Figure 2.4 SAP EA Framework Artifacts Overview

We’ll explain each of the artifacts in the following sections. In addition, we’ll demon-
strate in this book how the artifacts are developed as part of use cases. For that, refer to
Chapter 5 through Chapter 10.

Meta Model of SAP Enterprise Architecture Framework

SAP EA Framework includes an internal meta model that defines all the main entities
used in its methodology and illustrates their interconnections. However, the complex-
ity of this meta model can be overwhelming, meaning it can provide little clarity for the
reader trying to comprehend the subsequent content. While the meta model ensures
consistency in navigating between artifacts and aids in maintaining coherence in refer-
ence content and tool development, it’s not essential for practitioners to grasp every
detail of the metal model. The primary focus for users should be on leveraging the
framework’s practical applications rather than delving into the intricacies of the meta
model.
Chapter 11 offers an overview of the SAP LeanIX meta model, which is leaner and easier
to comprehend but still aligns with the overall SAP EA Framework meta model. Those
who are interested in understanding the concept of a framework meta model should
refer to Chapter 11.

48 48
 2 The
2.2 SAP Enterprise
Enterprise Architecture
Architecture Framework
Methodology

2.2.1 Architecture Vision

The architecture vision domain provides an initial sketch of the desired outcomes of 2
the architecture work. It focuses on identifying relevant stakeholders and gathering
essential context from both business and IT perspectives. This domain includes already
formulated business and IT strategies, which will be refined for the selected scope. Ulti-
mately, it produces the statement of architecture work, which defines the scope and
requirements for the subsequent phases of the project.
We’ll walk through the key components of the architecture vision in the following sec-
tions.

Stakeholder Map
Performing a stakeholder analysis is a crucial preliminary step in enterprise architec-
ture planning because it can help an organization identify and prioritize the needs, ex-
pectations, and concerns of various stakeholders within the organization. By compre-
hensively understanding the stakeholders involved―including executives, employees,
customers, and partners―an organization can align its architectural efforts with strate-
gic objectives and ensure that the resulting architecture meets the diverse requirements
of all involved parties. This analysis enables architects to anticipate potential challenges,
mitigate risks, and foster stakeholder buy-in throughout the architectural planning and
implementation processes.
Creating a stakeholder map is a key part of stakeholder analysis. As illustrated in Figure
2.5, a stakeholder map is typically divided into four distinct quadrants that categorize
stakeholders as promoters, enthusiasts, resisters, and opponents.
High

IV. Opponents (Satisfy) I. Promoters (Actively Engage)

ƒ Targeted actions, full focus. ƒ Target actions to keep positive attitudes.
ƒ The purpose is to change their opinion. ƒ Use their influence to increase buy-in on the
ƒ Decrease influence on project by isolating or project.
Level of Influence

replacing them.

III. Resisters (Monitor and Respond) II. Enthusiasts (Inform)

ƒ Slow, negative. No special activities needed. ƒ Try to use them as promoters and increase
ƒ Watch them carefully. their positive attitude to get them to the active
promoters level.
Low

Negative Positive
Attitude

Figure 2.5 Stakeholder Map

49
2 2 The SAP Enterprise Architecture Framework
The SAP Enterprise Architecture Framework

The initial stage of creating a stakeholder map involves consulting the organizational
chart to pinpoint relevant stakeholders. These individuals often include those most
impacted by architectural changes, those executing significant influence over the
architecture, and those with a vested interest in the success of the architectural devel-
opment process. Subsequently, stakeholders are analyzed in accordance with the
defined quadrants of the stakeholder map. This analysis informs the formulation of
tailored action plans to effectively manage each stakeholder group. Stakeholder man-
agement then emerges as an essential, ongoing endeavor throughout the entire archi-
tectural development cycle, demanding nuanced strategies tailored to the unique
dynamics of each stakeholder cohort.

Statement of Architecture Work

The statement of architecture work (SoAW) plays an important role in the enterprise
architecture planning process by providing a clear and comprehensive outline of the
objectives, scope, and constraints of the architectural initiative. By defining the pur-
pose and goals of the enterprise architecture effort up front, the SoAW serves as a guid-
ing document that aligns architectural endeavors with the overarching strategic vision
of the organization. The SoAW provides clarity that helps stakeholders understand the
intended outcomes of the architecture planning and implementation processes and
ensures that efforts remain focused and coherent throughout.
Following the TOGAF framework, a SoAW typically contains the following elements:
 Title
 Architecture project request and background
 Architecture project description and scope
 Overview of architecture vision
 Specific change-of-scope procedures
 Roles, responsibilities, and deliverables
 Acceptance criteria and procedures
 Architecture project plan and schedule
 Approvals

The SoAW facilitates effective communication and collaboration among stakeholders

by establishing a common understanding of the architectural initiative. By clearly
articulating the scope, deliverables, timelines, and resource requirements, the SoAW
enables stakeholders to align their expectations and commitments accordingly. This
alignment fosters a sense of ownership and accountability among stakeholders, pro-
moting engagement and buy-in throughout the enterprise architecture planning pro-
cess. Additionally, the SoAW serves as a baseline for measuring progress and assessing
the success of the architecture, providing a framework for iterative improvements and
adjustments as the architectural initiative unfolds.

50 50
 2 The
2.2 SAP Enterprise
Enterprise Architecture
Architecture Framework
Methodology

Solution Context Diagram

The solution context diagram serves as a comprehensive visualization of the intended
2
solution within enterprise architecture endeavors. Its primary objective is to offer a
clear and accessible depiction of the aspired-to solution, ensuring that it’s easily under-
standable by both technical and nontechnical stakeholders. By encapsulating the
required business capabilities to be fulfilled by the architecture, the diagram provides
a strategic roadmap for aligning the solution with organizational objectives. Key pre-
requisites for developing the solution context diagram include the creation of a stake-
holder map and an SoAW, which help contextualize the solution within the broader
enterprise landscape. Particularly for stakeholders from the business domain, the solu-
tion context diagram serves as a vital tool for conveying how the envisioned solution
interfaces with various organizational units, roles, and business functions. Its impor-
tance lies in guiding architectural decision-making, fostering consensus among stake-
holders, and promoting alignment between the solution and business objectives
throughout the architecture planning and implementation phases.
To create the solution context diagram, follow these steps and use the template from
Figure 2.6:
1. Translate learning into business capabilities
Begin by translating your understanding of the aspired-to solution into business
capabilities. These capabilities describe what the solution can do in terms of main
functions or features, expressed in business terminology. Aim for a list of five to ten
main capabilities that capture the essence of the solution’s intended functionality.

<Envisioned Solution> As-Is Landscape

Description of the solution context by…

9 Business requirements
<Application
Application1>
<Application 1>
1
Role 1 9 Business capabilities
9 Additional solution context
<Application 3>

<Application
Application 2>
2
Role
R l 2

Figure 2.6 Solution Context Diagram

2. Identify architectural components and organizational elements

After defining the business capabilities, identify the architectural components
needed to support them. Consider related organizational units, business roles, and
existing applications. Use the stakeholder map to reference users and roles. This
ensures that the solution context diagram reflects both technical and organizational

51
51
2 2 The SAP Enterprise Architecture Framework
The SAP Enterprise Architecture Framework

aspects, providing a comprehensive view of the solution’s ecosystem and alignment

with stakeholder needs.
3. Iterate and refine
Iterate on the solution context diagram based on feedback from stakeholders and
validation against business requirements. Refine the diagram to ensure clarity, com-
pleteness, and accuracy in representing the intended solution and its alignment
with organizational goals.

Solution Concept Diagram

The solution concept diagram serves as an important tool for crafting a high-level por-
trayal of the proposed solution. It offers a concise yet comprehensive overview of the
solution, capturing its key components, functionalities, and interrelationships. This
diagram is instrumental in aligning the solution with the strategic objectives and
requirements of the architecture engagement. By distilling complex solution elements
into a visual representation, it helps stakeholders gain a clear understanding of the pro-
posed approach and its intended outcomes. Furthermore, the solution concept dia-
gram serves as a communication tool, facilitating discussions among stakeholders and
fostering consensus on the proposed solution’s viability and alignment with business
goals. Overall, this diagram plays a crucial role in guiding decision-making processes
and ensuring that the proposed solution effectively addresses the needs and objectives
of the enterprise architecture initiative.
To create a solution concept diagram like the one illustrated in the template in Figure
2.7, you must follow several key steps:
1. Identify high-level architectural building blocks
Begin by identifying the high-level architectural building blocks required to fulfill
the key objectives and business capabilities outlined in the solution context dia-
gram. These building blocks should represent the fundamental components neces-
sary to realize the desired solution.
2. Translate business-oriented capabilities into architecture building blocks
Translate the business-oriented capabilities described in the solution context into
corresponding architecture building blocks. This involves mapping each business
capability to the architectural elements necessary to support it, ensuring alignment
between business requirements and architectural components.
3. Outline relationships among building blocks
Establish the relationships among the identified building blocks within the solution
concept diagram. These relationships may encompass various types, such as
request-response interactions or information flows, and should reflect the depen-
dencies and interactions among architectural components.
4. Incorporate users, roles, and organizational units
Integrate users, roles, and organizational units into the solution concept diagram,
illustrating their relationships with the architecture building blocks. This step

52 52
 2 The
2.2 SAP Enterprise
Enterprise Architecture
Architecture Framework
Methodology

ensures that the diagram reflects the organizational context and depicts how differ-
ent stakeholders interact with and utilize the solution’s components.
2

<Solution Name>

<Building Block> <Building Block>

<Building Block> <Building Block> <Building Block> <Building Block>

Backend Systems

<System 1> <System 2> <System 3>

Figure 2.7 Solution Concept Diagram

2.2.2 Strategy and Motivation

This enterprise architecture domain is crucial for deriving objectives based on the com-
pany’s strategic priorities and long-term goals, and it forms the first part of the busi-
ness architecture. It ensures that the enterprise architecture aligns with the overall
business strategy. Additionally, it plays a vital role in motivating stakeholders by
clearly communicating the benefits and rationale behind architectural decisions and
transformations, thereby establishing a compelling vision for the company’s future.
Let’s dive into the key components of the strategy and motivation domain next.

Business Context Diagram

A business context diagram serves as a crucial artifact in enterprise architecture plan-
ning due to its ability to offer a comprehensive and accessible depiction of how a busi-
ness interfaces with its external environment. By visually illustrating the various
entities that interact with the business―including customers, suppliers, partners, and
regulatory bodies―the diagram provides a holistic view of the organization’s ecosys-
tem. Additionally, it describes the flows of information, resources, and materials
between the business and these external entities, shedding light on the complex net-
works and dependencies that underpin business operations.

53
53
 2 2 The SAP Enterprise Architecture Framework
The SAP Enterprise Architecture Framework

The initial step of constructing the business context diagram entails defining the orga-
nizational entities―such as customers, suppliers, competitors, and financial institu-
tions―as named business actors. Subsequently, high-level business flows among these
actors must be outlined. These include product flow, payment flow, and information
flow, among others. This process provides a structured framework for capturing the
interactions and exchanges that occur within the business environment. A standard
template for the business context diagram, exemplifying these defined entities and
flows, is depicted in Figure 2.8. This template serves as a visual reference point for orga-
nizing and representing the complex web of relationships and activities essential to
the business’s functioning.

Customers Suppliers
<Business Flow>
<Business Flow>
Business Actor <Business Flow> Business Actor

<Business Flow>
<Business Flow>
Business Actor <Company> Business Actor
<Business Flow>

<Business Flow>
<Business Flow>
Business Actor <Business Flow> Business Actor

w>
Flo
ess <Business Flow>
in
us
<B

Competitors Addition Entities

Business Actor Business Actor

Figure 2.8 Business Context Diagram

A business context diagram offers several benefits, including providing insights into
the complex networks of relationships that generate value through dynamic ex-
changes among individuals, groups, and organizations. By visually representing these
relationships and flows of information and resources, and by highlighting the most
critical business activities for value creation, the diagram promotes strategic clarity.
This clarity enables stakeholders to prioritize efforts and resources in their efforts to
optimize key processes and relationships, which helps them ultimately drive efficiency
and effectiveness in operations. Additionally, the diagram serves as a catalyst for inno-
vation by identifying intersections where information and material flows converge.
This in turn presents the organization with opportunities for the development of new
products, services, and processes that enhance its competitive advantage.

54 54
 2 The
2.2 SAP Enterprise
Enterprise Architecture
Architecture Framework
Methodology

Strategy Map
In enterprise architecture planning, a strategy map is a crucial tool for effectively trans-
2
lating business strategy into actionable business architecture. It aids in establishing a
clear connection between the strategy map and business capabilities. Moreover, it pro-
vides a comprehensive view of the organization’s readiness to adopt new or improved
business changes. Significantly, it helps align business and IT priorities, ensuring that
business-critical priorities are adequately addressed in the IT architecture and road-
map design. Thus, a strategy map serves as a pivotal component in achieving strategic
alignment and facilitating business transformation.
The main components of a strategy map and what they do are as follows:
 Strategic priorities are the catalysts that drive change within an organization. They
serve as the guiding principles that shape the organization’s direction and decision-
making processes.
 Business goals, on the other hand, represent the end state that stakeholders aim to
achieve. They provide a clear vision of what success looks like for the organization.
 Objectives, also known as value drivers, are measurable short-term or midterm tar-
gets that have direct relevance to the business. They come with defined target values
and schedules, acting as stepping stones on the way to reaching the business goals.
 Lastly, business capabilities reflect the organization’s potential to carry out business
activities successfully, attain its objectives, and deliver value to its customers. They
underline the competencies and resources of the organization in executing its stra-
tegic priorities and achieving its goals.

The principal procedures for constructing a strategy map like the one in Figure 2.9
include the following:
1. Understand the strategy
Familiarize yourself with the strategic priorities of your company or business unit.
These are often outlined in strategic documents specific to the corporation or busi-
ness division, which may be accessible internally or publicly. Additionally, conduct
interviews with key stakeholders who play a role in shaping the strategy of the tar-
geted organizational unit. This can provide valuable insights and information. To
enhance your understanding, compare this information with external analysis from
public sources, such as industry trends.
2. Clarify the objectives
From the strategic priorities, extrapolate the specific business objectives of your
organization. These objectives provide more detail on the strategic priorities. They
may be numerous, and sometimes, you may need to arrange them in a hierarchical
structure. To maintain a manageable scope, we suggest aligning no more than three
to five objectives with each strategic priority.

55
55
 2 2 The SAP Enterprise Architecture Framework
The SAP Enterprise Architecture Framework

3. Identify value drivers

Link the appropriate value drivers to the established objectives. Value drivers, or key
performance indicators, make the business objectives quantifiable and are typically
associated with a timeframe. If you can’t determine value drivers from the strategy
documents available, or if there’s a need to expedite the strategy mapping process,
you can bypass this step and directly associate business capabilities with business
objectives.
4. Map business capabilities
Identify the enabling and core business capabilities that relate to value drivers. In
this phase, you bridge the gap between strategy and operations by aligning business
capabilities with value drivers (or with business objectives, if you omitted the previ-
ous step). Concentrate on the most crucial and distinctive business capabilities,
rather than attempting to map all necessary capabilities. Consequently, you’ll have
an initial business capability map that supports the organization’s strategy, which
can serve as a foundation for further development of the business capability map
within the business domain.

Strategic
Sustainability
Priorities

Demonstrate
Meet shifting
responsibility as a Raise corporate
Business caring company to
consumer
reputation as a
Goals preference with
attract best-in-class sustainable brand
“green” products
employees

Actively identify, Understand and

Create a workplace Lower the carbon Minimize our monitor, and address social,
Value Create a gender-
mitigate the ethical, and
free from fatalities footprint of our operational water
Drivers balanced workforce
and injuries own operations footprint catastrophic hazards environmental risks
within our business in supply chains

Product and
EHS Incident Carbon Footprint Supplier
Not Yet Defined Not Yet Defined Not Yet Defined
Management Management Sustainability
Assessment
Business
Capabilities

Health and Safety

Management

Figure 2.9 Strategy Map

Business Model Canvas

The business model canvas (BMC) is a strategic management tool that provides a struc-
tured framework for visualizing and analyzing the key components of a business model.
It consists of nine building blocks, as shown in Figure 2.10: key partnerships, key activi-
ties, key resources, value propositions, customer relationships, channels, customer

56 56
 2 The
2.2 SAP Enterprise
Enterprise Architecture
Architecture Framework
Methodology

segments, cost structure, and revenue streams. Each building block represents a funda-
mental aspect of the business, and using these building blocks to create the BMC allows
stakeholders to understand how different elements interact and contribute to the over- 2
all business model. The BMC enables organizations to articulate and refine their busi-
ness strategies, identify areas for innovation and improvement, and align various
business functions with common goals. It promotes a holistic view of the business
model, fostering collaboration and informed decision-making among different depart-
ments and stakeholders.

Key Partnerships Key Activities Value Propositions Customer Relationships Customer Segments

Key Resources Channels

Cost Structure Revenue Streams

Figure 2.10 Business Model Canvas

In the context of enterprise architecture, the BMC serves as a crucial artifact. Firstly, it
provides a structured framework for enterprise architecture practitioners to analyze
and understand the business architecture of an organization. By mapping out the vari-
ous components of the business model, enterprise architecture teams can identify
dependencies, synergies, and potential gaps between different business functions and
processes. This understanding enables them to develop coherent and aligned architec-
ture blueprints that support the organization’s strategic objectives. Secondly, the BMC
helps enterprise architecture practitioners to communicate complex business con-
cepts and strategies in a visual and easily understandable format. This facilitates stake-
holder engagement and buy-in, as it allows for more meaningful discussions about the
organization’s business model and how it intersects with technology and IT infrastruc-
ture. Ultimately, the BMC serves as a bridge between business strategy and enterprise
architecture, helping organizations to translate their strategic priorities into actionable
architectural decisions.

57
57
2 2 The SAP Enterprise Architecture Framework
The SAP Enterprise Architecture Framework

2.2.3 Business Architecture

The business architecture domain focuses on creating a comprehensive description of
the organization, covering all business aspects, including capabilities, processes, data,
and organizational structure. It facilitates business-led discussions with stakeholders
and aids in making decisions based on agreed-upon business terms. This domain
enables clear communication of business values and the impact of architecture work,
ensuring that all stakeholders are on the same page.
Let’s walk through the key components of the business architecture domain.

Business Capability Map

An organization’s business capabilities constitute its ability to effectively execute its
business activities, accomplish its business aims, and provide value to its stakeholders.
A capability represents a distinct skill or capacity that a business might possess or
leverage to attain a particular objective or result. Business capabilities lie at the heart of
business architecture as they articulate what the business accomplishes and not how
it’s accomplished. These capabilities can encompass existing functions or those
needed to support a novel direction or strategy. The idea of business capability has
evolved into a key element in crafting business architecture. With numerous organiza-
tions grappling with the complexity of their operations, they seek to address queries
about their advancement toward achieving strategic objectives. Business capabilities
offer a simplified representation of the business landscape, facilitating discussions
among stakeholders and furnishing a practical framework for both business and IT
endeavors.
Business capabilities are best represented in a business capability map like in Figure 2.11.

Figure 2.11 Example of Business Capability Map with Attribute Fulfillment and Priority

58 58
 2 The
2.2 SAP Enterprise
Enterprise Architecture
Architecture Framework
Methodology

The main steps involved in creating a business capability map are as follows:
1. Identify business functions
2
Begin by identifying the primary functions or activities within your organization.
These could include sales, marketing, customer service, product development, etc.
2. Break down functions into capabilities
Break down each business function into discrete capabilities. These are specific abil-
ities or capacities that the business must possess to perform the function effectively.
For example, under the “sales” function, capabilities might include lead generation,
prospecting, negotiation, etc.
3. Maintain attributes and assess capabilities
Adding attributes to business capabilities can provide additional context and infor-
mation, enhancing the understanding of each capability. Evaluate each business
capability to assess its current state and performance. Potential attributes could be
description, strategic importance, maturity level, requirements, stakeholder, organi-
zational or business unit, etc.
4. Iterate and maintain
Business capabilities evolve over time, so it’s important to regularly review and
update the diagram to reflect changes in the organization’s strategy, structure, and
operations. Continuously iterate on the diagram to keep it relevant and useful for
decision-making.

Utilizing reference content is crucial when developing a business capability diagram as

it provides valuable insights and guidance based on established industry standards and
best practices. Drawing from reference content allows organizations to leverage the
collective knowledge and expertise of their industry peers, ensuring that their business
capability diagram reflects relevant and proven approaches to structuring and organiz-
ing business functions. SAP offers a wealth of reference business capability models tai-
lored to specific industries. These models serve as invaluable resources, offering
predefined frameworks and templates that align with industry-specific requirements
and nuances. Refer to Section 2.3 to learn more about SAP’s reference content.

Business Process Catalog

A business process catalog is a comprehensive repository that documents all business
processes within an organization. It serves as an organized inventory of the various pro-
cesses that are critical to the functioning of the enterprise. This catalog includes detailed
descriptions, objectives, inputs, outputs, key stakeholders, and any interdependencies
between processes. Essentially, it provides a high-level view of how different business
activities are structured and interconnected, offering a clear understanding of the oper-
ational landscape of the organization.

59
2 2 The SAP Enterprise Architecture Framework
The SAP Enterprise Architecture Framework

The business process catalog is crucial to enterprise architecture because it provides or

aids in the following:
 Holistic view
It provides a complete overview of the organization’s business processes, facilitating
a better understanding of how different functions and activities are interrelated.
 Alignment
It ensures that business processes are aligned with the organization’s strategic goals
and objectives. This alignment is essential for achieving organizational coherence
and effectiveness.
 Decision making
It aids in informed decision-making by providing a clear picture of existing pro-
cesses, which helps in identifying areas for improvement, optimization, and innova-
tion.
 Integration
It supports integration efforts by highlighting interdependencies and interfaces
between processes, ensuring smooth collaboration among various departments.

The business process catalog typically takes the form of a structured document. It may
include the elements shown in Table 2.1.

Business Catalog Element Business Catalog Description

Process ID A unique identifier for each process

Process name The name of the process

Description A brief overview of the process

Objectives The goals and intended outcomes of the process

Inputs The resources, data, and prerequisites required to execute the

process

Outputs The deliverables or results produced by the process

Organizational unit Organizational or business units

Process owner Key business processes where the owner is responsible

Stakeholders Key individuals or groups involved in or affected by the process

Interdependencies Relationships and dependencies with other processes

Performance metrics Key process performance indicators (PPIs) and metrics used to
measure the effectiveness and efficiency of the process

Table 2.1 Example of Business Process Catalog

60 60
 2 The
2.2 SAP Enterprise
Enterprise Architecture
Architecture Framework
Methodology

Level of Business Processes

Business processes are often organized into five levels of depth to provide a clear and 2
structured approach:
1. Business area
Represents the broadest categories, aligning with the main functions of the organi-
zation
2. Process group
Groups related processes within a business area
3. Business process
Defines specific processes that achieve certain business objectives
4. Process variants
Defines variations on the same process, based on different conditions or data
inputs
5. Process steps
Provides the most detail, outlining individual tasks or activities within a process

Developing a business process catalog involves several key steps:

1. Identify processes
Conduct workshops and interviews with stakeholders to identify all significant busi-
ness processes within the organization on level 1 to level 3.
2. Document processes
Capture key information about each process, including descriptions, objectives,
inputs, outputs, stakeholders, and interdependencies.
3. Standardize information
Ensure that the documentation follows a consistent format and standard nomencla-
ture for easy understanding and comparison.
4. Validate information
Engage with process owners and stakeholders to review and validate the docu-
mented processes for accuracy and completeness.
5. Categorize and organize
Group processes into logical categories and hierarchies to create a structured and
easily navigable catalog.
6. Implement tool
Choose an appropriate tool or platform to store and manage the catalog, ensuring
it’s accessible and user-friendly.

Be aware that in enterprise architecture, the business process catalog provides a

higher-level view of processes compared to solution blueprints. The catalog offers an
overview of all business processes, concentrating on levels 1 to 3, rather than detailed

61
61
2 2 The SAP Enterprise Architecture Framework
The SAP Enterprise Architecture Framework

process descriptions. This higher-level focus, developed during the planning and analy-
sis phases, aids strategic decision-making and ensures alignment with organizational
goals. In contrast, solution blueprints provide detailed technical designs during the
implementation phase, concentrating on how specific processes will be executed
within a particular system. Thus, while the catalog serves as a foundational tool for
understanding and optimizing business operations, the detailed process descriptions
are part of the actual solutioning phase, when solutions are built and implemented.

Business Value Flow Diagram

A business value flow diagram is integral to SAP Enterprise Architecture Methodology
(SAP EA Methodology). It depicts the integration of value-adding business activities
aimed at achieving specific goals and delivering valuable outcomes. These flows are
pivotal for enterprise architecture planning, offering insights into how value is gener-
ated and delivered across the organization. By mapping these activities, stakeholders
identify opportunities for improvement, innovation, and strategic alignment. The dia-
gram provides visibility into the current and desired future state of the organization,
ensuring alignment between business and IT priorities. Ultimately, understanding
business value flows empowers organizations to enhance their efficiency, agility, and
competitiveness.
Business processes and business value flows and serve distinct yet interconnected pur-
poses within an organization. Business processes, represented in Business Process
Model and Notation (BPMN), detail the sequential steps and activities required to
accomplish a specific task or achieve a particular outcome. They provide a granular
view of the operational workflow, highlighting the sequence, interactions, and decision
points involved in executing a process. On the other hand, business value flows focus
on the flow of value-adding activities aimed at achieving strategic business objectives
and delivering value to stakeholders. While business processes focus on operational
efficiency and effectiveness, business value flows provide a higher-level perspective,
emphasizing the alignment of activities with overarching business goals and priorities.
In essence, business processes offer a detailed blueprint of operational activities, while
business value flows offer a strategic roadmap for value creation and delivery within
the organization.

Business Process Model and Notation

BPMN is a standardized graphical representation of specific business processes. It pro-
vides a set of symbols and notations that are used to create detailed process maps. Key
elements of BPMN include the following:
 Flow objects
These are the core elements―such as events (circles), activities (rectangles), and
gateways (diamonds)―that define the actions and decisions in the process.

62 62
 2 The
2.2 SAP Enterprise
Enterprise Architecture
Architecture Framework
Methodology

 Connecting objects
These are arrows that connect flow objects, showing the sequence and direction of 2
the process flow.
 Swimlanes
These divide the diagram into lanes or pools to represent different participants or
departments involved in the process.
 Artifacts
These constitute additional information, such as data objects or annotations, that
provide more context to the process.

To illustrate a business value flow, we can examine Figure 2.12, which presents a busi-
ness value flow extracted from SAP’s reference content (see Section 2.3 for more details).

Figure 2.12 Example of Value Flow for Operate-to-Maintain Process Mapped with Business
Capabilities

Usually, you can create the business value flow diagram by performing the following
steps:
1. Identify end-to-end business value flows
Begin by identifying the high-level, end-to-end business value flows that encompass
the organization’s primary objectives or goals. These level 1 business value flows
provide a top-down perspective on how value is created and delivered within the
organization.

63
 2 2 The SAP Enterprise Architecture Framework
The SAP Enterprise Architecture Framework

2. Identify industry-specific variants

Determine whether there are any industry-specific variations or nuances that need
to be considered for each business value flow. This step involves identifying how
industry-specific factors may impact the execution of business activities and the
overall flow of value within the organization.
3. Explore further levels of business value flows
Delve deeper into each level 1 business value flow to identify and define more
detailed levels of value flow, down to level 4. These lower levels break down the level
1 flows into specific business activities, providing a more granular understanding of
the value creation process.
4. Map business capabilities to business activities
Identify the business capabilities that are associated with each business activity.
This helps you to understand which capabilities are necessary for the organization
to execute each activity and how they contribute to value creation within the orga-
nization.
5. Review and iterate
Once you have created the initial diagram, review it with stakeholders to ensure its
accuracy and completeness. Make adjustments as necessary based on feedback and
further analysis.

Organization Map
An organization map is a comprehensive representation of the various entities that
make up an organization. It details the hierarchical arrangement of and relationships
among different components such as groups, business units, regions, countries, sales
organizations, and production sites. This map provides a clear understanding of how
the organization is structured, showing the distribution and coordination of roles,
responsibilities, and operations among different levels and areas (see Figure 2.13).

Group

Business Unit 1 Business Unit 2 Business Unit 3 Business Unit 4

EMEA APJ LA EMEA EMEA NA

South Africa
Germany

England

Mexico

France
China

Brazil
India

Italy

USA

Figure 2.13 Organization Map

64 64
 2 The
2.2 SAP Enterprise
Enterprise Architecture
Architecture Framework
Methodology

The organization map is a crucial artifact in enterprise architecture because it provides

an overview of the organizational structure, serving as a foundational framework for
structuring business processes and capabilities. It ensures alignment between the 2
enterprise architecture and the organizational hierarchy, supporting strategic goals
and operational needs. Additionally, the map aids in understanding business needs by
clearly defining roles and responsibilities among various entities, thus facilitating
effective planning and resource management. In summary, the organization map
helps you navigate through the enterprise architecture of the organization.
Developing an organization map involves several key steps:
1. Identify key entities
Determine the main groups, business units, regions, countries, sales organizations,
and production sites within the organization.
2. Document relationships
Map out the relationships and reporting lines between different entities.
3. Create the visual representation
Use diagramming tools to create a visual representation of the organizational struc-
ture.
4. Validate with stakeholders
Review the draft map with stakeholders to ensure its accuracy and completeness.

Business Data Catalog

A business data catalog serves as a comprehensive repository of metadata, encompass-
ing various dimensions of an enterprise’s information assets. It houses definitions of
data objects and fields, alongside crucial business system attributes, such as business
rules, process relevance, data activities, and access controls. This catalog offers a clear
and up-to-date depiction of data reality from both business and IT perspectives, foster-
ing collaboration and facilitating impact analysis for new data requirements. Crucially,
it aids in understanding the creation, storage, transmission, and reporting of enter-
prise data entities, thus contributing to enterprise architecture planning. By providing
a holistic view of the entire organizational landscape, the catalog transcends specific
business functions, enabling its utilization in diverse business operations.
The business data catalog can encompass diverse attributes such as the following:
 Data object and field definitions
 Business rules and process relevance
 Data activities such as data quality management
 People and organizations involved in data management
 Locations of data, including master and secondary systems
 Access controls and security limitations

65
2 2 The SAP Enterprise Architecture Framework
The SAP Enterprise Architecture Framework

 Compliance requirements and regulations

 Timing and events related to data processing
 Components of the data lifecycle (creation, maintenance, and deletion)

For instance, we can consider Table 2.2, which offers just a glimpse of the entire busi-
ness data catalog.

Data Object Data Type Business Definition Process Data Owner

Relevance

Sales order Transactional An order placed by a Order-to- Sales manager

data customer for a prod- cash
uct

Material Master data A unique identifier Plan-to- Inventory

for a product in produce manager
inventory

Customer Master data The name of the cus- Lead-to-order Customer ser-
tomer placing an vice manager
order

Order quantity Transactional The quantity of a Lead-to-order Production

data product ordered by a manager
customer

Delivery date Transactional The scheduled date Lead-to-order Logistics

data for delivering the manager
order

Payment status Transactional An indication of Order-to- Finance

data whether payment for cash manager
the order is received

Table 2.2 Example of a Business Data Catalog

The key steps for creating a business data catalog involve two main phases―catalog
definition and catalog delivery:
1. Catalog definition
– Engage in discussions with data architecture stakeholders to gather require-
ments.
– Agree on the structure and level of detail for the initial version.
– Define usage scenarios for the metadata catalog.
– Establish a roadmap for content delivery and evolution.
2. Catalog delivery
– Name priority-1 data objects along with their business and IT attributes.

66 66
 2 The
2.2 SAP Enterprise
Enterprise Architecture
Architecture Framework
Methodology

– Begin populating the catalog with content based on the identified priorities.
– Expand the baseline version to encompass all data objects.
2
– Include data objects with specifically identified priority-1 business and IT attri-
butes.
– Incorporate nonpriority objects to complete the overall version.
– Ensure all data objects and attributes are captured in the metadata catalog.

Business Role Diagram

A business role diagram is a detailed representation of the various roles within an orga-
nization and their relationships to business activities and processes. This artifact out-
lines the responsibilities, duties, and authorities of different roles, providing a clear
understanding of who is involved in what activities within the enterprise. It typically
includes roles such as executives, managers, specialists, and other key positions, and it
maps these roles to specific business functions and activities.
The business role diagram typically includes the following elements:
 Roles
Definitions of various roles such as executives, managers, specialists, administra-
tors, and clerks
 Responsibilities and duties
A description of the responsibilities and duties associated with each role
 Relationships to business activities
Mapping of roles to specific business activities and processes
 Attributes
Seniority level, required skills, and other role-specific characteristics

Business roles are intricately related to other entities within the organizational and
process frameworks. They are directly connected to business activities, indicating who
is responsible or accountable for each activity, as defined in the extended RACI model
(RACI meaning responsible, accountable, consulted, and informed). Additionally, busi-
ness roles have relationships with other roles, often forming hierarchical structures
where roles like learning manager report to roles such as chief learning officer. Busi-
ness roles also interact with application roles, requiring specific software access to per-
form their duties. They are linked to business capabilities, which define the skills and
resources needed to carry out business activities. Moreover, business roles can be asso-
ciated with job roles and personas, providing a detailed breakdown of responsibilities
within the organization and aligning roles with specific personal profiles or job posi-
tions. These relationships ensure that business roles serve as a bridge between organi-
zational structure, business processes, and individual responsibilities, creating a cohe-
sive and comprehensive framework for enterprise architecture.

67
 2 2 The SAP Enterprise Architecture Framework
The SAP Enterprise Architecture Framework

Business Footprint Diagram

A business footprint diagram is a graphical representation that illustrates the various
components, relationships, and interactions within an organization’s business envi-
ronment. It typically includes elements such as business goals, organizational units,
business functions, applications, and technical components. This diagram serves as a
comprehensive map, providing clarity on the structure and functioning of the enter-
prise. Understanding the business footprint is crucial for effective enterprise archi-
tecture planning as it enables stakeholders to visualize the current state of the
organization, identify areas for improvement, and devise strategies for alignment
with business goals. By mapping out the business footprint as in Figure 2.14, organi-
zations can make informed decisions regarding resource allocation, technology
investments, and process optimization, ultimately enhancing their operational effi-
ciency and driving business success.

Increasing
Improving Customer Expanding Market
Goals Operational
Satisfaction Reach Efficiency

Unit Sales Finance

Omnichannel
Function Lead Generation Sales Campaigns Order Management
Engagement

Application SAP Sales Cloud SAP S/4HANA

Technology SAP Business

SAP HANA
Technology Platform

Figure 2.14 Example of Business Footprint Diagram

You can create a business footprint diagram by performing the following steps:
1. Gather requirements
Understand the business goals, organizational structure, and key functions of the
company. Identify stakeholders and gather input on their needs and requirements.

68 68
 2 The
2.2 SAP Enterprise
Enterprise Architecture
Architecture Framework
Methodology

2. Define components
List the organizational units, business functions, services, and technical compo-
nents relevant to the business. This may involve conducting interviews and work- 2
shops or reviewing existing documentation.
3. Establish relationships
Determine the links between business goals, organizational units, business func-
tions, and services. Map out how these functions rely on each other to achieve the
company’s objectives.
4. Map technical components
Identify the technical components (e.g., software applications, hardware infrastruc-
ture) that support the business functions. Connect these components to their corre-
sponding services and functions.
5. Create visualization
Use a diagramming tool or software to visually represent the relationships and con-
nections you’ve identified in the previous steps. Arrange the components in a logi-
cal layout that is easy to understand and annotate the diagram as needed to provide
clarity.

2.2.4 Solution Architecture

The solution architecture domain covers reference, base, target, and transition archi-
tectures, focusing on capabilities, processes, data, and organizational structure. Its pri-
mary value lies in aligning technology solutions with business goals and requirements.
Acting as a bridge between the business and technical sides of an organization, it
ensures that technology solutions are designed and implemented in a way that meets
business needs, providing a cohesive approach to integrating technology with business
operations.
We’ll review the key components of solution architecture in the following sections.

Product Map
A product map describes the functional ability of a single or multiple solution compo-
nents to implement and support a specific business capability. The product map cap-
tures solution capabilities structured by business domains, business areas, and
possibly business capabilities or solution components for reference purposes. Figure
2.15 shows an example of a product map for asset management. Benefits of a product
map include the following:
 It lists relevant solution capabilities structured by business needs.
 It helps to identify relevant solution components and the role they can play in fulfill-
ing the business scope.
 It supports the comparison and value proposition of solution components.

69
2 2 The SAP Enterprise Architecture Framework
The SAP Enterprise Architecture Framework

Figure 2.15 Example of Product Map for Asset Management

Creating a product map involves a structured approach to aligning business needs with
technical solutions. Initially, you identify the business scope by structuring the prod-
uct map into relevant business domains and business areas, possibly further refined by
relevant business capabilities at a granular level 3. Once you identify the business
scope, you assign supporting solution capabilities to address the identified business
areas or business capabilities, thus potentially offering multiple alternative solutions
for flexibility. Subsequently, for each solution capability, you should list the required
and optional solution components, clearly describing the components that are neces-
sary to fulfill the capability and those that offer additional features or enhancements.
Using this structured methodology ensures that the product map effectively captures
the alignment between business requirements and technical solutions and thus facili-
tates informed decision-making and solution design processes.
You can depict product maps in different layouts and different heat mapping, depend-
ing on the context in which the product map will be used. For example, in the context
of application rationalization, you can establish a product map on the tolerate, invest,
migrate, or eliminate (TIME) methodology or the rehost, replatform, repurchase, refac-
tor, retire, and retain (6R) methodology. When using SAP LeanIX, this comes out of the
box, and you can immediately apply it to visualize the product map. (For additional
details on SAP LeanIX, see Part III.)

Solution Component Diagram

A solution component diagram serves as a graphical representation of the essential
solution components mandated for a specific solution variant. It accurately outlines
the deployment possibilities of these components and explains the complex integra-
tion points among them, referencing corresponding implementation artifacts like
application programming interfaces (APIs) and integration flows. Its significance lies in

70 70
 2 The
2.2 SAP Enterprise
Enterprise Architecture
Architecture Framework
Methodology

its capacity to clarify the collection of solution components for addressing a given busi-
ness scenario, thus providing stakeholders with a comprehensive understanding of the
solution’s architecture. Additionally, the diagram outlines the necessary integration 2
channels among these solution components, offering insights into their interdepen-
dencies and interactions that are critical for seamless operation. Moreover, it aids in
the identification of crucial implementation artifacts such as APIs, communication
scenarios, and recommended middleware content, thus empowering organizations to
streamline their implementation processes and ensure optimal performance.
Solution components are modular, software-based units that are essential for con-
structing an entire solution and are tailored to fulfill specific business needs. These
components, which can manifest as configured applications or services, are designed
to perform distinct functions within the solution architecture. They can be further cat-
egorized into more granular components or grouped into coarser-grained units to
describe the overall structure of the solution. For instance, in Figure 2.16, there are eight
top-level solution components (such as SAP SuccessFactors HXM Suite and SAP Master
Data Integration), and each represents a distinct functional aspect of the solution.
Moreover, these solution components may be hierarchically organized, with higher-
level components (like SAP SuccessFactors HXM Suite) encapsulating finer-grained
components like SAP SuccessFactors Employee Central Payroll. Additionally, deploy-
ment units are demarcated by a cloud icon, distinguishing them from other solution
components within the architecture. Overall, solution components serve as the build-
ing blocks of a solution, delineating its structure and functionality in a modular and
scalable manner.

Figure 2.16 Example of Solution Component Diagram for Solution Process Hire-to-Retire
(Refer to https://api.sap.com/)

71
71
2 2 The SAP Enterprise Architecture Framework
The SAP Enterprise Architecture Framework

Creating a solution component diagram involves a methodical process comprising

several key steps:
1. Outline the solution variant
Get clear about the business scenario (e.g., the business process variant). The solu-
tion will address and determine the name of the solution variant.
2. Identify and structure solution components
Identify the solution components required to address the scope of the solution vari-
ant as well as relevant external components and understand the role they play
within the solution variant. Then, group or detail the solution components to trans-
fer required details in a clearly arranged manner.
3. Introduce communication channels
Introduce schematic communication flows between the solution components.
Note that the communication channels between solution components must be
integrated with each other.
4. Consider details
Take the details (e.g., associated communication scenarios, APIs, message flows) into
account as required.

Solution Value Flow Diagram

A value flow is a sequence of activities and interactions that deliver value to stakehold-
ers. It differs from a business process, which is typically depicted in a BPMN diagram
that details specific steps and tasks. Value flows can be nested in several hierarchies,
but on the lowest level, the main entity is the business activity that is the main step of
the value flow. In addition, each business activity can be mapped to corresponding
business capabilities. Refer to Section 2.3.1 for additional details.
The artifact known as a solution value flow encapsulates an abstract representation of a
solution process, showcasing a collection of business activities aimed at generating addi-
tional value for stakeholders. These addressed business activities are linked with relevant
solution components and solution capabilities that are responsible for their implemen-
tation. Typically depicted through solution value flow diagrams, these visualizations
offer insights into how value is created and propagated throughout the solution architec-
ture. Additionally, these diagrams may incorporate the display of associated solution
components and solution capabilities, providing a comprehensive view of the underly-
ing mechanisms driving value creation within the enterprise architecture. Overall, solu-
tion value flows serve as invaluable tools for understanding and optimizing the flow of
value across business processes and technical solutions.
Figure 2.17 illustrates an example of a solution value flow diagram for the Market prod-
ucts and services (generic) business segment. Within this diagram, specific business
activities such as Execute promotional activities or Perform customer profiling are
correlated with corresponding solution capabilities like Digital Asset Management or

72 72
 2 The
2.2 SAP Enterprise
Enterprise Architecture
Architecture Framework
Methodology

Customer Profile Management, and they are also associated with solution components
such as SAP Customer Data Cloud.
2

Figure 2.17 Example of Solution Value Flow Diagram

Creating a solution value flow artifact follows a structured process to elucidate value-
adding processes within the solution architecture:
1. Specify business activities
Depict all addressed value-adding business activities in a logical order that is condu-
cive to easy explanation of the solution process. Note that the actual execution
sequence may differ from the depicted order.
2. Identify solution capabilities and solution components
Assign business activities to relevant solution capabilities and solution components
that are responsible for realizing them.

Solution Process Flow Diagram

The solution process flow diagram provides a comprehensive depiction of the solution
process, illustrating its sequential execution and interactions within an ecosystem.
Functioning as a behavioral diagram, it articulates the solution process through a tan-
gible flow. Leveraging the framework of BPMN 2.0 collaboration or process diagrams, it
incorporates SAP EA Methodology extensions to delineate integration architecture
nuances. Within this framework, the rectangular areas (which we call pools) symbolize
deployment units and encapsulate solution components, while message flows eluci-
date the collaboration and integration dynamics among these units. Lanes, on the
other hand, serve to delineate subsolution components or application roles, offering a
granular view of the process landscape. Through this structured representation, the
solution process flow diagram serves as a vital tool for comprehending, analyzing, and

73
73
 2 2 The SAP Enterprise Architecture Framework
The SAP Enterprise Architecture Framework

optimizing complex solution architectures. Figure 2.18 depicts an example of a solu-

tion process flow diagram for performing quality inspections.
Production Engineer

Display Routing
SAP S/4HANA Cloud Public Edition

for Inspection
Characteristics
Inspection Results from
SAP Digital Manufacturing
Quality Technician

Record Qualitative Update Inspection

Create Display Open Complete
and Quantitative Results in
Inspection Lot Inspection Lot Inspection
Production Order Inspection Results Inspection Lot
Released

Figure 2.18 Example of Solution Process Flow Diagram for Performing Quality Inspection
Process

Creating a solution process flow diagram involves several key activities aimed at cap-
turing the essence of the solution process and its components. Here are the main activ-
ities:
1. Specify flow of solution activities
Depict all relevant solution activities, each of which represents one or a part of one
or multiple business activities and the ordering constraints between them. Define
the flow of solution activities, including parallel and optional process flow paths.
2. Identify solution components
Assign solution activities to solution components, realizing them in the context of
the given solution process flow. You can assign a given solution activity to exactly
one solution component, which is represented as a pool in the diagram.
3. Specify integration
Define how integration of relevant solution components is realized in the context of
the given solution process flow. Use message flows to depict different integration
points between any two solution components.

Solution Data Flow Diagram

The solution data flow diagram serves as a visual representation of the data flow within
a particular solution, revealing the exchange of information among solution compo-
nents. At its core, the diagram illustrates the interconnectedness of solution compo-
nents and their associated solution data objects, showcasing how data travels through

74 74
 2 The
2.2 SAP Enterprise
Enterprise Architecture
Architecture Framework
Methodology

the system. Through the depiction of data flows, it highlights the journey of data origi-
nating from the system of records and its propagation among various solution compo-
nents. By providing a structured view of data movement, the solution data flow 2
diagram aids in your understanding of the data exchange dynamics within the solu-
tion architecture, thus facilitating effective analysis and optimization of data flow pro-
cesses. Figure 2.19 illustrates a sample solution data flow diagram for the hire-to-retire
process within a cloud deployment scenario.

Figure 2.19 Example of Solution Data Flow Diagram for Hire-to-Retire Process
(Refer to https://api.sap.com/)

Creating a solution data flow diagram involves a series of systematic steps aimed at
capturing the intricacies of data flow within the solution architecture. Here are the
main steps:
1. Identify solution data objects
Specify all solution data objects within the relevant solution components, empha-
sizing their relevance to integration processes. These objects serve as specific reali-
zations of business objects, representing parts or combinations of business objects
tailored to the solution components.
2. Specify data structure
Define the structure of the identified solution data objects, particularly focusing on

75
75
2 2 The SAP Enterprise Architecture Framework
The SAP Enterprise Architecture Framework

their attributes and relationships. In the context of SAP, the structure is typically
outlined by SAP One Domain Model, which provides a standardized framework for
data representation.
3. Specify data flows
Establish dependencies between identified solution data objects by defining the
flow of data among relevant solution components. Data flows are the pathways by
which data moves among solution data objects situated in different solution com-
ponents. Each endpoint of a data flow signifies a solution data object, indicating the
direction of data transmission from the sending object to the receiving object.

SAP One Domain Model

SAP One Domain Model is a standardized data model that ensures consistent data inte-
gration across various SAP applications. It aims to eliminate data silos by providing a
unified view of business data, facilitating seamless integration and interoperability.
SAP One Domain Model serves as a common language that enables different SAP solu-
tions to communicate effectively, ensuring that data remains consistent, accurate, and
accessible across the enterprise. This model is crucial for businesses looking to harmo-
nize their data landscape and drive digital transformation.

Software Distribution Diagram

The software distribution diagram provides a high-level overview of how individual
solution components or building blocks are structured and distributed across the IT
infrastructure and underlying technology foundation. Its level of detail is contingent
upon the granularity of the solution components under consideration. Typically,
the diagram categorizes environments into on-premise data centers, private clouds
(designated private areas within an IT partner’s data center), and public clouds (services
hosted in public hyperscaler data centers). This visualization aids in understanding the
potential impact, risks, and connectivity challenges associated with the selected solu-
tion components during the application and data architecture phase. While the dia-
gram primarily focuses on these aspects, additional details pertaining to the physical
locations of data centers, their connectivity (such as virtual private or interconnec-
tions), and specifics regarding the operational software layer (e.g., virtualization, con-
tainer technology) are addressed within the technology architecture domain (Section
2.2.5).
Creating a software distribution diagram like the one in Figure 2.20 involves several
systematic steps aimed at illustrating the distribution of solution components among
various deployment models and environments.

76 76
 2 The
2.2 SAP Enterprise
Enterprise Architecture
Architecture Framework
Methodology

<Cloud Provider> <Data Center> <Shopfloor>

<Architecture Building Block> <Solution Building Block> 2

<Solution Building Block> <Solution Building Block>

<Solution Building Block> <Solution Building Block>

<Solution Building Block>

<Solution Building Block>

Figure 2.20 Template for Software Distribution Diagram

Here are the typical steps:

1. Identify solution components and deployment models
Begin by identifying the key building blocks of the solution variant. This entails
understanding the specific deployment types or deployment models involved. Uti-
lize content from the related solution component diagram, if available, to inform
this process.
2. Depict relationships among the identified solution components
Visualize the communication relationships among the solution components within
the diagram. This step is crucial for understanding potential latency considerations
or network requirements associated with the solution architecture.
3. Identify hosting and deployment environments as well as infrastructure providers
Map the identified solution components to their respective hosting and deploy-
ment environments, taking into account the infrastructure providers involved. This
step helps to establish a clear understanding of where each component resides
within the overall IT infrastructure landscape.

Application Architecture Overview Diagram

The application architecture overview diagram serves as a comprehensive visualiza-
tion of the solution components and their interconnections within an enterprise
architecture. It encapsulates both SAP and third-party solution components, offering
a holistic perspective on the architecture landscape. Unlike the formalized structure
of solution component diagrams, this overview diagram presents a more illustrative
and accessible representation, making it easier to grasp the architecture’s essence at a
glance. While it potentially encompasses a broader scope than the solution compo-
nent diagram suggested by SAP Reference Solution Architecture, it must align with
and complement the architecture description outlined in the corresponding solution
component diagram. The application architecture overview diagram thus plays a

77
77
 2 2 The SAP Enterprise Architecture Framework
The SAP Enterprise Architecture Framework

crucial role in providing stakeholders with a clear, cohesive understanding of the

enterprise architecture’s composition and relationships.
Figure 2.21 is an application architecture overview diagram example showing different
solutions like SAP Ariba, SAP Business Technology Platform (SAP BTP), and SAP
S/4HANA, including their components like product compliance (in SAP S/4HANA) and
SAP Ariba Sourcing (as part of SAP Ariba).

Non-SAP21 1
Non-SAP111 1
SAP BTP Non-SAP

Microsoft Excel
SAP Responsible
Design and
Production

SAP BTP

SAP S/4HANA

EHS
Product Environment SAP Sustainability
Compliance Management Control Tower

SAP Ariba

SAP Datasphere
SAP Ariba
Sourcing
SAP BTP

SAP Ariba SAP Analytics

SAP Sustainability Cloud
Supplier Lifecycle Footprint
and Performance Management

SAP Ariba Together

EcoVadis Supplier Risk for
Sustainability
(TfS)

Figure 2.21 Example of Application Architecture Overview Diagram with Focus on

Sustainability

Creating an architecture overview diagram involves a structured approach that begins

with the identification and organization of solution building blocks. This process may
utilize existing artifacts, such as a solution concept diagram if available, to define the
key components of the solution variant. Additionally, you can highlight areas lacking
SAP solution components (which we call white spots) to indicate potential gaps in the
architecture. To enhance clarity, you can employ icons and color-coding to distinguish
between SAP and non-SAP components. It is therefore essential that you understand
the dependencies between these components. Leveraging SAP reference architecture
facilitates this task by mapping out the required solution components. By compre-
hending these dependencies, such as application interfaces, the diagram effectively
captures the intricate relationships and dependencies within the architecture, provid-
ing stakeholders with invaluable insights into the system’s structure and functionality.

78 78
 2 The
2.2 SAP Enterprise
Enterprise Architecture
Architecture Framework
Methodology

Conceptional Data Diagram

A conceptual data diagram is a visual representation that outlines the data entities
2
involved in a solution building block and the relationships among them. This artifact is
fundamental for understanding the data architecture of an enterprise because it illus-
trates how different data entities are structured and interconnected. It provides a high-
level view of the key data elements and their associations, serving as a blueprint for
data management and integration within the organization.
Developing a conceptual data diagram like the one in Figure 2.22 involves the following
key steps:
1. Identify relevant data entities
Explore the business process and activities to identify the primary data entities
involved.
2. Define attributes
For each data entity, identify and name key attributes with appropriate data types.
3. Establish relationships
Identify the relationships between data entities, such as one-to-one, one-to-many,
or many-to-many, and represent them graphically.
4. Create the visual representation
Use diagramming tools to create a visual representation of the entities and their
relationships.

Entity 1 (<Noun>) Entity 2 (<Noun>)

Property 1: DataType 1 <Verb> n Property 1: DataType

Property 2: DataType

0..n
Entity 3 (<Noun>)

Property 1: DataType 1 <Verb>

Properts 2: DataType
Property 3: DataType

Figure 2.22 Conceptual Data Diagram

This artifact is also related to several other key artifacts. It supports the business value
flow by detailing the necessary data for process execution and aligning data dependen-
cies with value streams. It complements the organization map by defining role-based
data access and stewardship, ensuring data security and governance. Additionally, it
connects with other enterprise architecture artifacts like the business process catalog,

79
2 2 The SAP Enterprise Architecture Framework
The SAP Enterprise Architecture Framework

business role diagram, solution value and process flows, and business capability mod-
els, thus ensuring that data architecture aligns with business architecture and organi-
zational structure.

2.2.5 Technology Architecture

This domain is concerned with documenting how the target solution architecture
building blocks are delivered through various technology components, such as operat-
ing systems, virtualized environments, hardware, and networks. It provides a detailed
depiction of the deployment of the organization’s IT systems in specific data center
locations, ensuring that the technological infrastructure supports the overall architec-
ture effectively.
There’s one key diagram available for technology architecture, and we’ll discuss it in
this section.

Environment and Location Diagram

The environment and location diagram serves as a comprehensive visual representation
of the deployment and operation of solution building blocks in various data center loca-
tions. It defines the required physical connections between these blocks, explaining the
infrastructure supporting them. Moreover, it factors in the geographic distribution of
users and external systems that are essential for interacting with the solution compo-
nents. This integrated perspective extends to delineating data exchange pathways over
public lines and identifying areas necessitating VPN security enhancements. By encap-
sulating these elements, the diagram provides a holistic view that is vital for orchestrat-
ing a robust and secure architectural framework. Figure 2.23 shows a template that you
can use in the SAP context for an environment and location diagram.
Creating the environment and location diagram involves the following steps:
1. Begin with the previously created software distribution diagram and advance it into
the environment and location diagram.
2. Identify the deployment environments where your building blocks are operational,
then enhance the landing zones of the software distribution diagram by explicitly
specifying data center providers, data center locations, and infrastructure details for
each landing zone.
3. Align the solution building blocks, as outlined in the solution realization diagram,
with the corresponding deployment environments.
4. Visualize the relationships, such as request-response or information flow, among
the building blocks. This visualization aids in your understanding of network
requirements.

80 80
 2 The
2.2 SAP Enterprise
Enterprise Architecture
Architecture Framework
Methodology

<Cloud Provider Data Center – Location> Public <Data Center – Location>

Internet 2

<Architecture Building Block> <Solution Building Block>

<Solution Building Block>

<Solution Building Block>

<Solution Building Block> <Office Locations>

<City 1> <City 2>

<Cloud Provider Data Center – Location>

<Solution Building Block>

Figure 2.23 Template for Environment and Location Diagram

2.2.6 Roadmap and Transition

The roadmap and transition domain focuses on identifying and planning required ini-
tiatives and managing the transition of systems or processes. It involves pinpointing
potential advantages, planning migrations, and executing changes to achieve the proj-
ect’s objectives efficiently. This domain ensures that transitions are smooth and that
the organization can adapt to new systems or processes without significant disrup-
tions.
We’ll walk through the key components of the roadmap and transition domain in the
following sections.

Architecture Roadmap
The architecture roadmap in enterprise architecture encompasses two primary arti-
facts that serve distinct yet interrelated purposes:
 The business architecture roadmap offers a visual depiction of business objectives
over varying timeframes and functional groupings. It provides stakeholders with a
clear understanding of the anticipated business outcomes and how they align with
strategic goals.
 The application architecture roadmap delineates the deployment sequence of indi-
vidual solution building blocks relative to business lines or value drivers on a speci-
fied timeline. It guides the implementation journey by outlining the order of steps
needed to transition from a baseline architecture to a desired target architecture.

These roadmaps work in tandem, offering complementary perspectives and facilitat-

ing a cohesive approach to architectural planning and execution within the enterprise.

81
81
 2 2 The SAP Enterprise Architecture Framework
The SAP Enterprise Architecture Framework

Creating a comprehensive architecture roadmap involves considering several influ-

encing factors spanning various dimensions of the organization. These factors include
the following:
 Delivery scope, which encompasses the extent and boundaries of the project’s deliv-
ery, as well as the specific business segments, geographical entities, and lines of busi-
ness (LoBs) affected
 Business architecture, which entails mapping out the business operating model,
strategy, pain points, and prioritization of capabilities based on value and change
drivers
 Application architecture considerations, which involve detailing the as-is and to-be
architecture, aligning with SAP product strategies, defining deployment options,
sequencing implementations, ensuring user experience (UX) and data governance,
and integrating intelligent capabilities
 Technical architecture considerations, which span platform strategies, sizing, intelli-
gent technologies, and hyperscaler strategies
 Transformation programs, all within the context of boundary conditions, ongoing
initiatives, and timelines

The first step in crafting an architecture roadmap typically involves assembling an ini-
tiatives catalog like the one in Figure 2.24. This entails creating a list of initiatives de-
rived from the target architecture. Moreover, where feasible, it’s advantageous to con-
nect these initiatives with customer goals to establish an initiative/goals map. This
map provides a clear picture of how each initiative relates to specific customer objec-
tives, thereby enhancing the strategic planning process. Each initiative can be assessed
using a value-feasibility matrix, which takes into account the initiative’s ease of imple-
mentation and the value it generates. This process aids in prioritizing initiatives that
offer maximum value while considering the implementation effort required. The em-
phasis should be on initiatives with high value and low implementation effort as quick
wins, with others of high value targeted for later stages. Additionally, it’s advisable to
map dependencies among initiatives within the same catalog of initiatives.

Goal Dependencies on Value Ease of

No. Initiative Description
Contribution Other Initiatives Assessment Implementation

Conduct a conversion assessment study

Conversion
A1 for a brownfield conversion of the SAP Goal 2 Initiative B1 and D4 High Medium
Assessment ERP system PRD to SAP S/4HANA.

Develop a detailed concept on data

Data Cleansing cleansing requirements as a preproject
A2 Goal 2 Initiative A1 and D3 High Low
Concept of the planned SAP S/4HANA
conversion project.

A3 … … … … ..

Figure 2.24 Initiatives Catalog

82 82
 2 The
2.2 SAP Enterprise
Enterprise Architecture
Architecture Framework
Methodology

Utilizing the initiatives catalog as the cornerstone, you can formulate the roadmap. Ini-
tially, you can group the primary initiatives based on business or IT initiatives, LoB-
specific endeavors (such as finance or procurement), end-to-end business processes, 2
SAP products, or a combination of diverse criteria. Further structural elements may
include phases of transformation programs (e.g., foundation, quick wins, innovation)
or alignment with the organization’s key strategic objectives (e.g., supporting a new
business model). During the creation of these clusters, it’s imperative to consider
dependencies and analyze and determine sequences. Ultimately, you can illustrate the
roadmap in various formats, one example of which is provided in Figure 2.25.

Phase 1 2025 Phase 2 2027 Future Opportunities

Foundation and Quick Wins Optimize and Standardize Grow and Innovate

Corporate
P3 Vision
P2
P1
Planning
F2 S3

F1 T4
vbbb
S2 T3

T2
Finance S1

T1

Sustainability

Technology Platform

Figure 2.25 Roadmap Template

The architecture roadmap, alongside the application architecture overview diagram,

typically stands out as one of the most crucial artifacts produced during planning activ-
ities because it synchronizes all elements from various artifacts on a timeline. How-
ever, it’s important to note that you should not treat the roadmap as a detailed project
plan at this stage, as doing so would entail including additional levels of detail that are
not intended during the architecture planning phase. Nonetheless, when coupled with
the work breakdown structure discussed in the next section, the architecture roadmap
serves as the primary foundation for all subsequent program or project-related plan-
ning endeavors.

Work Breakdown Structure

The work breakdown structure (WBS) is a crucial artifact in project management
because it functions as a hierarchical framework that dissects a project into smaller,

83
2 2 The SAP Enterprise Architecture Framework
The SAP Enterprise Architecture Framework

more manageable components. Its primary purpose is to provide a clear definition,

organization, and control mechanism for the entirety of a project’s lifetime. By struc-
turing initiatives into discrete sections and deliverables, the WBS enables teams to
better allocate resources and track progress effectively. Moreover, it serves as a founda-
tional tool for estimating both the effort and the cost associated with each initiative
within the project. Typically, collaboration between enterprise architects and the
implementation team lead facilitates the development of the WBS, effort, and cost esti-
mations, marking a pivotal transition from the architecture planning phase to the
implementation phase of the project.
You can create the work breakdown structure by following these steps:
1. Define major deliverables and milestones and break down the initiative in scope
into deliverables, alongside project phases, milestones, and activities. First, identify
the major outcomes or deliverables that need to be achieved throughout the project.
Then, break down the entire project scope into smaller, more manageable delivera-
bles, aligning them with project phases, milestones, and specific activities required
to accomplish them.
2. Estimate resource requirements and estimate relevant resources per line item
(internal, external, license, third-party costs, etc.). Once the deliverables are defined,
estimate the resources needed to complete each line item effectively. Consider both
internal and external resources, licensing needs, and any third-party costs that may
arise during the project.
3. Align with key stakeholders and review and agree with them on the breakdown
structure, effort, and cost. Engage key stakeholders throughout the WBS creation
process to ensure alignment with project goals and expectations. Present to stake-
holders the breakdown structure, along with effort and cost estimations, for their
review and approval. Collaboratively refine as needed to gain consensus and ensure
everyone’s understanding and agreement.

2.2.7 Requirements and Governance

The requirements and governance domain is not linked to a specific phase of an archi-
tecture engagement, but it includes relevant governance artifacts such as risk catalogs
and architecture principles. This domain captures important architectural decisions as
architecture decision records (ADRs) and manages requirements that can emerge in any
architecture domain. It ensures that governance is maintained throughout the project,
supporting consistency and compliance with architectural principles and policies.
Let’s explore the key components of requirements and governance in the next sec-
tions.

84 84
 2 The
2.2 SAP Enterprise
Enterprise Architecture
Architecture Framework
Methodology

Requirements Catalog
The requirements catalog is a structured document that captures and organizes both
2
the functional and the nonfunctional requirements for a specific project, system, or
product. It plays a crucial role in identifying and collecting high-level business needs,
which helps to clearly define the objectives of the business, leading to a more focused
and aligned approach to project development. Through a refinement process, the ini-
tial high-level requirements undergo thorough analysis, resulting in clear and action-
able requirements that can be effectively implemented. By classifying requirements,
the catalog enables easier review and tracking, ensuring that each requirement is con-
sidered by the appropriate owner and well documented for subsequent analysis. This
process ultimately enhances overall project management and communication.
To create a requirements catalog, like the one in Figure 2.26, you can perform the fol-
lowing steps:
1. Document all identified high-level business needs and requirements.
2. Classify requirements as either functional or nonfunctional.
3. Further classify nonfunctional requirements using classes of nonfunctional require-
ments.
4. Categorize requirements based on business capabilities, distinguishing between
strategic business requirements and operational business requirements.
5. Maintain additional attributes for business requirements such as status, priority,
and owner.

Figure 2.26 Example of Requirements Catalog

Architecture Principles Catalog

Principles serve as foundational guidelines in enterprise architecture planning, ex-
pressing overarching, long-term objectives that drive organizational transformation.
They are high-level and enduring, rooted in strategic business and IT goals rather than
reactive to day-to-day demands. An example principle, “Subscribe before buy before
build,” highlights this strategic focus by emphasizing the prioritization of subscrip-
tion-based solutions over immediate purchase or in-house development.
In contrast, policies are actionable rules that guide the application of enterprise archi-
tecture. While they may be influenced by current trends, policies refrain from specify-
ing particular products or protocols. For instance, a policy dictating the adoption order

85
2 2 The SAP Enterprise Architecture Framework
The SAP Enterprise Architecture Framework

of cloud solutions―such as software as a service (SaaS), platform as a service (PaaS),

and infrastructure as a service (IaaS)―aligns with strategic objectives without naming
specific vendors or platforms.
Finally, standards precisely define the products, best practices, and protocols that sup-
port policies. While they aim for longevity, standards may change more frequently
than policies, ensuring alignment with evolving technology landscapes. An example
standard, such as Amazon Web Services (AWS) as the designated cloud IaaS provider,
illustrates the specificity of standards compared with the broader scope of policies and
principles.
Table 2.3 gives an example of the definition of a principle.

Principle Simplify and standardize processes.

Statement Streamline and standardize business processes across the organization to

optimize efficiency and agility.

Rationale Simplifying and standardizing processes in SAP S/4HANA facilitates seam-

less integration, reduces complexity, and enhances scalability. This principle
promotes operational consistency, accelerates deployment timelines, and
mitigates risks associated with fragmented or redundant processes.

Implications Adhering to this principle entails conducting thorough process assess-

ments, identifying opportunities for consolidation and optimization, and
defining standardized processes aligned with industry best practices. It also
requires change management efforts to ensure organizational buy-in and
adoption of standardized processes.

Table 2.3 Example of Architecture Principal

Architecture principles are typically formulated by enterprise architects in collabora-

tion with key stakeholders and subsequently endorsed by the architecture board. They
draw upon existing principles at the enterprise level, if applicable, ensuring coherence
and alignment with broader organizational goals. These principles are meticulously
crafted to provide clear guidance for decision-making processes and are tailored to
steer the architecture and implementation of the target architecture in harmony with
business strategies and visions. The development of architecture principles is chiefly
influenced by various factors, including the enterprise’s mission, strategic plans, and
organizational structure, as well as ongoing strategic initiatives and external con-
straints such as market dynamics and regulatory requirements. Additionally, consider-
ation is given to the current technology landscape within the enterprise, encompass-
ing existing systems, infrastructure, and emerging industry trends that may impact
the enterprise environment. Through a comprehensive assessment of these factors, ar-
chitecture principles are crafted to form a robust framework for driving architectural
decisions and fostering strategic alignment across the organization.

86 86
 2 The
2.2 SAP Enterprise
Enterprise Architecture
Architecture Framework
Methodology

Risk Catalog
The risk catalog serves as a comprehensive repository for systematically capturing, cat-
2
egorizing, and managing risks throughout the enterprise architecture process. This
artifact encompasses various types of risks, including technical, operational, strategic,
and regulatory, among others. By documenting risks alongside their associated impact,
likelihood, and mitigation strategies, the risk catalog enables stakeholders to proac-
tively identify and address potential threats to the successful execution of architec-
tural initiatives. Additionally, it facilitates informed decision-making by providing a
centralized reference point for assessing risk exposure and prioritizing risk mitigation
efforts. Through regular updates and reviews, the risk catalog evolves dynamically,
reflecting changes in the organizational landscape and ensuring that risk management
remains an integral aspect of the architectural governance framework.
Creating a risk catalog for architecture planning like the one in Figure 2.27 involves the
following steps:
1. Identification
Collaborate with stakeholders to identify potential risks relevant to the architectural
initiatives, considering factors like technological dependencies, stakeholder require-
ments, and regulatory compliance.
2. Documentation
Document each identified risk along with its perceived frequency of occurrence and
potential effect on architecture objectives.
3. Assessment
Track the assessment status of each risk to monitor its evolution over time, facilitat-
ing proactive risk management.
4. Ownership
Assign a risk owner to each identified risk to ensure accountability and effective
implementation of mitigation strategies.
5. Scope alignment
Align identified risks with the scope of the architecture program to contextualize
their relevance and prioritize mitigation efforts accordingly.

Figure 2.27 Example of Risk Catalog

87
 2 2 The SAP Enterprise Architecture Framework
The SAP Enterprise Architecture Framework

Architectural Decisions Catalog

The architectural decisions catalog supports architecture planning as a comprehensive
record of the key decisions made throughout the architectural process. This artifact
encapsulates the rationale, considerations, and outcomes of significant architectural
choices, providing valuable insights into the evolution of the architectural framework.
Typically, the architecture board is responsible for making these decisions―but by
documenting architecture decisions, stakeholders gain clarity on the reasoning behind
specific design choices, helping them to gain better understanding of and alignment
with overarching architectural goals and objectives. Moreover, this artifact serves as a
reference point for future decision-making, facilitating consistency, transparency, and
traceability within the architectural process.
To create an architectural decisions catalog like the one outlined in Figure 2.28, follow
these steps:
1. Identify architectural decisions to be taken
Begin by listing all the significant architectural decisions that need to be addressed.
2. Assign priority
Prioritize each architectural decision based on factors such as impact, urgency, and
complexity. This helps you focus on the most critical decisions first.
3. Describe the decision taken
For each decision, provide a description. This should include what the decision is,
why it was made, and the implications it has.
4. Document the criteria that led to the decision
Outline the criteria and rationale that guided the decision-making process. This
could include business requirements, technical constraints, performance consider-
ations, and any other relevant factors.
5. Optional: Cross-reference decision accelerators
If any decision accelerators (e.g., reference content from SAP) were used in making a
decision, document them as well. Provide cross-references to the relevant resources
for future reference.

Ref Decision Priority Decision Description Criteria Reference to Decision Accelerator

1 SAP EWM High SAP EWM will be deployed Business processes integration, Deployment options for SAP EWM
embedded in SAP S/4HANA maintenance, latency, risk, effort
2

… … … … … …

Figure 2.28 Example of an Architectural Decisions Catalog

88 88
 2 The SAP Enterprise Architecture
2.3 SAP’s Framework
Reference Content

2.3 SAP’s Reference Content

Throughout the diverse activities involved in enterprise architecture planning, refer- 2
ence content plays a crucial role, providing invaluable guidance and insights. Whether
enterprise architects are analyzing current systems, shaping future architectures, or
aligning technology with business objectives, reference content serves them as a reli-
able resource. It offers a structured foundation for decision-making, ensuring archi-
tects can leverage established best practices, standards, and organizational knowledge
effectively. Reference content simplifies the daily tasks of an enterprise architect by
providing a ready repository of knowledge and insights. With access to established best
practices, architects can quickly find solutions to common challenges and industry
standards. Also, by leveraging reference materials, architects can reduce the time they
spend on research, ensure consistency across projects, and mitigate risks effectively.
Ultimately, reference content empowers architects to focus their energy on innovation
and strategic planning, rather than constantly reinventing the wheel. It thus enhances
productivity and drives the success of architectural initiatives.
The reference content within SAP EA Framework provides enterprise architects with
distinct advantages over other frameworks like TOGAF and Zachman. It provides enter-
prise architects with a wealth of resources, including best practices, methodologies,
and industry-specific insights tailored to SAP environments. With access to such com-
prehensive reference materials, architects can expedite their decision-making pro-
cesses, enhance the quality of their designs, and ensure alignment with SAP-specific
standards and principles. Furthermore, the richness of reference content within the
SAP framework enables architects to navigate complexities more effectively, address-
ing challenges with greater confidence and precision. Ultimately, this advantage trans-
lates into streamlined architectural endeavors, improved implementation outcomes,
and enhanced value realization for organizations leveraging SAP solutions.
Figure 2.29 shows the current publicly available or planned reference content that SAP
provides as part of SAP EA Framework.

Strategy and Motivation Business Architecture Solution Architecture Technology Architecture

SAP Signavio SAP Reference SAP Reference SAP BTP Reference

Strategic Content Business Architecture Solution Architecture Architectures

Architectural Decisions

Architecture Decision Accelerators

Figure 2.29 Overview of Available and Planned Reference Content for SAP EA Framework

89
2 2 The SAP Enterprise Architecture Framework
The SAP Enterprise Architecture Framework

SAP’s reference architecture content primarily emphasizes business architecture and

solution architecture, exemplified by SAP Reference Business Architecture and SAP
Reference Solution Architecture. Moreover, SAP extends its offerings through SAP Sig-
navio, providing strategic content for various industries from an outside-in perspec-
tive. Within the domain of technology architecture, SAP furnishes best-practice
content tailored to diverse SAP BTP architectural use cases. Additionally, at the solu-
tion implementation level, SAP offers best-practice business process content in BPMN
format, accompanied by configuration guides and test scripts. However, since this con-
tent pertains to solution implementation rather than enterprise architecture, it’s not
considered part of the enterprise architecture domain.
SAP reference architecture content offers a comprehensive approach to exploring and
understanding SAP’s solution offerings, guided by the structure and format of SAP EA
Methodology and aligned with industry standards like TOGAF and the American Pro-
ductivity & Quality Center (APQC). The APQC Cross-Industry Process Classification
Framework (APQC Cross-Industry PCF) is a comprehensive model used to standardize
business processes across different industries. The APQC Cross-Industry PCF includes a
wide range of business processes, categorized into functional areas such as finance,
human resources (HR), supply chain, and customer service, among others.
Central to the SAP EA Framework reference content are SAP Reference Business Archi-
tecture and SAP Reference Solution Architecture. The former provides standardized
content for business architecture, and the latter maps recommended solutions to
SAP’s portfolio. They ensure consistency and clarity in communicating the architec-
tural landscape of enterprises, thus facilitating informed decision-making and align-
ment with organizational goals.
In subsequent sections, we’ll delve deeper into the key repositories of reference con-
tent provided by SAP for use with SAP EA Framework.

2.3.1 SAP Reference Business Architecture

SAP Reference Business Architecture encompasses diverse collections of architectural
reference content focused on the business domain. Both SAP Reference Business Archi-
tecture and other reference sources adhere to a unified meta model that is akin to the
artifacts within SAP EA Framework mentioned earlier. This alignment streamlines arti-
fact development, ensuring coherence through a shared language. The primary com-
ponents of SAP Reference Business Architecture include the following:
 Business capability model
 Business process model
 Business data model (planned)
 Business organizational model (planned)

90 90
 2 The SAP Enterprise Architecture
2.3 SAP’s Framework
Reference Content

As depicted in Figure 2.30, SAP Reference Business Architecture is organized in align-

ment with distinct enterprise domains, offering a range of end-to-end business process
models and business capability models tailored to each domain. Moreover, SAP Refer- 2
ence Business Architecture incorporates industry-specific business capability and pro-
cess models to cater to diverse sectors. Consequently, choosing an end-to-end business
process model such as idea to market, with associated business capabilities in areas like
research and development (R&D), engineering, and product management, can yield
varied outcomes depending on the chosen industry. Additionally, alongside industry-
specific iterations of the content, a generic perspective remains accessible in instances
where a specific industry is not yet covered by SAP Reference Business Architecture.

Enterprise Develop Products

Supply: Fulfill Demand Customer: Generate Corporate: Plan and Manage the Enterprise
Domain and Services
Demand

End-to-End
Recruit to Acquire to
Business Pro- Idea to Market Source to Pay Plan to Fulfill Lead to Cash Governance Finance
cess Model Retire Decommission

R&D/ Sourcing and Supply Chain Human Asset Enterprise Finance

Marketing Strategy
Engineering Procurement Planning Resources Management

Product Supply Chain Sustainability

Management Sales Management
Execution

Portfolio and
Supply Chain Omnichannel Project
Business Enablement Commerce Management
Capability
Model Governance,
Customer Risk, and
Manufacturing
Service Compliance
International
Service Delivery Trade and
Global Tax

IT Management

Industries:
Cross- and
Consumer Industries Discrete Industries Energy and Natural Resources Financial Services Public Services Service Industries
Industry-
Specific
SAP S/4HANA Cloud,
SAP Business Technology SAP Customer
Applications SAP S/4HANA, SAP SAP SuccessFactors SAP Concur SAP Ariba SAP Fieldglass Partner Applications
Platform (SAP BTP) Experience
Digital Supply Chain

Figure 2.30 Introduction to SAP Reference Business Architecture

Figure 2.31 lists the core and supporting processes of SAP Reference Business Architec-
ture. Each of the listed end-to-end business processes (e.g., source to pay) is further
detailed into modular business processes (e.g., source to contract, procure to receipt).
Further exploration into detailed business activities beneath those modular business
processes is consistently feasible, as illustrated in Figure 2.32. Under the modular busi-
ness process Source-to-contract, designated business segments such as Source prod-
ucts and services are established as elements, providing structure to underlying
business activities. For each business activity, such as Prepare RFX (request for pro-
posal/information/quotation) or Process RFX, corresponding business capabilities are
also mapped, including Supplier RFX Preparation, Supplier RFX Execution, and Sourcing
Collaboration.

91
91
 2 2 The SAP Enterprise Architecture Framework
The SAP Enterprise Architecture Framework

Generic End-to-End Business Processes + Business Process Modules: Core Processes

and Services
Products

Plan to Optimize Products/ Manage

Idea to Design to
Idea to Market Products/ Services to Products/
Requirement Release
Services Market Services

Plan to Optimize Manage

Core Processes

Source to Plan to Optimize Procure to Request to

Source to Pay Sourcing and Invoice to Pay Suppliers and
Contract Fulfillment Receipt Resolution
Procurement Collaboration
Supply

Plan to Optimize Procure to Deliver Product Deliver Service Manage

Plan to Fulfill Make to Inspect
Fulfillment Receipt to Fulfill to Fulfill Fulfillment
Customer

Plan to Optimize Manage

Opportunity to Request to
Lead to Cash Marketing and Market to Lead Order to Fulfill Invoice to Cash Customers and
Quote Service
Sales Channels

Plan to
Recruit to Develop to Reward to Manage
Recruit to Retire Optimize
Onboard Grow Retain Workforce
Workforce
Supporting Processes

Acquire to Plan to
Acquire to Operate to Offboard to
Optimize Manage Assets
Decommission Onboard Maintain Decommission
Corporate

Assets

Manage Manage Gov- Manage

Plan to Optimize Manage Manage Global
Governance Portfolios ernance, Risk, Information
Enterprise Sustainability Trade and Tax
and Projects and Compliance Technology

Plan to Optimize Record to Manage Manage Real

Finance Invoice to Pay Invoice to Cash
Financials Report Treasury Estate

Figure 2.31 Overview of Supported SAP Reference Business Architecture Processes

Figure 2.32 Source to Contract Drilldown in SAP Reference Business Architecture

SAP Reference Business Architecture not only supports general business processes but
also accommodates industry-specific variations known as business process variants.
For instance, within the source to pay domain, there exist specialized variants such as
source to pay for direct physical products, source to pay for subcontracting, and source
to pay for services, among others.
Furthermore, SAP Reference Business Architecture enables detailed scoping and explo-
ration of business activities and capabilities, offering a comprehensive model encom-
passing both generic and industry-specific business capabilities. This model spans
business domains (level 1), business areas (level 2), and detailed business capabilities
(level 3), as illustrated on the business domain level in Figure 2.33 and the complete drill
down from the corporate business domain to business area asset management and its
related business capabilities in Figure 2.34.

92 92
 2 The SAP Enterprise Architecture
2.3 SAP’s Framework
Reference Content

Figure 2.33 Business Domains from SAP Reference Business Architecture

Figure 2.34 Drilldown from Business Domain (Level 1) to Business Area (Level 2) to Business
Capabilities (Level 3)

The primary benefit of SAP Reference Business Architecture lies in its provision of both
generic and industry-specific business process and capability models, with a strong
alignment between the two. This facilitates seamless navigation between business pro-
cesses and capabilities in both directions. Additionally, SAP Reference Business Archi-
tecture is agnostic to solutions and applications, allowing it to map the business
architecture domain without being tied to any particular software provider.

2.3.2 SAP Reference Solution Architecture

SAP Reference Solution Architecture is the counterpart to SAP Reference Business
Architecture, and it outlines the application, data, and technology aspects of SAP and

93
 2 2 The SAP Enterprise Architecture Framework
The SAP Enterprise Architecture Framework

partner solutions in alignment with business architecture assets. It provides recom-

mended implementation guidance utilizing SAP software components, including
endorsed partner components. Through SAP Reference Solution Architecture, stake-
holders gain access to an implementable SAP reference architecture that illustrates
how the components interact to support business processes. Furthermore, organiza-
tions can leverage this content to define their own target architecture based on their
specific needs and objectives. The primary components of SAP Reference Solution
Architecture include the following:
1. Solution capability model
2. Solution process model
3. Solution data model (planned)
4. Solution organizational model (planned)

SAP Reference Solution Architecture can be seen as the specialized counterpart of SAP
Reference Business Architecture. It facilitates the transition from a solution-agnostic
perspective in the business architecture to an SAP-specific solution architecture,
revealing the necessary solution components to uphold the chosen business process
or capability.
Figure 2.35 illustrates the correlation between SAP Reference Business Architecture and
SAP Reference Solution Architecture. The transition from the business domain to the
solution domain is facilitated through the alignment of business capabilities with solu-
tion capabilities.

SAP Reference Business Architecture SAP Reference Solution Architecture

Basic Structure of an Enterprise
Enterprise Domain According to Its Core Functions

Business Domain
End-to-End Business Process
consists of consists of

Business Process Module Business Area

consists of consists of

Business Process Segment Business Capability is realized by Solution Capability

Business Activity enables Solution Component

Business Process Model Business Capability Model

Figure 2.35 Connection of SAP Reference Business Architecture to SAP Reference Solution
Architecture

94 94
 2 The SAP Enterprise Architecture
2.3 SAP’s Framework
Reference Content

In the SAP reference model, the linkage between business processes at the business
activity level and business capabilities, as well as between business capabilities and
solution capabilities, enables the mapping of required solution components from 2
either the business process level or the business capability level.
This relationship is displayed in Figure 2.36. We revisit the Source-to-contract example
depicted in Figure 2.32, this time examining it from a solution component perspective,
wherein the necessary solution components are aligned with business activities
through solution capabilities.

Figure 2.36 SAP Reference Solution Architecture for Business Process Source to Contract
(Selection)

Within the business process segment focusing on sourcing products and services, and
within its associated activities such as Prepare RFX, Process RFX, Negotiate bid and
select suppliers, and Define purchase quotas for products (which are drawn from SAP
Reference Business Architecture), SAP Reference Solution Architecture automatically
establishes connections between solution capabilities and business activities. For
instance, the business activity Prepare RFX corresponds to the solution capability Sup-
plier RFX Preparation (SAP S/4HANA Cloud, SAP Ariba). Through this alignment, the ref-
erence content facilitates an automated mapping from solution capabilities to the
required or optional solution components. For example, Supplier RFX Preparation is
linked to SAP S/4HANA Cloud and SAP Ariba Sourcing. Furthermore, the content
encompasses mappings for SAP partner solutions and solutions supporting specific
use cases.
If the business capability is intended as the starting point for defining the business
architecture, SAP Reference Solution Architecture facilitates not only the mapping
from the business process level to solution components but also mapping directly
from business capabilities to solution components. An example illustrating this is pro-
vided in Figure 2.37.
In the business domain of Asset Management and specifically within the business area
of Asset Lifecycle Delivery, the underlying business capabilities are linked to solution

95
2 2 The SAP Enterprise Architecture Framework
The SAP Enterprise Architecture Framework

components. For instance, the business capability Asset Health Monitoring is sup-
ported by solution components such as SAP S/4HANA Cloud and SAP Asset Perfor-
mance Management. This method allows us to first identify the necessary business
capabilities and then delve into the required solution components when constructing
the solution target architecture based on the business architecture. With the reference
content already providing mappings for SAP solutions, this approach significantly
expedites the process within any SAP-centric environment. However, since most land-
scapes comprise not only SAP solutions but also third-party alternatives, we have the
capability to map business capabilities to any third-party non-SAP solution as well.
This mapping can be easily executed using the tools detailed later in this chapter and is
an integral part of every service engagement for architecture planning.

Figure 2.37 SAP Reference Solution Architecture: Mapping Business Capabilities to Solution
Components

2.3.3 Additional Reference Content

In addition to SAP Reference Business Architecture and SAP Reference Solution Archi-
tecture, SAP offers supplementary reference architecture sources tailored to various
use cases. However, some of these additional sources are highly specific to particular
use cases and lack the broad scope of SAP Reference Business Architecture and SAP Ref-
erence Solution Architecture. Other sources, such as SAP S/4HANA scope items at the
BPMN level, extend beyond the domain of enterprise architecture and are more suited
to solution implementation levels. Hence, they are not included in this chapter. Addi-
tionally, we refrain from discussing reference content exclusive to SAP and inaccessi-
ble to external enterprise architects.

SAP Signavio Process Explorer and SAP Signavio Process Navigator

SAP Signavio, as a suite of tools, can’t be classified solely as a source of reference con-
tent. SAP Signavio Process Explorer and SAP Signavio Process Navigator do offer SAP

96 96
 2 The SAP Enterprise Architecture
2.3 SAP’s Framework
Reference Content

Reference Business Architecture and SAP Reference Solution Architecture as part of

their content sources (along with other implementation-focused reference materials
such as best practice scope items at the BPMN level). However, it is not sufficient to 2
consider SAP Signavio solely from a tool perspective where reference content can be
accessed.
SAP Signavio also provides outside-in content for the strategic domain of SAP EA Frame-
work. This content includes strategic objectives and business goals that can be aligned
with required business processes from SAP Reference Business Architecture. In Chapter
6, we’ll demonstrate a use case illustrating how you can connect the strategy domain to
the business domain by leveraging strategic content.
You can access SAP Signavio Process Navigator at https://me.sap.com/processnavigator.

SAP Business Technology Platform

SAP BTP Guidance Framework is a comprehensive resource designed to help organiza-
tions effectively navigate and leverage the capabilities of SAP BTP. As shown in Figure
2.38, it provides structured guidance, best practices, and tailored recommendations to
ensure successful adoption and implementation of the platform’s various services and
tools.

Guidance for Guidance for Guidance for

Architects Developers Administrators

Decision Guides
Integration Architecture Guide SAP BTP Developer’s Guide
Extension Architecture Guide

Reference Architectures Recommendations

SAP BTP Reference Architecture SAP BTP Solution Diagram Design Repository Security Recommendations

Business Process Blueprints

Methodologies DevOps
SAP Integration Solution Advisory Methodology DevOps with SAP BTP
SAP Application Extension Methodology
SAP Data and Analytics Advisory Methodology

Best Practices Learning and Enablement Community

SAP Business Technology Platform

Figure 2.38 SAP BTP Guidance Framework (http://s-prs.co/v586300)

The key elements of SAP BTP Guidance Framework as depicted in Figure 2.38 are deci-
sion guides, reference architectures, methodologies, recommendations on implemen-
tation options, and DevOps principles. We describe these elements as follows:

97
2 2 The SAP Enterprise Architecture Framework
The SAP Enterprise Architecture Framework

 Decision guides
The Integration Architecture Guide is designed to help enterprise and integration
architects modernize their existing integration architectures using SAP BTP. It pro-
vides insights into SAP’s current technology offerings and highlights the integration
services available to meet the diverse needs of heterogeneous IT landscapes. The
Extension Architecture Guide provides guidance on extending SAP applications on
SAP BTP using modular, flexible approaches. The Developer’s Guide is a comprehen-
sive resource for developers building, deploying, and managing applications on SAP
BTP. It offers tools, services, and best practices to maximize development efficiency
and effectiveness.
 Reference architectures
The SAP BTP reference architectures provide a comprehensive catalog of best-prac-
tice architectural patterns to guide organizations in designing and implementing
solutions on SAP BTP. SAP BTP’s solution diagram design repository is a collaborative
space that offers prebuilt solution diagrams, enabling architects and developers to
visualize and design their SAP BTP implementations effectively. Meanwhile, the
business process blueprints offer detailed process descriptions for key business pro-
cesses, ensuring alignment with industry standards and best practices.
 Recommendations
SAP BTP’s security recommendations provide a comprehensive set of guidelines for
ensuring the security of your SAP BTP environment. These recommendations cover
key areas such as identity and access management, data protection, compliance, and
secure application development.
 Methodologies
SAP Integration Solution Advisory Methodology provides a structured approach for
guiding organizations in designing and implementing effective integration strate-
gies using SAP solutions. SAP Application Extension Methodology focuses on extend-
ing SAP applications on SAP BTP, offering best practices for scalable and maintainable
extensions. Meanwhile, SAP Data and Analytics Advisory Methodology offers a frame-
work for maximizing the value of data and analytics within SAP ecosystems, ensur-
ing informed decision-making and business insights.
 DevOps
DevOps with SAP BTP provides a comprehensive guide for implementing DevOps
practices on SAP BTP. It covers key principles like continuous integration, continu-
ous delivery, monitoring, and automation, tailored specifically to SAP environ-
ments. The guide helps organizations streamline their DevOps processes, ensuring
faster delivery, improved quality, and more efficient collaboration between devel-
opment and operations teams. It also offers tools and best practices to support Dev-
Ops initiatives within SAP BTP.

98 98
 2 The SAP Enterprise Architecture
2.3 SAP’s Framework
Reference Content

SAP Business Accelerator Hub

SAP Business Accelerator Hub, formerly known as SAP API Business Hub, is an online
2
platform provided by SAP that offers access to a wide variety of reference and best-
practice content. You can access SAP Business Accelerator Hub at https://api.sap.com/.
For example, the following types of reference content can be found there:
 Solution value flow diagrams
 Solution component diagrams
 Solution data flow diagrams
 Solution process flows
 Application programming interfaces (APIs)
 Events
 Core data services (CDS) views

Architecture Decisions Accelerators

In SAP-centric enterprise architecture landscapes, you must make specific decisions
pertaining to enterprise architecture when designing the new to-be architecture. Draw-
ing from our experience, we know that numerous decisions can be standardized using
predefined criteria that facilitate decision-making. As a result, the SAP Transformation
Hub team has introduced architecture decision accelerators as reference content. These
accelerators offer predefined architectural patterns, best practices, and implementa-
tion guidelines, enabling architects to make informed decisions efficiently and acceler-
ate the design and implementation of robust architectures. By leveraging architecture
decision accelerators, enterprise architects can reduce the time and effort required to
address recurring architectural issues, enhance the quality and consistency of their
solutions, and ultimately drive innovation within their organizations.
As examples, there are architecture decision accelerators for the following decisions:
 Financial analytics deciding between SAP S/4HANA, SAP Analytics Cloud, and SAP
Disclosure Management
 SAP Extended Warehouse Management (SAP EWM) deployment options to help
make a decision between embedded and de-centralized warehouse management
 Solution options for manufacturing operations management
 SAP S/4HANA event management standalone or add-on deployment options

These decision accelerators include decision trees that simplify the process of choosing
the right architecture. An example of a decision tree for manufacturing performance
management is illustrated in Figure 2.39.

99
99
2 2 The SAP Enterprise Architecture Framework
The SAP Enterprise Architecture Framework

Start

Business and IT
Transformation in
Your Company

SAP Digital OEE, Live Existing Existing SAP

No No No Existing SAP No Yes
Manufacturing in Monitoring, SAP BW in Analytics
BW/4HANA?
Scope? etc.? Place? Cloud?

Yes Yes Yes Yes No

SAP Digital
Modernize SAP BW to
Manufacturing for SAP Analytics Cloud
SAP Datasphere
Insights and Execution

End

Figure 2.39 Example Decision Tree for Manufacturing Performance Management

These decision accelerators can be applied within enterprise architecture work and
documented within the architecture decision catalog artifact, serving as references to
justify why a particular decision was made.
You can find the decision accelerators at http://s-prs.co/v586301.

100
 Das, Klee, Reichel

Enterprise Architecture
with SAP
Planning, Management, and
Transformation

■ Use SAP Enterprise Architecture Frame-

work and SAP LeanIX to optimize your
daily architecture work
■ See enterprise architecture in action with
SAP use cases
■ Establish and manage an integrated and
collaborative enterprise architecture
practice

www.sap-press.com/5863

We hope you have enjoyed this reading sample. You may

recommend or pass it on to others, but only in its entirety,
including all pages. This reading sample and all its parts
are protected by copyright law. All usage and exploitation
rights are reserved by the author and the publisher.

Anup Das is a chief enterprise architect and the regional delivery head for SAP
Transformation Hub in North America. Peter Klee leads SAP Transformation
Hub within the Customer Services & Delivery board area. Johannes Reichel is a
principal enterprise architect for SAP Transformation Hub, focusing on global
transformation and architecture planning for SAP clients.

ISBN 978-1-4932-2573-6 • 562 pages • 11/2024

E-book: $84.99 • Print book: $89.95 • Bundle: $99.99