Defining Business Architecture

The SAP Enterprise Architecture Methodology – a methodology aligned with the TOGAF standard and tailored to the SAP Reference Architecture

The SAP Enterprise Architecture Methodology has evolved from the formerly known Industry Reference Architecture (IndRA) framework, an SAP internal project.

It provides a comprehensive approach used bySAP and customers to systematically map IT Solutions to business needs. Internally SAP uses the framework to build enterprise architecture content. Customers apply the framework to define their desired future business scope and desired target architecture.

The recommendation for our customers is to follow a phased approach. It can be used by any enterprise to find the IT Solutions that meet their business need. Same holds true also for SAP's own IT.

This approach is in line with the TOGAF® standard from The Open Group, a proven EA methodology used by the world’s leading organizations to improve their business efficiency.

The TOGAF Architecture Development Method (ADM) cycle is the result of continuous contributions from a large number of architecture practitioners. It describes a method for developing and managing the lifecycle of an Enterprise Architecture.

The ADM is highly iterative: Within phases, between phase, between cycles, stakeholder reviews after the phases.

The SAP Enterprise Architecture Methodology - MetroMap outlines

• The full set of architecture artifacts (recommended and optional)
• Input from the SAP Reference Architecture to define the target architecture both in terms of business and IT domains
• References to existing architecture work products such as principles, standards and guidelines as well as existing baseline business and solution architectures

The selection of artifacts again very much depends on the nature of the architecture project and the stakeholders involved. These should be selected for the sake of the stakeholders (not for the sake of architecture).

Please note that there will be iterations within and across the individual phases (the intention of the visualization is not to give the impression of a waterfall-based approach).

Business Architecture is a representation of holistic, multi-dimensional business views of: capabilities, end-to-end value delivery, information, and organizational structure; and the relationships among these business views and strategies, products, policies, initiatives, and stakeholders.

Business Architecture relates business elements to business goals and elements of other domains.

A knowledge of the Business Architecture is a prerequisite for architecture work in any other domain (Data, Application, Technology), and is therefore the first architecture activity that needs to be undertaken, if not catered for already in other organizational processes (enterprise planning, strategic business planning, business process re-engineering, etc.).

In practical terms, the Business Architecture is also often necessary as a means of demonstrating the business value of subsequent architecture work to key stakeholders, and the return on investment to those stakeholders from supporting and participating in the subsequent work.

The scope of work in Phase B is primarily determined by the Architecture Vision as set out in Phase A. The business strategy defines the goals and drivers and metrics for success, but not necessarily how to get there. That is the role of the Business Architecture

This will depend to a large extent on the enterprise environment. In some cases, key elements of the Business Architecture may be done in other activities; for example, the enterprise mission, vision, strategy, and goals may be documented as part of some wider business strategy or enterprise planning activity that has its own lifecycle within the enterprise.

In such cases, there may be a need to verify and update the currently documented business strategy and plans, and/or to bridge between high-level business drivers, business strategy, and goals on the one hand, and the specific business requirements that are relevant to this architecture development effort.

In other cases, little or no Business Architecture work may have been done to date. In such cases, there will be a need for the architecture team to research, verify, and gain buy-in to the key business objectives and processes that the architecture is to support. This may be done as a free-standing exercise, either preceding architecture development, or as part of Phase A.

In both of these cases, the business scenarios technique (see the TOGAF® Series Guide: Business Scenarios), or any other method that illuminates the key business requirements and indicates the implied technical requirements for IT architecture, may be used.

A key objective is to re-use existing material as much as possible. In architecturally more mature environments, there will be existing Architecture Definitions, which (hopefully) will have been maintained since the last architecture development cycle. Where Architecture Descriptions exist, these can be used as a starting point, and verified and updated if necessary

Gather and analyze only that information that allows informed decisions to be made relevant to the scope of this architecture effort. If this effort is focused on the definition of (possibly new) business processes, then Phase B will necessarily involve a lot of detailed work. If the focus is more on the Target Architectures in other domains (data/information, application systems, infrastructure) to support an essentially existing Business Architecture, then it is important to build a complete picture in Phase B without going into unnecessary detail.

There is a variety of content sources for the artifacts created in the Business Architecture phase. The above provided overview lists the recommended information sources

A variety of source exists to "fill" the Business Architecture artifacts with content. Every company has a business architecture although it is often not holistically and formally documented. Depending on the artifact in scope different sources and existing documentation will need to be consulted.

During the Business Architecture phase multiple artifacts are created to provide a holistic understanding of the Business Architecture in scope. The artifacts range from organization and business role specific viewpoints to business capabilities, processes and information.

Many ways lead to Rome as commonly known – this is not different with the definition of the business architecture as well as the related solution architecture in a specific customer context. Based on the insights gained across multiple transformation programs, we can generally differentiate two district approaches:

• Capability centric approach
• Process centric approach

The capability centric approach (focus on the WHAT) – in this approach business capabilities are used as the anker point to identify areas of improvement (higher level of maturity) or gaps addressing the business requirements in support of the business strategy. Business capability maps are created and with the help of heatmapping exercises areas of concern / action are getting identified. The SAP Business Reference Architecture supports the "translation" of the business capabilities in scope into solution capabilities with underlying applications and components.

The process centric approach (focus on the HOW) – for organizations thinking along processes the process centric approach is the commonly used way forward. With the help of value flows and business process models on various level of granularity, areas of improvements, gaps etc., are getting identified. The SAP Business Reference Architecture supports the "translation" of the business processes in scope into solution process models with underlying applications and components.

On the reference Business Architecture side:

The business capability model consists of the business domain, the business area and the business capability. The business capability is describing what the organization need to know to generate value, independent of how software or technology may support it.

Each business capability is assigned to one business area, and consequently to one business domain..

The business process model consists of end-to-end business processes, business process modules, business process segments, and business activities. Business activities are associated to business capabilities, and describe the how an organization creates value and achieves an outcome by performing a series of steps.

On the reference Solution Architecture side, Solution Capabilities are used to describe a functional ability of a single or multiple software components, that addresses and supports a Business Capability.

Being a technology and solution provider SAP has the answer to "a how" when it comes to how technology supports the business to drive value to the organization.

The linkage between business and Solution Architectures is what organizations are really looking for. It helps to answer critical questions, such as which stakeholders or which division of business units could be impacted or involved; what are the strategy and objectives the organization should try to accomplish, and how that refers to requirements, processes, and ultimately to the integration and data that is sitting within business applications.

Independent of the approach chosen, it is strongly recommend to run the architecture work in iterations (as also foreseen by the TOGAF ADM). A combination of different approaches has been proven as a best practice.

The organization map provides an understanding of which business units to involve in the architecture effort, who and when to talk about a given requirement, and how to measure the impact of various decisions.

An organization map shows the key organizational units, partners, and stakeholder groups that make up the enterprise ecosystem. The map should also depict the working relationship between those entities, as distinct from an organizational chart that only shows hierarchical reporting relationships. The map is typically depicted as a network or web of relationships and interactions between the various business entities (see Organigraphs: Drawing How Companies Really Work, by Mintzberg and Van der Heyden, 1999).

The business unit is the main concept used to establish organization maps. In keeping with the relatively unconstrained view of what constitutes as enterprise, the enterprise may be one business unit for the project underway, may include all business units, or also include third parties or other stakeholder groups. The interpretation depends on the scope of the architecture effort.

This map is a key element of Business Architecture because it provides the organizational context for the whole Enterprise Architecture effort. While capability mapping exposes what a business does and value stream mapping exposes how it delivers value to specific stakeholders, the organization map identities the business units or third parties that possess or use those capabilities and which participate in the value streams.

Business roles and personas in context of the architecture change are identified and outlined in terms of graphical representations or catalogues.

The given example outlines different internal and external business roles interacting with the target solution.

Each organization has it’s existing business capabilities although these are not necessarily document. Best practice is to use a reference business capability model to speed up the work. Business capability maps are created in cooperation with the business. As the business is the owner of the business capabilities the naming of the business capabilities should resonate with the business

Heat mapping of business capabilities is a power method to engage with business stakeholders. Any kind of heat mapping can be applied – make sure that the context is clear e.g. fit-gap, pain/gains, portfolio investment etc.

Visualization of the organization’s business capabilities will provide an important viewpoint on the business architecture. Drill down into lower levels can be achieved through tool support.

• Helps gaining visibility on the as-is and to-be operating model of an organization.
• Helps aligning Business and IT priorities by ensuring business-critical priorities are addressed in the IT Architecture and roadmap design.
• Helps identify the potential areas of investment with maximum impact on strategic goals.

Business Capabilities describe the organization’s ability to successfully perform business activities, thereby achieving its business objectives and delivering value to its customers.​ A capability constitutes "a particular ability or capacity that a business may possess or exchange to achieve a specific purpose or outcome". Business capabilities are the core of the business architecture because they define "what" the business does​ to generate value independent from how software supports it.​​​​​​​​​​​​​​

Business Capabilities are classified around four Enterprise Domains - Products and Services, Customer, Supply and Corporate.

A Business Capability Model is a multi-level hierarchy of Business Capabilities.

It organizes the complete set of Business Capabilities an organization may require to successfully fulfill its mission, reach its strategic objectives, and execute its business model.

It observes the "mutually exclusive and collectively exhaustive" (MECE) principle.

A Business Capability Map is a visualization or diagram of an Business Capability Model.

SAP Reference Business Architecture defines Business Capabilities in a BCM with three levels of granularity, using the following names:

• Level 1: Business Domain
• Level 2: Business Area
• Level 3: Business Capability

Business Capabilities are hierarchically structured along 3 levels:

• Level 1: Business Areas are grouped into Business Domains
• Level 2: Business capabilities are grouped into Business Areas
• Level 3: The third level represents the Business Capability

• Derive the relevant Business Capabilities via the Enterprise Domain of the SAP Reference Business Architecture – reuse as much as possible reference content; consider to reuse other industry reference capability models if necessary
• Focus on relevant Business Capabilities for a given customer context with the help of the artifacts created as part of the Architecture Vision phase – starting point could be the Business Model Canvas or Solution Context
• Review and adjust Business Capability Map with key stakeholders; add Business Capabilities in case these are missing. Feel free to change names of Business Capabilities (business has to own the Business Capabilities and should therefore reflect business acumen)
• Optional: derive a first product map

The given example outlines the business capabilities on multiple levels (L1-L3) and classifies the business capabilities in terms of pain point, opportunity and in scope

Business Capability Heat Mapping is a powerful technique to gain insights into a specific context. This can range from strategic assessments over maturity levels to e.g. pain points.

Make sure that the color coding is well articulated and undoubtedly understood in a given context.

Clearly define the context in which the Business Capability Heat Mapping will take place e.g. in context of a new business model, maturity of capabilities, pains, gains etc.

Define and agree upon the color coding scale e.g. time horizon, t-shirt sizes, maturity levels, priority, classification (opportunity/pain point/to-be-decided/out of scope/in scope) etc.

Conduct the heat mapping exercise: This should happen with the stakeholders in charge / owning the business capability.

Derive (first) interpretation of the results: summarize the key takeaway and insights gained with the help of the heat mapping – outline possible dependencies.

This example shows a Business Capability Map as heatmap visualizing the strategic importance of Business Capabilities (on level 3).

Objective of this heatmap is to answer the question: "What is the strategic importance of individual business capabilities classified by commodity, differentiation and innovation?"

Insights will lead to e.g. investment decision in context of specific business capabilities.

A Business Value Flow is the combination of value-adding business activities to fulfill a defined business goal and create a valuable result for a stakeholder.

In the SAP EA Methodology, Business Value Flows describe Business Processes from a value perspective.

Business Processes belong to the Business Architecture Domain. The SAP Reference Business Architecture provides a system of Business Processes independent from their concrete realization in IT.

In the Solution Architecture Domain, Solution Processes and SAP Solution Components address the needs of Business Processes

Starting point of the business process modeling is the value flow identification. In case values flows have not been document within an organization, reference models should be used as a best practice. Make sure that the context of this work (architecture scope) is clear.

Once the value flows are identified, the further breakdown into modules, segments and activities can be accomplished on a per need basis. Reference models can help to speed up work.

Visualization is key to get engaged with business stakeholders. Business process models need to stay updated to gain the trust of the "consumers"

• Helps gaining visibility on the as-is and to-be operating model of an organization.
• Helps aligning Business and IT priorities by ensuring business critical priorities are addressed in the IT Architecture and roadmap design.
• Helps identify the potential areas of investment with maximum impact on strategic goals.

Take an solution agnostic end-to-end perspective of the business model in scope and identify the relevant value flows.

A dedicated business model or the architecture scope of work is taken here as the context to identify relevant value flow elements.

Complement the value flows in case the reference content is not covering the area of interest.

Other industry value flows might complement the SAP reference content.

Complete the value flow analysis be visualizing the value generating areas.

Highlight the areas of interest and further more detailed investigation (break down of business process model).

With the help of the Business Reference Architecture the «navigation» between different levels of the Business Process Model is easily achieved. Aim is not to define and outline a holistic business process model but rather concentrate on the processes relevant for the architecture work.

The Business Process Model is based on the Process Classification Framework (PCF) version 7.2.1 from American Productivity and Quality Center (APQC).​​​​​​​​​​​​​​

APQC offers many industry specific variants of their PCF.

You find the APQC reference in our Business Process Models on the Business Activity level.

• Level 1: A E2E Business Process is composed of multiple Business Process Modules. A Generic E2E Business Process covers all aspects of a so-called PCDA cycle (plan/do/check/act) and also includes pervasive ‘management’ activities that don’t fit within a specific process sequence. They therefore start with a module ‘ Plan to Optimize…’, followed by modules covering the execution (or action), and end with a process module ‘Manage …’ for pervasive management type activities.
• Level 2: Business process segments are combined to Business Process Modules. The name of a business process module follows the nomenclature <A to B> with A representing the starting point of the process and B representing the end point of the process. Exception are process modules titled as <Manage ..> as these contain activities which are pervasive and not typically sequenced along a process.
• Level 3: Business activities are composed into Business Process Segments. The name of a business process segment usually corresponds to a Business Area in the Business Capability Model (note: we used same name to create synergy between the two models but they are different objects).

• Level 4: The lowest level 4 represents the Business Activity (value creating step). All business activities are defined in ONE central Business Activity Repository.

• Level 1: A E2E Business Process is composed of multiple Business Process Modules. A Generic E2E Business Process covers all aspects of a so-called PCDA cycle (plan/do/check/act) and also includes pervasive ‘management’ activities that don’t fit within a specific process sequence. They therefore start with a module ‘ Plan to Optimize…’, followed by modules covering the execution (or action), and end with a process module ‘Manage …’ for pervasive management type activities.
• Level 2: Business process segments are combined to Business Process Modules. The name of a business process module follows the nomenclature <A to B> with A representing the starting point of the process and B representing the end point of the process. Exception are process modules titled as <Manage ..> as these contain activities which are pervasive and not typically sequenced along a process.
• Level 3: Business activities are composed into Business Process Segments. The name of a business process segment usually corresponds to a Business Area in the Business Capability Model (note: we used same name to create synergy between the two models but they are different objects).

• Level 4: The lowest level 4 represents the Business Activity (value creating step). All business activities are defined in ONE central Business Activity Repository.

Beside the generic business process model, industry specific process variants are part of the SAP Business Reference Architecture.

​​​​​​​​​​​​​​​​​​​​​​​​​​​​​​​​​​​​​​​​​​In general a Business Process describes asset of value-generating business activities, which reflect a specific business practice and can be implemented by enterprises to generate a specific outcome. Different from a generic Business Process, a Business Process Variant reflects an implementable and executable process and is typically composed of elements from one or multiple generic Business Processes. Business Processes are also structured along the above mentioned four levels, with the business activity as the lowest level (note: each business activity must always refer to a business activity in the SAP Business Activity Repository; name changes are allowed to reflect a specific practice, industry or use case but the inherent meaning / purpose of an activity must not be changed).

The SAP Reference Business Architecture offers the unique viewpoint of relationships between Business Activities and Business Capabilities as defined by the meta model.

The Business Footprint Diagram is a x-ray like visualization of goals and objectives to applications and technologies with the help of business capabilities. It is a powerful artifact for the communication with stakeholder to outline the relationship and interdependencies between the different domains.

Business Footprint Diagram defines a cross-domain architectural view for a specific solution for integrating business, solution and technology architecture domains. The purpose of a Business Footprint Diagram is a visual representation that aligns strategic business objectives with underlying business and IT operation model (business capabilities and related solution and technology components) within a specific organizational context.

Prerequisites for composing Business Footprint Diagram

• High quality data for presenting entities and their relationships & internal associations
• Tool for end userto select diagram viewing context (scope) and automatically populate EAM metamodel associations and other relevant dependencies

Definition of scope and storyline: The business footprint diagram is a powerful artifact to convey the message of a strategic intent and how this will be supported by technology. It is therefore crucial to define a precise scope and to define a resonating story line

Selection of relevant entities: As the business footprint diagram is like a x-ray crossing multiple architecture domains, a subset of entities/objects needs to be selected relevant for the story line (goal, objective, capability, application, technology).

Visualization of dependencies: Visualization of the entities/objects and the relationship to each other is of crucial importance to convey the story line

Business Footprint Diagram typically shows:

• Organization Units explaining the scope of architecture design
• Strategic Goals and/or Objectives (value drivers) of the organization
• Business Processes required by stakeholders
• Business Capabilities required by stakeholders
• Solution Components
• Required Technology Capabilities describe resources that support the overall technology environment
• Locations describing the geographical operating location of the software

Domain Layers which can be chosen at discretion, BUT must adhere to established top-down hierarchical relationships.

The Business Information Views provides the "big picture" on Business Information Objects in a given business context. It helps to gain a holistic understanding of the semantics of a information model.

In a given architecture context, key business information models need to be understood to allow accurate, timely, and relevant information for good decision-making and innovation.

The broader picture of an Information Map is build by defining the relationships between different business information entities as well as the relationship to business capabilities, processes etc.

Visualization is key to get engaged with business stakeholders.

Information plays an increasingly important role in successful businesses. Accurate, timely, and relevant information is crucial for good decision-making and innovation. Knowledge results from the ability to apply information in a particular way to solve a problem or create value. It is therefore necessary for architects to understand what information matters most to a business before developing or proposing solutions. An Information Map provides a framework to give rise to that understanding.

In Business Architecture terms, information is considered to be an intangible, conceptual representation of things that exist in the real world. "Information concepts" are the basis for the architectural elements that are used to make those intangible things explicit. Importantly, information concepts are used to model a business rather than an IT system. Defining the core information concepts that support a particular enterprise provides the core of the Information Mapping view in Business Architecture, which then enables characterization of relationships to other Business Architecture concepts such as business capabilities and value streams.

Information Mapping provides the architect with a means to articulate, characterize, and visually represent the information that is critical to the business, and to shape its representation in ways that enable a more detailed analysis of how the business operates today – or how it should operate at some point in the future.

Business Information Models can be retrieved via multiple routes:

• Via identified business processes and capabilities
• Via business entities in the SAP One Domain Model (https://api.sap.com/sap-one-domain-model)

For the sake of completeness missing business entities need to be identified (if architecturally relevant)

Insights into the Business Data Model and relationships are of crucial importance to understand potential implication on integration, mapping requirements as well as the potential need for semantical alignment.