Investigating the SAP Enterprise Architecture Methodology

The SAP Enterprise Architecture (EA) Methodology is one of the pillars of the SAP Enterprise Architecture (EA) Framework covering:

• Methodology

• Reference Architecture Content

• Tooling

• Practices

• Services

The SAP Enterprise Architecture (EA) Methodology supports enterprise architecture work in different use cases, such as initiating engagements, defining target architectures to implementation and continuous transformation.

The SAP EA Methodology is based on industry standards such as TOGAF®, BPMN™, UML®, APQC® Cross-Industry Process Classification Framework. It is broadly adopted across SAP. The SAP EA Methodology delivers benefits by:

• Providing concrete guidance to support enterprise architecture journeys.
• Setting up a uniform language and techniques for cross-unit alignment along the entire software lifecycle.
• Forming the basis for boundaryless content fluency, intense reuse across use cases, and feedback provisioning.

The SAP EA Methodology introduces:

Enterprise Architecture concepts

These are abstract representations of objects, elements, or entities relevant to the Enterprise Architecture domain. Examples are concepts as Business Capabilities, Solution Components, Data Flows, or Communication Channels.

Enterprise Architecture artifacts

These are typical architecture work products such as diagrams, catalogs, reports, and so on. Examples are Stakeholder Maps, Business Context Diagrams, Solution Value Flow Diagrams, or Solution Component Diagrams.

Proven Enterprise Architecture techniques

A set of guidelines, standards, processes, and behaviors to deliver enterprise architecture work products and manage enterprise architecture in alignment with the business goals. Examples are Capability-based Planning, Stakeholder Mgt, Architecture Road Mapping.

The delivered concepts, artifacts, and EA techniques are based on agreed principles and the SAP EA Methodology meta-model that describes the relationship between the concepts as well as their key attributes.

The agreed principles are fundamental guidelines that capture shared values, goals, priorities, and essential beliefs that have guided the SAP EA Methodology design.

The SAP Enterprise Architecture (EA) Methodology concepts are the fundamental, abstract representations of entities relevant to Enterprise Architecture. They serve as essential building blocks for consistent and comprehensive modeling across all domains.

The SAP (EA) Methodology enables enterprise architects to articulate their understanding and ideas and to achieve consistency across enterprise architecture use cases.

Here are examples of SAP EA Methodology concepts within each domain:

Concepts are organized into domains: specific subject areas or problem spaces.

The business architecture domain and the solution architecture domain are central to the SAP EA Methodology, which links business and IT and supports the collaboration of business owners and architects. Both domains consist of a Capability View, a Process View, a Data View, and an Organization View.

The Business Architecture Domain is independent or agnostic of SAP or any service provider portfolio. It uses pure business language.

• The Capability View describes what abilities and competencies that an enterprise needs to operate in its market successfully.
• The Process View explains how business activities create value in business processes, transforming inputs into outputs and leveraging the business capabilities.
• The Data View shows the information available and required to plan, execute, and control these processes.
• The Organization View describes the organizational structure with roles and responsibilities.

The Solution Architecture Domain, with Application and Data Architecture, focuses on how SAP, partner, or third-party solutions address and support the needs of the Business Architecture for all these aspects.

• The Capability View describes how Solution Components support and address the Business Capabilities.
• The Process View explains how processes are supported across the integrated Solution Components.
• The Data View shows where data is stored and how data flows between the Solution Components.
• The Organization View describes which application roles must be assigned to users and how access is managed in the applications.

Within the SAP EA Methodology, the concepts across different domains are related and associated with each other, creating a comprehensive and consistent system of architecture building blocks.

Beyond the Business Architecture and the Solution Architecture domain, the SAP EA Methodology covers:

• Strategy & Motivation Domain
• Technology Architecture Domain
• Opportunities & Migration Domain
• Architecture Principles & Vision Domain
• Requirements, Risks, and Architecture Decisions Domain

Meta-Model Overview

A meta-model is a model that consists of statements about concepts and the relationship between them. 

The SAP EA Methodology meta-model describes the attributes of the concepts, the relationship between the different concepts within the SAP EA Methodology, and the relation to other architecture domains.

Exploring the graphic: This snapshot from the SAP EA Methodology meta-model. Practitioners are in general not concerned about the meta-model. Only Enterprise Architecture tool engineering teams and EA methodology experts take this into consideration.

The snapshot shows parts of the Capability View in the Business Architecture and the Solution Architecture Domain. On the left side, the Strategy and Motivation Domain is adjacent to the right the Technology Architecture, below the Process View.

Enterprise Architecture artifacts are architecture work products created to capture, document, or communicate enterprise architecture. These artifacts can be, for example, diagrams, catalogs, models, specifications, other documents, or prototypes.

The introduced SAP EA Concepts are the building blocks for the SAP EA Methodology Artifacts.

The graphic provides an overview of the SAP EA Methodology artifacts and their assignments to the different domains.

Catalogs are lists of entities or concepts, possibly hierarchically structured.

Diagrams are graphical representations of models and underlying concepts. Diagrams of low complexity are often referred to as "Maps." Three examples of Artifacts:

1. A Business Capability Map:

   A Business Capability Map represents a complete and stable set of business capabilities, often showing three levels.

2. A Solution Component Diagram:

   A Solution Component Diagram is a graphical, structural representation of the Solution Components and Communication Channels required for a Solution Variant, their possible deployments, and their integration.

3. An Architecture Decision Catalog:

   An architecture decision catalog is a structured repository that records critical architecture decisions made during architecture development. It is a centralized reference for capturing, organizing, and communicating architecture decisions, rationales, and implications.

A deliverable is an (often contractually) committed artifact or a product of architecture work. Stakeholders of the architecture work shall review, agree upon, and sign off on deliverables.

The provisioning of enterprise architecture artifacts is the subject of SAP’s Suite Qualities and SAP product standard relevant.

Throughout the Architecture Development Cycle, which follows the TOGAF® Architecture Development Method – a registered trademark of the Open Group – we use several proven techniques. These include:

• Initiating architecture work
• Managing requirements, risks, or involved parties
• Capturing solutions and communicating architecture decisions
• Evaluating business capabilities
• Deriving solution components based on evaluated capabilities

In principle, the complete Architecture Development Cycle can be viewed as a distinct technique in its own right.

We offer specific training courses and lessons for different techniques conveyed by the SAP EA Methodology.

Architecture Techniques play a crucial role in ensuring the quality, communicability, reliability, and maintainability of architecture. By following established techniques, organizations can improve alignment between business and IT, reduce risks and costs, and enhance the overall quality and agility of their architectures.

Architecture Principles are fundamental guidelines that lead Enterprise Architects to make consistent and coherent decisions.

These principles capture an organization's shared values, business goals, priorities, and essential beliefs.

Their definition, rollout, and discussion ensure that the created architectures are in alignment with these common basics.

Creating the SAP EA Methodology, we agreed on several principles that guided our decisions on how to define the SAP EA Methodology.

1. Architecture Content Fluency

   The SAP Methodology supports multiple use cases along the Software Lifecycle.

   Shared architecture content reduces content creation efforts lead to critical and valuable feedback loops, improve content quality, and support consistent messaging across use cases.

   For different use cases, different aspects of the SAP EA models might be relevant.

2. Reuse Industry Standards (such as TOGAF®, BPMN™, UML®, APQC® PCF, SAP TAM)

   Using well-known industry standards such as TOGAF, BPMN, UML, or APQC’s cross-industry Process Classification Framework increases the acceptance of the methodology in the market and meets the expectations of experts.

   Reusing already known concepts, artifacts, and techniques reduces training efforts and existing training material can be leveraged. Already existing SAP and third-party tools can be leveraged as well. There are and have been BPMN tools, UML stencils, and so on, at SAP and outside SAP.

3. Extensibility

   The SAP EA Methodology defines concepts, artifacts, and techniques.

   The standard SAP EA Methodology enablement, as the training material and courses, focuses on the core concepts, artifacts, and techniques of the SAP EA Methodology. This focus also applies to the SAP EA professional certification.

   However, single units or regions can also define extensions with additionally needed concepts, artifacts, and techniques.

   Based on the usage, the achieved value, and the collected feedback, such extensions might become part of the core methodology.

   Similarly, the other way around, concepts, artifacts, and techniques that show poor adoption or constantly unfavorable feedback might be moved from the core methodology to an extension and finally deprecated.

4. Mapping to Other Architecture Disciplines and Contexts

   Enterprise Architecture is one of many architecture disciplines. It does not govern other architecture disciplines or dictate the application, data, technology, or other architecture.

   Additionally, Enterprise Architecture should not act as an isolated exercise. Constructive collaboration with other disciplines is a prerequisite for relevance and effectiveness.

   Enterprise architects require collaboration with other architects and the knowledge of other practitioners to link business and IT effectively.

Only through this collaboration can Enterprise Architecture effectively influence the implementation of IT landscapes.

There are various areas of architecture interest:

• Enterprise Architecture
• Integration Architecture
• System Landscape Architecture
• Data Architecture

Each expert group has their own agreed languages. They have specific concepts and models that describe the relevant aspects in their bounded architecture context.

The SAP EA Methodology does not strive for a monolithic, over-complex architecture meta-model that comprehensively covers all architecture disciplines. Instead, we follow a Domain Driven Design approach.

Exploring the Graphic:

The "T-shaped" colored symbols represents architecture disciplines or contexts.

Every architecture discipline has its own, specific aspects and models.

Assume the blue propeller in the middle represents Enterprise Architecture (EA).

With some other architecture disciplines, we agree to share concepts and catalogs of entities:

We have a common, shared kernel with the other discipline.

An agreement for a shared kernel requires a common vocabulary, content management, and content change management.

In addition, we can have related concepts that we don't manage together in a shared kernel. For these concepts, we only map the related instances.

Overall, this domain-driven design approach facilitates different architecture groups to work consistently but to a large degree independently from each other, with manageable scopes. It consistently follows our collaborative way of working.

The SAP EA Methodology primarily supports Enterprise Architects, Business Architects, Solution Architects, and anyone responsible for an architecture function. That also applies to Integration Architects, Data Architects, or IT Architect roles.

Furthermore, the SAP EA Methodology also supports experts responsible for Product Management functions.

An Enterprise Architect covers Business, Solution, and Technology Architecture. The Enterprise Architect owns the holistic view of the interactions and dependencies between business, organization, and supporting IT solutions.

Business Architects focus on business goals and objectives and subsequent decisions, organizational and operational structure, business-oriented requirement engineering, and management.

Solution Architects own a holistic view of the interactions and dependencies between business and supporting IT regarding a specific solution, thus addressing a distinct scope:

The Solution Architect is a subject matter expert and is responsible for all architecture domains but related to the scope of a specific solution.

IT Architects can cover Solution Architecture (including Application Architecture, Data Architecture), Technology Architecture, and other domains such as Integration Architecture while only slightly addressing Business Architecture aspects.

The architecture roles and personas presented as examples have been extracted from the Disciplines & Roles definition in MEE Customer Advisory. Product Management

Additionally, "Portfolio Management," "Product Positioning and Product Definition," or "Product Requirement Engineering" can also benefit from the SAP EA Methodology. Therefore, it is also interesting for experts in Product Management roles.

The SAP EA Methodology is the basis for creating Reference Architecture Content from SAP, which is another pillar of the SAP Enterprise Architecture Framework, next to the SAP EA Methodology.

Currently next to the Reference Business Architecture (RBA) from SAP , there is SAP Reference Solution Architecture Content (RSA).

Exploring the Graphic: Reference Architecture Content from SAP

The T-Model shown in the figure explains the scope of the RBA, the High-Level RSA, and the detailed RSA. The Business Architecture Scope is depicted on the horizontal axis.

Both the High-level RSA and the detailed RSA are related to Reference Business Architecture from SAP.

The high-level RSA covers a broad business architecture scope and mainly positions SAP Solution Components and Solution Capabilities. It typically uses the work products or artifacts "Solution Value Flow Diagrams" and "Product Maps."

The detailed RSA typically also adds Solution Component Diagrams with Communication Channels, detailed Solution Process Flows, and Data Flow Diagrams. It also emphasizes integration topics.

It covers all artifacts of the Technology Guideline "Industry Reference Architecture" and, therefore, a deeper Solution Architecture Scope.

Detailed RSA has been created so far only for selected scenarios and addresses a smaller Business Architecture scope.