Defining Technology 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 by SAP 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 - Metro Map outlines the following:

• 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).

The evolution of new technologies is a major driver for change in enterprises looking for new innovative ways of operating and improving their business. The Technology Architecture needs to capture the transformation opportunities available to the enterprise through the adoption of new technology.

While the Enterprise Architecture is led by business concerns, drivers for change are often found within evolving technology capabilities. As more digital innovations reach the market, stakeholders need to both anticipate and be open to technology-driven change. Part of Digital Transformation has arisen due to the convergence of telecommunications and computer capabilities which have opened up new ways of implementing infrastructures.

Solution development methods are also evolving to challenge traditional development methods and are putting pressure on the shared services and common use benefits of the traditional Enterprise Architecture approach. Without a strong Enterprise Architecture approach, the rapid adoption of changing technologies will cause discontinuities across the enterprise.

The flexibility of the TOGAF ADM enables technology change to become a driver and strategic resource rather than a recipient of Change Requests. As a result, the Technology Architecture may both drive business capabilities and respond to information system requirements at the same time.

Specifically, the Technology Architecture describes the technology stack, physical computing environment and required network connectivity that enable the Application and Data Architecture Solution Building Blocks. Examples are the dedicated selection of virtual computing environments (for example, container-based), the availability in selected data center locations and the connectivity from office locations to the data centers where the Solution Application Components are operated.

The objectives of this phase are as follows:

• Develop the Target Technology Architecture that enables the Architecture Vision, target business, data, and application building blocks to be delivered through technology components and technology services, in a way that addresses the Statement of Architecture Work and stakeholder concerns
• Identify candidate Architecture Roadmap components based upon gaps between the Baseline and Target Technology Architectures

There are a variety of content sources for the artifacts created in the Technology Architecture phase. The above images provides you with an overview that lists the recommended information sources.

• Link to SAP Trust Center: https://www.sap.com/germany/about/trust-center.html

• Link to SAP Discovery Center: https://discovery-center.cloud.sap/serviceCatalog?regions=all&%20provider=all

The following image outlines the deployment/landscape of the Technology Architecture. It describes the functions of the Software Distribution Diagram and the Environments and Location Diagram.

The Environments and Location Diagram shows you the Solution Building Blocks that are deployed and operated in which data center location as well as the required physical connections between the Solution Building Blocks.

The physical locations of the users and other external systems that need to interact with the Solution Components must also be considered (see Context Diagram in Architecture Vision) . This also visualizes which data is exchanged over public lines and where VPN security capabilities need to be added.

The following image shows you which of your architecture building blocks and solution building blocks are deployed at which locations. You can also outline different deployment environments such as development, test, and production.

Software Distribution Diagram

Pick up the previously created Software Distribution Diagram and evolve it into the Environments and Location Diagram.

Deployment Environments and Locations

Identify the deployment environments in which your Solution Building Blocks are running. Add more details to the "landing zones" of the Software Distribution Diagram by explicitly naming the data center providers, the data center location and infrastructure specific details per "landing zone".

Map the identified solution building blocks to the deployment environments.

Data Flow and required connectivity

Visualize the relationships of type request-response or information flow between the Solution Building Blocks. This helps to understand network requirements.

The following template can be used to create an Environment and Location Diagram.

The following image provides you with an outline, which is an example of an Environments and Location Diagram.

Two typical decisions that need to be also taken during the Technology Architecture phase are the decisions about the Instance Strategy and the SAP System Landscape Model. These are not standard artifacts but important architecture decisions which must be documented.

The Instance Strategy defines how many production systems will be needed per application: a single instance, systems by region or systems by business sector.

The following image provides you with an overview of the terminology related to SAP Instance.

SAP Landscape (Logical instance):

A collection of SAP environments that is used for a common release. For example, production support landscape or project landscape.

SAP Environment:

This is a collection of SAP Instances that is used for a common purpose - for example, Development, QA/Testing, or production environment. Other types can be Training, Pre-Prod/Staging, and Sandbox.

SAP Instance:

This is a single SAP instance of a given component with a specific role - for example, DEV or PRD residing on a separate hardware or partition.

SAP Client:

SAP Client is a logical and legally independent organizational entity and has its own set of user data and separate master records. For more details, see the following material.

The types of data in a client are as follows:

• Master Data: Data that remains unchanged over a long period of time. Master data contains information that is needed again and again in the same way.
• Transactional Data: Data relating to the day-to-day transactions.
• (Client specific) Configuration: Configuration (often referred as customizing) is customizations which are done using the "IMG" or by editing the configuration tables directly.
• Client Independent Configuration: Configuration (often referred as customizing) which is common across multiple clients.

Instance strategy is used to describe typical scenarios, including productive landscape, development landscape and template considerations.

There are different instance strategy approaches with their characteristics:

Independent:

• Harmonized SAP release level
• Completely independent development streams
• Optional informal information and knowledge sharing

Partial Template (Global/Local):

• Global development system for common template settings
• Localization achieved through local development systems
• Clear differentiation between global and local setting required

Full Template - Multiple Production Instances:

• One global development system
• Multiple SIT, PRD systems
• Well organized transport procedures required

Full Template - Single Production Instance:

Globally centralized DEV, SIT and PRD environment

There are seven Instance Strategy patterns. Each of these is presented in the following figures to illustrate the key differences.

The graphical representation in the following figure outlines the elements of the "House" Model that will be used on the following images to explain the seven Instance Strategy patterns.

In the case of single instance, you have benefits on transparency across the whole business, for example:

• Central Control
• Reporting and Integration
• Easier Maintenance
• Harmonization and Standardization

However, you will have constraints in terms of flexibility (for example, in the case of any change requirement, everybody has to talk to everybody), in addition to mentioning the following:

• Global Complexity
• Risk, Performance, Size
• Ownership
• Managing Downtime

In case you want to move towards a single instance, you need to assess the following:

• Globalization Options and Constraints
• Transaction and User Volumes
• Competitive Advantage
• Local Acceptance
• Ability to Implement
• Cultural Issues
• Global network capabilities
• Reliance on admin, maintenance, and testing tools

For all ERP split architecture patterns (divisional, functional, regional), there are benefits from the following:

• Local Freedom of Choice, Time, and Approach which improves speed and agility
• Local Independence
• No Re-engineering Efforts

At the same time, ERP split architectures provide disadvantages in relation to the following:

• Synergy potential
• Redundancy and Incompatibility wrt systems, interfaces
• Redundant Implementation / additional effort in Maintenance
• No global processes

In case you want to move towards a single instance, you need to assess the following:

• Global Costs of Incompatibility
• Global Costs of Implementation and Maintenance

Challenge in this pattern is the coordination across regions by, for example, Product Line or Business Unit:

• How do the business units collaborate across the regions? Are the employees working in three different systems?
• Or are there product lines which are used in a single region anyway?
• Relationship with internal and external customers: directly to the external customers or between the regional systems (for internal customers)? Or via the headquarters system (acting as a commercial layer)

In the pure definition of a regional pattern, there is no shared service instance. However, in praxis, we always see when a regional pattern is in place that there are global instances for global functions.

There is a special topic that is often discussed, and that is if you could have separate SAP S/4HANA systems, one for finance, and one for order fulfillment and manufacturing, which we call here "functional split".

The core of SAP S/4HANA was developed with the purpose of an "all-in-one" usage and one of the main benefits is the tight integration between the logistics modules and the finance modules.

While this setup is technically feasible in SAP S/4HANA, most of these companies who had such a setup perceived this as very suboptimal because it introduces additional reconciliation effort in the business and in IT. So, most of these companies are now moving away from a split architecture.

In the case of a split architecture with a separate finance system, also called Central Finance, the additional efforts and risks for operations are due to the following requirements:

• A "shadow" finance application is needed in the logistics system.
• Postings from the "shadow" finance applications need to be replicated to the core finance system, on total or line item level or with the Central Finance approach.
• Finance master data and configuration have to be continuously synchronized between the two systems or-in the case of Central Finance-mapping rules need to be defined and continuously updated.

High level of standardization does not always deliver maximum benefits. An optimal solution often lies in the middle and not at the extreme ends.

Defining the instance strategy is about finding the "sweet spot" and deciding which from the previously introduced strategies is the best for the customers' SAP solutions.

There is a proven methodology for defining and agreeing in the SAP Instance Strategy:

• Start with clear problem statement that describes the required decision and the way of achieving it. Decision stakeholders are identified.
• Identification of decision alternatives (ideally no more than 3-4) that will be further evaluated out of a given set of all possible alternatives. The alternatives to be evaluated are described and documented.
• Selection criteria are brainstormed then sorted, categorized and weighted.
• Each alternative Instance Strategy option is scored against each criterion, either collaboratively or by individual assessments that are then aggregated.
• Preliminary results are then reviewed as a group and discussed with stakeholders. Winning scenarios are reviewed and validated, and the final decision is documented and communicated, concluding with a clear description of the selected Instance Strategy and the evaluation process.

The 7 typical SAP architecture patterns

Start with the 7 typical architecture patterns introduced before.

Understand the patterns

Make the stakeholders involved familiar with the patterns and foster the understanding of their benefits and challenges. Discuss the stakeholder views on the patterns, considering the company's situation.

Discard least fitting options

Depending on the company's situation, some of the patterns can be quickly excluded. Discard the least fitting instance strategies options.

Shortlist of potential Instance Strategy options

Build a shortlist of the remaining potential Instance Strategy options relevant for the company's situation. The list ideally consists of not more than 3-4 option, which are described and documented for the subsequent evaluation process.

The remaining Instance Strategy options on the shortlist need to be evaluated now in more detail to find the option with the best fit for the company's situation.

Evaluation criteria

Create a catalog of evaluation criteria against which you would like to evaluate and compare the options.

Apply weighting

Some criteria might be more important, and hence be weighted higher than others. Decide on the weight of each criteria considering the company's situation.

Rate each Instance Strategy option against each criterion

Rate each Instancy Strategy option from the shortlist against each criterion.

Evaluation document - recommendation for best fit

Document the evaluation of the comparison and give a recommendation to the decision-making body for the best fit. Prepare all the required documents to take a decision.

Decision

Decision-making body to decide on the Instance Strategy.

Hints and best practices for creating the core artifact:

• This process is an art, not a science - a certain degree of subjectivity is inherent in the process.
• Defining the right set of stakeholders is essential to getting buy-in for the decision.
• A collaborative approach is essential, with a core group of stakeholders participating in multiple face-to-face discussions. Responsible or accountable stakeholders who are remote or unable to participate in all workshops are likely not be properly engaged.
• Take care to define key terms and phrases. It's typical for quite a bit of time to be required for "fleshing out" the meaning of terms and getting all stakeholders on the same page as to the implications and assumptions behind various statements.
• Critical decisions with far-reaching impact such as the SAP Instance Strategy probably cannot be solved in an intensive 3-day workshop. It's often best to allow the process to occur over several weeks, as it allows for more research and fresh thinking.
• Financial considerations can be challenging to include as evaluation criteria, especially if costs associated with each scenario are not fully known. It may be necessary to narrow the options by this process, and make the final decision once the financial implications can be calculated in detail.

To view the whitepaper, choose the following link: https://d.dam.sap.com/a/JAAUmx/WhitePaper_ProductionSystemStrategy_v6_final.pdf

The System Landscape Model enables the following:

• Defines the number of environments to be used
• Defines the roles and usage guidelines of each environment
• Defines the sequence of environments in the transport path (this is integral to the defined roles of each environment)

There are several fundamental system landscape strategies commonly employed by SAP customers. Two of them are presented in the following figures to illustrate the key differences.

Only those environments that are essential to the change / release management approach are included in the following figures. SAP customers often have other environments - for example, Sandbox, Training, Pre-Production Testing but these are not included in the models for sake of simplicity.

System landscape model (as development and configuration staging) is also relevant for SAP Cloud products. The typical approach is first to start with ERP / SAP S/4HANA system because other Cloud-LoBs such as SAP SuccessFactors and CX as well as PaaS Cloud / SAP BTP typically mirror and follow S/4H N-tier landscape.

Each of the approaches presented have benefits and weaknesses. The SAP Architect needs to work collaboratively with Development, Maintenance and Testing teams, Implementation partners, and IT Operations stakeholders (for example, Release Management, Change Management and Support) to agree the most appropriate System Landscape Model for the enterprise situation.

As for the Instance Strategy, this process is an art, not a science - a certain degree of subjectivity is inherent in the process, and getting stakeholder buy-in for the decision is of critical importance.

Key Principles:

• • QA is a reliable predictor of the impact of changes on PRD
  • High commonality of configuration settings and RICEF objects between QA and PRD
  • All configuration and development work enters the landscape through DEV
  • Integrity of transport sequence is maintained
  • QA is periodically refreshed from PRD, and thus tends to have a large production-quality data set
• Primary Limitation
  • Challenge of supporting new projects / rollouts in parallel with production support.
    • Integration testing in QA leaves no environment to properly support PRD.
    • Essentially, there is little/no distinction between projects and production support.

The actual system names vary a lot among SAP customers, and the examples here are just for illustration purposes.

QA is periodically copied from PRD and is roughly the same size.

Other systems such as Sandbox or Training may exist, but these are not a primary part of the transport management process.

Integrity of transport request sequence means:

Order of export from DEV = order of import to QA = order of import to PRD

The Five-System ("N+1") Landscape Model provides the maximum flexibility in a system landscape:

• Net Change from Three-System Model
  • Second DEV environment (for example, "DPS") is added to create a separate DEV/QA pairing for both N and N+1, providing maximum isolation of projects and production support.
• Key Principles:
  • N and N+1 enter the landscape through separate Development environments, and N-based changes are replicated to the N+1 landscape to ensure consistency.
  • N and N+1 have release independence, that is, they do not have to be at the same version/patch levels.
  • The N+1 landscape is assumed to be the primary DEV/QA landscape post-cutover, generally because the volume of changes in N+1 is significantly greater than N.

N+1 changes are brought to QA/PRD eventually, but only at the point of the project's go-live.

• Primary Benefits:
  • Provides for independent governance of N and N+1, and clear segregation of project and production support changes.
  • Maintenance (upgrades, Support Packages) can be readily included in the scope of N+1.
• Primary Limitations:
  • As DEV in the N+1 landscape is assumed to be the primary long-term development environment, all production support changes must be re-entered into it through automated or manual procedures.
  • The SAP transport system is not an ideal mechanism for propagation of these changes.
    • Transports can over-write work in progress in the target system.
    • Solutions in the N+1 environments are not assumed to be at the same version/patch levels as N.

Depending on your installation, your SAP S/4HANA Cloud is based either on a 2-system landscape or on a 3-system landscape.

The image above illustrates the following:

2-System Landscape

The 2-system landscape consists of a quality system and a production system.

Quality system

The quality system combines development, configuration, and testing activities. You can test your custom developments and configurations separately in the quality system before transporting them to the production system.

Production system

The production system is the system in which you work productively with the content provided by SAP and your custom developments from the quality system.

As of September 1, 2022, SAP has made generally available SAP S/4HANA Cloud, 3-system landscape.

The above image illustrates the following:

3-System Landscape

The 3-system landscape consists of a development system, test system, and production system. Development and testing activities are separated into two dedicated systems. This separation makes it possible to have advanced development projects in the 3-system landscape, enabling developer extensibility options.

Configuration content in the 3-system landscape is always provided by SAP Central Business Configuration, which is connected only to the development system.

Development system

The development system provides a safe environment for development projects that include advanced coding projects. The development system is divided up into two tenants with specific purposes: the customizing tenant and the development tenant.

Test system

When you've finalized your development and configuration projects in the development system, you can transport them to the test system. In the test system, you can test both your custom developments and configurations before forwarding them to the production system.

Production system

The production system is the system in which you work productively with the developments that you created and the content that you configured in the development system and tested in the test system.

For further information, see https://help.sap.com/docs/SAP_S4HANA_CLOUD/a630d57fc5004c6383e7a81efee7a8bb/aa60b129af7b4ce8ae052618c8315d29.html

In the Explore phase of the SAP Activate roadmap, the fit-to-standard workshops take part, in which the standard processes of SAP S/4HANA Cloud are reviewed, to determine how they fit with the business requirements. The functionality of SAP S/4HANA Cloud is demonstrated in the starter system, so that one can see how the solution can meet the requirements.

The Starter System includes configuration and master data for your selected cloud solution for targeted enablement of the project team on SAP standard processes and to be host environment of the Fit-to-Standard workshops. It is decommissioned one month after the Production System is delivered.

Within a global account that is on feature set B, you can create up to five levels of directories to further structure your global account according to your business or technical needs. To actually develop and deploy applications, to use services, and to subscribe to business applications provided by SAP, you need to create subaccounts. Directories are optional, but highly recommended as they offer a way to organize your subaccounts and to manage entitlements or users for an entire group of subaccounts. This means you can distribute the resources that are assigned to your global account across directories, and from there to the subaccounts inside a directory. Directories and subaccounts let you structure a global account according to the requirements of your organization and projects with regards to users, authorizations, and quotas.

Account Model Directories per Location

In this account model, you create different directories for geographical areas. Additionally, for example, you can add labels to subaccounts that belong to the same departments in those locations. Alternatively, you could nest additional directories inside these ones.

The following example shows a possible BTP Account Model to extend SAP S/4HANA system landscape.

• Mimic leading system landscape of staging
• If leading system f.e. SAP S/4HANA has 3-tier such as DEV, QA and PROD then we have corresponding setup of subaccounts / spaces