Lesson 1 of 5
Using SAP reference architectures
10 min
Listen to this lesson
Most extension and integration problems have been solved before, many times, by SAP and its customers. A reference architecture captures one of those solutions as a reusable pattern: which services play which part, how data and identities flow, what the trade-offs are and what alternatives are reasonable. Starting from one saves weeks and avoids the mistakes that the pattern already designed out. It does not replace design: every reference architecture says, in some form, that it is a starting point to adapt.
Where SAP publishes them
SAP's main home for this guidance is the SAP Architecture Center, a site for architects and developers that collects reference architectures, best practices and community guidance. Its content is developed in the open on GitHub under an open source license, so each architecture shows when it was last updated and who contributed. Architectures are grouped into technology domains: AI and machine learning, application development and automation, data and analytics, integration, and operation and security. The site points to related resources such as the SAP Discovery Center, where services are described and missions walk through implementations step by step, and to diagram templates for drawing your own solution in SAP's notation.
What a reference architecture contains
The architectures follow a recognizable structure. Taking SAP's DevOps on SAP BTP with CI/CD and SAP Build as an example: an architecture diagram; a flow in numbered steps (set up continuous integration, develop, deliver, operate); characteristics of the result; examples in an SAP context; reasonable alternatives for teams with existing processes; and the services and components required. That structure makes them easy to compare with your own situation, step by step.
| Reference architecture (SAP Architecture Center) | Use it when |
|---|---|
| Designing Event-Driven Applications on SAP BTP | An extension must react to business events, such as a delivery being posted, without polling |
| SAP IAM integration with SAP Cloud Identity Services | Designing sign-on, user replication and authorization across SAP cloud apps |
| DevOps on SAP BTP with CI/CD and SAP Build | Setting up build, test, transport and operations for BTP apps |
| Multi-Region HA/DR Resiliency for SAP BTP | An app must survive a regional outage, beyond the default multi-zone availability |
| App2App Integration and API Managed Integration with SAP Integration Suite | Connecting applications and exposing APIs with management and security |
| Establish a central entry point with SAP Build Work Zone | Giving users one launchpad across SAP S/4HANA and BTP apps |
A selection of SAP reference architectures relevant to S/4HANA extensions. Titles as published; content changes over time.
Adapting, not copying
- Frame the needBusiness capability, users, data, volumes, availability and compliance needs
- Find the patternSearch the Architecture Center by domain; shortlist one or two
- Map to your landscapeReplace generic boxes with your systems, subaccounts and identity provider
- Decide the deviationsRecord where and why you differ, using the pattern's alternatives where they fit
- Add operations and testsMonitoring, alerts and test approach for each part of the flow
- ReviewDesign authority approves; the decision record links to the pattern and its version
Contoso used this approach for its first side-by-side app, the fleet order status app, which lets staff at Great Lakes Fleet Services see the status of their alternator orders. The architect started from the DevOps and identity architectures, mapped them to Contoso's subaccounts (cmc-ext-dev, cmc-ext-test, cmc-ext-preprod, cmc-ext-prod) and its SAP S/4HANA systems, and recorded two deviations: no multi-region setup, because the business accepted a few hours of downtime in a regional outage, and a technical user for back-end calls instead of propagating customer identities into SAP S/4HANA. Lesson 3 explains that second choice.
Reference architectures stop at the pattern. The next layers down are just as important: the SAP Business Accelerator Hub tells you whether a released API or event exists for the data you need, and what it contains; the SAP Discovery Center tells you which service plans exist, in which regions, and offers missions that build a scenario step by step. Contoso's architect checks all three before a design review: pattern, interface and service. A design that names a pattern but no released API for its core data is not finished.
What would you do?
A developer proposes skipping the reference architecture review for the fleet order status app because "we know BTP well enough". What should the architect do?
- Reference architectures capture proven patterns; they are starting points to adapt, not mandates.
- The SAP Architecture Center groups them by domain and versions them in the open.
- Each one shows the architecture, the flow, characteristics, alternatives and required services.
- Map the pattern to your landscape, record deviations and the version used, then add operations and tests.
Check your understanding · not graded
Lesson check
1. What is the best way to use an SAP reference architecture?
2. Where does SAP publish reference architectures by technology domain?
3. Which section of a reference architecture helps teams with existing processes?
4. Why record the reference architecture version in a decision record?