Unit 6 Technology Architecture PDF

Technology Architecture SAP 2024 Edition SAP Public 1 Learning objectives This unit outlines…  The development of a Target Technology Architecture that enables the Target Business Architecture, Application and Data Architec...

Technology Architecture SAP 2024 Edition SAP Public 1 Learning objectives This unit outlines…  The development of a Target Technology Architecture that enables the Target Business Architecture, Application and Data Architecture. After completing this unit, you will be able to…  Create an Environments & Location Diagram  Define an Instance Strategy  Define a System Landscape Model  Understand SAP BTP Account Model SAP Publlic 2 2  SAP Enterprise Architecture Methodology Enterprise architecture development process based on TOGAF® ADM with selected artifacts Request for Preliminary: Stakeholder Map Architecture Method Statement of Architecture Work Principles, Work selection & Solution Context adoption Standards, Solution Concept Guidelines Business Strategy Map Business Context Diagram A. Business Model Canvas Architecture Vision H. Organization Map B. Business Roles Catalog Architecture Business Change Business Capability Map Governance Architecture SAP Reference Business Value Flow Diagram Business Business Footprint Diagram Architecture Business Data Catalog G. C. Solution Architecture Diagram(s) Implementation Requirements Application & Application Architecture Overview SAP Reference Governance Management Data Diagram Solution Architecture Software Distribution Diagram Architecture Solution Data Architecture Diagrams Environment & Location Diagram F. D. Migration Technology Architecture Roadmap Planning Architecture Work Breakdown Structure E. Opportunities & Solutions Architecture Vision Business Architecture Technology Architecture Requirements & SAP Publlic Strategy and Motivation Solution Architecture Roadmap & Transition 3 Governance 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, a 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. 3 SAP EA Methodology – Metro Map Request for Architectural Work Preliminary: Method Selection & Adoption to SAP Reference SAP Reference SAP EA Methodology Business Architecture Solution Architecture Business Data Catalog Stakeholder Map Business Organization Business Capability Map Footprint Start Implementation Map Business Value Flow Diagram Diagram Business Strategy Map Business Business Architecture Work Model Canvas Roles Roadmap Breakdown Catalog Structure Solution Software Business Architecture Distribution Context Diagram Diagram(s)* Diagram Environments & Location Diagram Statement of Solution Enterprise Solution Application Architecture Context Transformation Concept Architecture Work Diagram Assessment*** Diagram Overview Diagram Principles, Standards Baseline Business Solution Data and Guidelines and Solution Architecture Architecture Diagram(s)** SAP Reference Solution Architecture Requirements Management * Generic placeholder for selected ** Generic placeholder for *** Enterprise Transformation Architectural Decisions artifacts like: selected artifacts like: Assessment Risk Analysis  Product Map  Solution Component Diagram  Solution Data Flow Diagram  Conceptual Data Diagram  EA Practice Capability Assessment  Preliminary Business and Executive Summary  Solution Value Flow Diagram Technology Capability Assessment  Solution Process Flow Diagram  Business and Technology Architecture Vision Business Architecture Technology Architecture Transformation Readiness SAP Publlic Requirements & Assessment 4 Governance Strategy and Motivation Solution Architecture Roadmap & Transition 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) 4  Technology Architecture SAP Publlic 5 5 Technology Architecture – Purpose & artifacts Purpose  Describes and documents the deployment of your organization’s IT systems including hardware, software, and communications in specific Data Center locations  Develop Target Technology Architecture that enables the Target Business Architecture, Data, and Application Architecture building blocks to be delivered via technology components (e.g. Operating Systems, virtualized environments, Hardware, Networks) Key architectural work product is Target Technology Architecture with these artefacts:  Environments and Locations Diagram: grouping technology components into deployment environments (Data Centers)  Network and Communications Diagram: (e.g. definition of communication lines / VPNs etc.)  Container / virtualization environments  Hardware specifications SAP Publlic 6 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 (e.g. 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. 6 Technology Architecture – Steps Develop the Target Technology Architecture that enables the Target Business Architecture, Application and Data Architecture.  Develop Baseline Technology Architecture Description  Develop Target Technology Architecture Description  Perform Gap Analysis  Define Candidate Roadmap Components  Resolve Impacts Across the Architecture Landscape  Conduct Formal Stakeholder Review  Finalize the Technology Architecture  Create the Architecture Definition Document SAP Publlic 7 The objectives of this phase are to: - 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 7 Technology Architecture – Information sources Recommended content sources:  Environments and Locations Diagram  derived from SAP EA Methodology Solution Data Flow Diagram and Solution Process Flow Diagram  Information about SAP solution and services deployments (e.g. SAP Trust Center, SAP Discovery Center)  Network and Communications Diagram (e.g. definition of communication lines / VPNs etc.)  Information about SAP Cloud solution access (e.g. Cloud Peering), HEC connectivity options (SAP Online Help and Blogs) or e.g. SAP on Azure documentation  Hardware and network specifications (typical for on-Premises scenarios)  See SAP product hardware requirements (SAP Online Help) SAP Publlic 8 There is a variety of content sources for the artifacts created in the Technology Architecture phase. The above provided overview 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? provider=all&regions=all Link to Cloud Peering: https://www.sap.com/germany/services-support/service-offerings/ peering-interconnection.html 8 Technology Architecture (Deployment/ Landscape) Environments and Location Diagram Software Distribution shows where the Diagram shows how selected solution Solution Building components are Blocks are distributed technically installed and across the IT Software deployed, especially on infrastructure (high- Distribution which runtime and in level, e.g. on Premises, Diagram Environments & which physical network Public Cloud or Private Location Diagram environments (Data Cloud) Center specific information) Solution Architecture Technology Architecture SAP Publlic 9 Note: The Software Distribution Diagram belongs to the Application Architecture. However, it provides the input for and may finally lead to the Environment and Location Diagram which provides a much higher level of detail of the Solution Building Blocks from the deployment and operational perspective. Use the Network and Communications Diagram for documentation of network communication lines / VPNs etc.. 9 Technology Architecture – Environments & Location Diagram Environments & Location Diagram Shows the geographical location of solution building blocks and runtime environment specific details SAP Publlic 10 The Environments & Location Diagram shows which Solution Building Blocks are deployed and operated in which data centre 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. 10 Technology Architecture – Environments & Location Diagram Shows 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 Deployment Environments Choose locations Data Flow Pick up the previously created Identify the deployment Choose the geographical Visualize the relationships of Software Distribution Diagram environments in which your locations of the type request-response or and evolve it into the building blocks are running. previously identified information flow between Environments & Location deployment the building blocks. This Diagram. environments. helps to understand network SAP Publlic requirements. 11 Software Distribution Diagram Pick up the previously created Software Distribution Diagram and evolve it into the Environments & 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 11 Environments & Location Diagram - Template Public Internet Legend: Request-response: Information flow from source to target: SAP Publlic 12 Following template can be used to create an Environment & Location Diagram 12 Environments & Location Diagram - Example AWS Data Center – Frankfurt (DE) Public On Premises Data Center Internet (Berlin, DE) SAP Business Technology Platform Cloud SAP S/4HANA Cloud Foundry SAC Connector Service Embedded Global MPLS Workflow Connectivity SAP Web SAP Management Service Dispatcher BW/4HANA Office Locations Identity SAP HANA Authentication Cloud Austin San Francisco (US, TX) (US, CA) Launchpad Business Rules Service Berlin (DE) Tokyo (JP) SAP Publlic 13 The following graphical representation outlines an example of an Environments and Location Diagram. 13 Two typical technology architecture decisions to be taken Instance Strategy SAP System Landscape Model SAP Publlic 14 Two typical decisions which 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 notstandard artefacts but important architecture decisions which must be documented. 14 Technology Architecture – Instance Strategy Instance Strategy defines how many production instances will be needed per application SAP Publlic 15 The Instance Strategy defines how many production systems will be needed per application: a single instance, systems by region or systems by business sector. 15 SAP Instance - Terminology overview SAP Environment: SAP Landscape (Logical instance): A collection of SAP Instances that is used for A collection of SAP environments that is used for a common a common purpose. For example release. For example production support landscape or project Development, QA/Testing or production landscape. environment. Other types can be Training, Pre-Prod/Staging and Sandbox SAP Landscape Development Quality Production S/4 HANA S/4 HANA S/4 HANA 100 100 100 200 xxx SAP Client: SAP Instance: SAP client is a logical and legally independent A single SAP instance of a given component organizational entity and has its own set of user data with a specific role e.g. DEV or PRD residing and separate master records. Details see next page on a separate hardware or partition SAP Publlic 16 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: 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: A single SAP instance of a given component with a specific role e.g. 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. Details see next page 16 SAP Client Concept - Terminology overview SAP Instance Client 100 Client 200 Server Application (Master Application (Master and Transactional and Transactional User Master User Master S/4 HANA Data Data Data Data 100 200 Configuration/ Configuration/ xxx Customizing Customizing Client Independent Configuration SAP Publlic 17 Types of Data in a Client  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. 17 Instance Strategy overview Independent Full Template – Multiple Production Instances DEV SIT SIT PRD PRD Australia Australia Australia Australia Australia DEV SIT PRD SIT PRD Central, Central, Central, DEV Central, Europe, Central, Europe, Europe, APA Europe, APA Europe, APA Global APA APA...................................................................... Partial Template (Global/Local) Full Template – Single Production Instance DEV SIT PRD Europe Europe Europe DEV SIT PRD Global Global Global DEV SIT PRD DEV Central, Africa, Central, Africa, Central, Africa, Global APA APA APA.......................................... SAP Publlic 18 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 18 Seven Instance Strategy Patterns Single Instance Divisional Split Regional Split Functional Split 1 Single Instance 2 Divisional System 4 Regional Systems 7 Process Clusters 1 DEV – 1 PROD Independent Independent N DEV – N PROD N DEV – N PROD Process Cluster 1 BU1 Reg1 Reg3 BU2 Reg2 Process Cluster 2 3 Divisional System 5 Regional Systems Partial Template Partial Template 1 DEV – N DEV – N PROD 1 DEV – N DEV – N PROD Reg1 BU1 Reg2 BU2 Reg3 6 Regional Systems Full Template PROD Productive System 1 DEV – N PROD Reg1 QA Quality System Reg2 DEV Dev System Reg3 SAP Publlic 19 There are seven Instance Strategy patterns. Each of these, is presented in the following slides to illustrate the key differences. 19 Elements of the ‘House’ Model: Instance Strategy Basic Architecture Shapes Central Enterprise Management Functions or “Lines of Business” Strategic Enterprise Planning and Consolidation R&D, Corporate Consolidated Reporting Master Data Management Production Planning, Production Execution, e.g. Headquarters Sales and AR… e.g. Sales e.g. Production Divisions Americas EMEA APJ Business Units / Models Regions Product Portfolio Cluster Projects After Market B2C EMEA e.g. Finance APJ Americas e.g. Payroll Shared services HR Payroll Purchasing and AP SAP Publlic 20 The graphical representation above outlines the elements of the “House” Model which will be used on the following slides to explain the seven Instance Strategy patterns. 20 Single Instance: “all in one” Benefit Challenge Transparency Flexibility e.g. Headquarters Standardization: Global Processes e.g. Sales e.g. Production Americas EMEA APJ Projects After Market B2C e.g. Finance e.g. Payroll SAP Publlic 21 In 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 But you will have constraints in flexibility (for example in case of any change requirement: Everybody has to talk to everybody), in addition to mention  Global Complexity  Risk, Performance, Size  Ownership  Managing Downtime In case you want to move towards a single instance, you need to assess  Globalization Options and Constraints  Transaction & User Volumes  Competitive Advantage  Local Acceptance  Ability to Implement  Cultural Issues  Global network capabilities  Reliance on admin, maintenance, and testing tools 21 Divisional Split: Split by business units / models Benefit Challenge Flexibility for Minor synergies Divisions across Divisions e.g. Headquarters e.g. Headquarters Coordination across Divisions e.g. Sales e.g. Production e.g. Sales e.g. Production Division 1: e.g. Projects Division 2: After Market e.g. Finance e.g. Finance e.g. Payroll e.g. Payroll SAP Publlic 22 For all ERP split architecture patterns (divisional, functional, regional) there are benefits from  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  Synergy potential  Redundancy & 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  Global Costs of Incompatibility  Global Costs of Implementation and Maintenance 22 Regional Split: Split by geographical regions Benefit Challenge Operational Coordination stability across regions Exchange of Performance functions SAP Publlic 23 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. But in praxis we always see when a regional pattern is in place that there are global instances for global functions. 23 Functional Split: Split by process clusters Benefit Challenge Complexity & Flexibility for LoBs interfacing e.g. Headquarters e.g. Headquarters Best of breed from LoB perspective e.g. Sales e.g. Production After Market After Market e.g. Finance e.g. Payroll e.g. Payroll SAP Publlic 24 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 24 Impact of Split Architecture on Governance Centralization vs Decentralization High Sweet “Net” benefits spot Benefits of standardisation and scale Benefits  Transparency  Operational synergies  Information sharing benefits Benefits of local autonomy  No need for excessive group wide coordination Low Autonomy/decentralised/high  Rapid response to business Logical Split SAP High Standardisation/ number of SAP instances needs instances centralised single global SAP instance  Flexibility/local control SAP Publlic 25 High level of standardisation 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. Best Practice to define the Instance Strategy – Part I 7 typical SAP architecture patterns Understand patterns (SWOT) Decide Output: Shortlist of potential Instance Strategy options The remaining Instance Strategy options on the short list need to be evaluated now in more detail to find the option with the best fit for the company's situation SAP Publlic 26 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 via individual assessments which 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 short list 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 short list need to be evaluated now in more detail to find the option with the best fit for the company's situation 26 Best Practice to define the Instance Strategy – Part II Shortlist of Instance Strategy Evaluation criteria options Apply weighting Rate each option from the shortlist against each criterion Evaluation document – recommendation for best fit Decide Result: Instance Strategy SAP Publlic 27 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 & 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 via this process, and make the final decision once the financial implications can be calculated in detail. 27 Whitepaper on Production System Strategy Whitepaper on Production System Strategy SAP Publlic 28 28 Technology Architecture – System Landscape Model SAP System Landscape Model Defines the number of environments to be used SAP Publlic 29 The System Landscape Model:  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). 29 Technology Architecture – System Landscape Model Quality Sandbox Development Staging Production Assurance Training SAP Publlic 30 Approach for defining the System Landscape Model There are several fundamental system landscape strategies commonly employed by SAP customers. Two of them are presented in the following slides to illustrate the key differences. Only those environments that are essential to the change/release management approach are included in the following slides. SAP customers often have other environments e.g. 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 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 (e.g. 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. 30 Technology Architecture - Three-System Landscape Model DEV QA PRD SAP Publlic 31 Three-System Landscape Model, the traditional SAP system landscape model Key Principles  QA is a reliable predictor of the impact of changes on PRD  High commonality of configuration settings & RICEF objects between QA & PRD  All configuration & 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. 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 31 Technology Architecture - Five-System Landscape Model ∆N DPS ∆N QPS ∆N PRD N N N (at cutover) ∆(N+1) DEV ∆(N+1) QA ∆(N+1) N+1 ∆N N+1 ∆N SAP Publlic 32 The Five-System (“N+1”) Landscape Model provides the maximum flexibility in a system landscape Net Change from Three-System Model  Second DEV environment (e.g. “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, i.e. 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  Because 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. 32 SAP S/4HANA Cloud 2-System Landscape Solution Builder SAP Central Business Q(Quality) P(Production) Configuration Change deploy Project Project WorkSpace 100 100 SAP Publlic 33 Depending on your installation, your SAP S/4HANA Cloud is based either on a 2-system landscape or on a 3-system landscape. 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. 33  SAP S/4HANA Cloud – Three-System Landscape and SAP Central Business Configuration SAP Central Business D(Development) T(Test) P(Production) Configuration TransportR Workspace for Deploy Customizing elease Test Tenant Production Configuration Tenant (100) (100) Tenant (100) Backsync Workspace for Development Import Deploy Development Tenant (080) Backsync Forward Import ATO ATO Buffer Buffer SAP Publlic 34 As of September 1, 2022, SAP has made generally available SAP S/4HANA Cloud, 3- system landscape. 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 via 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 Once 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/a630d57fc5004c6383e7a81efee7a8b b/aa60b129af7b4ce8ae052618c8315d29.html 34 SAP S/4HANA Cloud – Three-System Landscape with Starter System SAP Central Business S/4HANA Cloud S/4HANA Cloud S/4HANA Cloud Configuration D(Development) Transport T(Test) P(Production) Deploy Release Workspace for Customizing Tenant Test Tenant Production Configuration Backsync (100) (100) Tenant (100) Deploy Workspace for Development Tenant Development Backsync (080) Import Forward Import ATO ATO Buffer Buffer S/4HANA Cloud Starter WorkSpace Starter Deploy Starter Customizing 100 Tenant (100) Backsync WorkSpace Starter Deploy Starter Development 080 Tenant (080) Backsync SAP Publlic 35 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. 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. 35 SAP Business Technology Platform account model overview Each subaccount holds: SAP Business Technology Platform  Resources that can be consumed by apps  Users allowed to work in the subaccount Global Account  Apps deployed and running in the subaccount  Data written by apps running in the subaccount  Configuration for apps running in the Directory subaccount Each subaccount is assigned to a Global Subaccount account and resides in a Region. SAP Publlic 36 Global Accounts A global account is the realization of a contract you or your company has made with SAP. A global account is used to manage subaccounts, members, entitlements and quotas. You receive entitlements and quotas to use platform resources per global account and then distribute the entitlements and quotas to the subaccount for actual consumption. There are two types of commercial models for global accounts: consumption-based model and subscription-based model. Global accounts are region- and environment-independent. Within a global account, you manage all of your subaccounts, which in turn are specific to one region. Directories Directories allow you to organize and manage your subaccounts according to your technical and business needs. A directory can contain directories and subaccounts to create a hierarchy. Using directories to group other directories and subaccounts is optional - you can still create subaccounts directly under your global account. You can create a hierarchical structure that is 7 levels deep. The highest level of a given path is always the global account and the lowest is a subaccount, which means that you can have up to 5 levels of directories. Directories allow you to: Group and filter directories and subaccounts Monitor usage and costs for contracts that use the consumption-based commercial model In addition, you can also add the following features to your directories (optional): Manage Entitlements: Enables the assignment of a quota for services and applications to the directory from the global account quota for distribution to the directory's subaccounts. When you assign entitlements to a directory, you express the entitlements and maximum quota that can be distributed across its children subaccounts. You also have the option to choose the auto- assignment of a set amount of quota to all subaccounts created or moved to that directory. Subaccounts that are already in the directory when you select that option will not be auto-assigned quota. Manage Authorizations: Enables authorization management for the directory. For example, it allows certain users to manage directory entitlements. You can only use this feature in combination with the Manage Entitlements feature. Subaccounts Subaccounts let you structure a global account according to your organization’s and project’s requirements with regard to members, authorizations, and entitlements. A global account can contain one or more subaccounts in which you deploy applications, use services, and manage your subscriptions. Subaccounts in a global account are independent from each other. This is important to consider with respect to security, member management, data management, data migration, integration, and so on, when you plan your landscape and overall architecture. Each subaccount is associated with a region, which is the physical location where applications, data, or services are hosted. The specific region is relevant when you deploy applications and access the SAP BTP cockpit using the corresponding cockpit URL. The region assigned to your subaccount doesn't have to be directly related to your location. You could be located in the United States, for example, but operate your subaccount in Europe. The entitlements and quotas that have been purchased for a global account have to be assigned to the individual subaccounts. Global accounts and subaccounts are completely independent of user accounts. Relationship between Subaccounts, Orgs, and Spaces When you enable the Cloud Foundry environment in one of your subaccounts, the system automatically creates a Cloud Foundry org for you. The subaccount and the org have a 1:1 relationship and the same navigation level in the cockpit (even though they may have different names). You can create spaces within that Cloud Foundry org. Spaces let you further break down your account model and use services and functions in the Cloud Foundry environment. Regions You can deploy applications in different regions. Each region represents a geographical location (for example, Europe, US East) where applications, data, or services are hosted. Regions are provided either by SAP or by our Infrastructure-as-a-Service (IaaS) partners Amazon Web Services (AWS), Microsoft Azure, Google Cloud, and Alibaba Cloud. The third-party region providers operate the infrastructure layer of the regions, whereas SAP operates the platform layer and Cloud Foundry. A region is chosen at the subaccount level. For each subaccount, you select exactly one region (that is one data center). Selecting a Region When deciding on the location of your Platform as a Service (PaaS), consider existing Software as a Service (SaaS) and Infrastructure as a Service (IaaS) and try to locate it close to those or even in the same data center. You can also optimize application performance (response time, latency) by selecting a region that's geographically close to your users. However, the selection of a region is also dependent on many other factors: First, check the availability of specific services in the individual regions. Second, ensure that you comply with security requirements, such as country- or industry-specific data privacy regulations. And third, consider the location of other cloud offerings you’re using. You might have to locate your solutions in the same data center. Setting Up Your Account Model The hierarchical structure between global accounts, directories, and subaccounts lets you define an account model that accurately fits your business and development needs. Once you've signed your commercial contract with SAP, you'll receive access information and credentials for your global account. Use this account to manage the resources and entitlements for your development projects; it's the realization of your commercial contract with SAP. You'll also receive a bill for all resources used in your global account. If you require multiple global accounts for compliance or other reasons, you'll need to sign a dedicated contract for each one. Note: SAP is currently migrating all global accounts from cloud management tools feature set A to the renovated cloud management tools feature set B. We’re doing this migration as a phased rollout, which is why cloud management tools feature sets A and B currently coexist. One big change that came with feature set B is a renovated account model: With feature set B, you can use directories to group and manage subaccounts inside your global account. For more information, see Cloud Management Tools - Feature Set Overview. Please make sure to understand if your global account is already on feature set B. 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. 36 SAP Business Technology Platform Landscape Model Using subaccounts to create a staged development environment Global Account Subaccount for DEV Subaccount for TEST Subaccount for PROD Apps Apps Apps Services Services Services Connectivity Connectivity Connectivity And more And more And more Recommendation In general, we recommend that you create at least three subaccounts to set up a staged development environment, including one subaccount each for development, testing, and production. SAP Publlic 37 Using Subaccounts to Create a Staged Development Environment The number of subaccounts you create, and for which purpose, depends on your organizational setup and your use case. Recommendation: In general, we recommend that you create at least three subaccounts to set up a staged development environment, including one subaccount each for development, testing, and production. Development – for development purposes and for testing individual increments in the cloud. Testing – for integration testing and testing in production-like environment prior to making it publicly available, to ensure quality delivery. In highly DevOps-driven companies, this subaccount is also used for production applications, as testing occurs in the development subaccount. Production – for production applications. Considerations For Creating Your Account Model Although we recommend that you use subaccounts to create a staged development environment, you can also create subaccounts to do the following: Note: If your global account is on feature set B, you can use directories to further structure your global account Separate development scenarios and projects to allow for easier configuration, for example, with regard to access restrictions. Separate the work of different development teams. Restrict access to applications and their administration, for example, by setting up "high-security" subaccounts with restricted access, or creating separate subaccounts to connect with your different back-end systems. Share an SAP HANA database in one subaccount with similar projects managed in other subaccounts Recommendation: We recommend to build an account structure that can easily scale once your organization gets larger or more projects are added. To start off with one subaccount per development stage (feature set A) or one directory that includes these three subaccounts (feature set B) and create more such subaccounts and directories, respectively, as the need arises. Keep in mind the following considerations when creating different subaccounts: Connections to on-premise systems must be made separately for each subaccount, which also means more work for your Cloud Administration Team. However, it might be easier for you to shut down all integration paths for a project if you've maintained them all in one subaccount. This also lets you control which application uses which on-premise connections. When choosing a region for your subaccount, consider that the region should be close to your customers' geographic location to reduce network latency. In extension scenarios, choose a region that's close to the systems involved. Also, consider any legal requirements and the load distribution when choosing a region. If your S/4HANA tenants need to be segregated for legal or regulatory reasons ( e.g. for the segregation of subsidiaries of a company), then you should use different subaccounts for their extensions. If the DevOps or operations teams for applications within one subaccount are completely separate, you should consider creating separate subaccounts for them for better maintainability. Special Considerations for the Cloud Foundry Environment When you enable the Cloud Foundry environment in one of your subaccounts, the system automatically creates a Cloud Foundry org for you. The subaccount and the org have a 1:1 relationship and the same navigation level in the cockpit (even though they may have different names). You can create spaces within that Cloud Foundry org. Spaces let you further break down your account model and use services and functions in the Cloud Foundry environment. You can use both subaccounts and spaces to develop applications and to use services. You must therefore decide, for example, whether to create different subaccounts or spaces within one subaccount to set up a staged development environment. Consider the following: Think of a subaccount as a tenant: Data access and data visibility segregation is done on subaccount level, not on application or Cloud Foundry space level. Keep in mind that services that are consumed by every app within a subaccount will gather messages from all of these services. If those should not be visible across applications, you need to create different subaccounts. In general, we recommend that you create different subaccounts for a staged development environment, as shown below. This allows for dedicated user management between the different stages, as well as for dedicated data management in elastic services, such as SAP IoT Application Enablement. You can then create a dedicated space for each application, extension, solution, or other project within these subaccounts if you don't need a dedicated user management for these applications and projects. You can monitor the consumption of resources in your global account only per subaccount, directory, or Cloud Foundry space. Not per application. To monitor the resources consumed by a specific project, department, or application, create a dedicated subaccount, directory, or space for them. Accurate billing is only possible for global accounts. For the consumption-based model, you can calculate costs according to usage, but note that this is only approximate. See Monitoring Usage and Consumption Costs in Your Global Account on https://help.sap.com/docs/BTP/65de2977205c403bbc107264b8eccf4b/de6f0db8919f4e6f97e54bc4ddaf2ab8.html Further information and considerations to decide whether to create separate subaccounts or separate spaces within the same subaccount can be found on https://help.sap.com/docs/BTP/df50977d8bfa4c9a8a063ddb37113c43/74eb32ef49804e6e8107338c4ed44d49.html Account Models with Subaccounts The following Account Models show ways to structure your global account into subaccounts. Note that all of them are just examples. They are not mutually exclusive and you can adapt them to your own needs. Once your global account is migrated to cloud management tools, feature set B, you will be able to make use of one more hierarchical level within your global account: with feature set B, you can additionally use directories and custom properties to group subaccounts. For more information, see Cloud Management Tools — Feature Set Overview on https://help.sap.com/docs/BTP/65de2977205c403bbc107264b8eccf4b/caf4e4e23aef4666ad8f125af393dfb2.html and Account Models With Directories and Subaccounts [Feature Set B] on https://help.sap.com/docs/BTP/df50977d8bfa4c9a8a063ddb37113c43/b5a6b58694784d0c9f4ff85f9b7336dd.html 37 Account Model Directories per subsidiary Global Account Directory for subsidiary 1 Subaccount for DEV Subaccount for Test Subaccount for Prod Apps Apps Apps Services Services Services Connectivity Connectivity Connectivity And more And more And more Directory for subsidiary 2 Subaccount for DEV Subaccount for Test Subaccount for Prod Apps Apps Apps Services Services Services Connectivity Connectivity Connectivity And more And more And more SAP Publlic 38 Account Models with Subaccounts The following Account Models show ways to structure your global account into subaccounts. Note that all of them are just examples. They are not mutually exclusive and you can adapt them to your own needs. Account Models With Directories and Subaccounts [Feature Set B] With cloud management tools feature set B, we're introducing a more flexible account structure with directories. Directories Apart from structuring your global account into several subaccounts, you can group individual subaccounts into directories to manage, operate, and analyze such groups of subaccounts together. One global account can contain up to five levels of directories, can contain n subaccounts each. All examples of using directories are based on Using Subaccounts to Create a Staged Development Environment and only use one level of directories. Here are a few example use cases where directories help you manage your subaccounts: Administrative reasons: Structure your global account according to the responsibilities within your organization. For example, give each subsidiary, department, or LOB their own directory. Billing purposes: Structure your global account into directories for accounting purposes. Geographical separation: Group subaccounts based on geographical locations to manage different local regulations or to improve network performance for groups that are located together. Business scenario: Group subaccounts that belong to the same business scenario or according to other business needs. This gives you the option to control each business solution separately. Resource limitations: Use the directory structure to control access to resources, limit usage by generating separate usage and cost reports, or define usage limitations, to give more resources to critical directories, or to enable different monitoring per directory. Or you could structure the subaccounts according to usage limits in different landscapes. Technical reasons: Structure directories and subaccounts according to technical limitation and then add labels for virtual grouping or vice versa. Account Model Directories per Subsidiary In this account model, you create directories for each subsidiary of your company. Additionally, you can add labels, for example, for cost centers or owners of the individual subaccounts or directories. 38 Account Model Directories per location Global Account Directory EMEA Subaccount for DEV Subaccount for Test Subaccount for Prod Apps Apps Apps Services Services Services Connectivity Connectivity Connectivity And more And more And more Directory AMER Subaccount for DEV Subaccount for Test Subaccount for Prod Apps Apps Apps Services Services Services Connectivity Connectivity Connectivity And more And more And more SAP Publlic 39 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. 39 Account Model Directories per functional area Global Account Directory for Sales Subaccount for DEV Subaccount for Test Subaccount for Prod Apps Apps Apps Services Services Services Connectivity Connectivity Connectivity And more And more And more Directory for HR Subaccount for DEV Subaccount for Test Subaccount for Prod Apps Apps Apps Services Services Services Connectivity Connectivity Connectivity And more And more And more SAP Publlic 40 Account Model Directories per Functional Area In this account model, you create a separate directory for each functional area. Within each of those directories, three subaccounts (for development, test, and production) are created. For each directory, the functional area can use their own identity provider and manage their entitlements. Additionally, you can make use of labels, for example for the person responsible, cost center, or other aspects that you need for reporting later on. 40 Account Model: Create a staged development environment using Continuous Integration / Continuous Delivery Global Account DEV Subaccount for Project A DEV Subaccount for Project B DEV Subaccount for Project C Apps Apps Apps Services Services Services Connectivity Connectivity Connectivity And more And more And more Common Subaccount for Test Common Subaccount for Prod Apps Apps Services Services Connectivity Connectivity And more And more SAP Publlic 41 Create a Staged Development Environment Using Continuous Integration / Continuous Delivery In this account model, a dedicated Development subaccount is created for each development project. Applications that are developed in these subaccounts are consolidated, tested, and published in one single Testing and Production subaccount. This account model is especially well suited for companies with a focus on continuous integration and continuous delivery, as it lets every development project decide separately about their environment. A central Testing and Production subaccount ensures a high degree of governance, data security, and compliance. In the Cloud Foundry environment, consider creating separate Development spaces in one subaccount and a dedicated Testing and Production space in a Testing and Production subaccount, respectively. When to Use Which Account Model The shown Account Models above show ways to structure your global account into subaccounts. Note that all of them are just examples. They are not mutually exclusive and you can adapt them to your own needs. Determine which account model with subaccounts is the most appropriate for your needs. More example account models can be found on Account Models with Subaccounts | SAP Help Portal on https://help.sap.com/docs/BTP/df50977d8bfa4c9a8a063ddb37113c43/049d331effa3434c8b55995f63f92f5f.html Additional guidance to determine the right account model can be found on When to Use Which Account Model | SAP Help Portal on https://help.sap.com/docs/BTP/df50977d8bfa4c9a8a063ddb37113c43/e4b4b5f9a64d46d08ceec5488a108 008.html There you can find tables which provide requirements with regards to project and team setup as well as the services and resources involved. You can compare them against your own requirements and see which account model most closely matches. Please remember that the account models are a result of a best-practice approach. They are not mutually exclusive and you may want to use a combination of approaches, if, for example, you have different projects with different requirements. 41 Example: Extend SAP S/4HANA (Cloud or On-Premise) SAP Business Technology Platform DEV