Lesson 1 of 5
Integration strategy
10 min
Listen to this lesson
Most SAP landscapes do not have an integration strategy. They have an integration history: interfaces built one project at a time, each sensible when it was built, together forming a landscape nobody fully understands. Contoso Motor Co. is typical. Its ECC system (EP1) exchanges data with banks, Lakeside Components, Great Lakes Fleet Services, a carrier, a tax service, the plant's test benches and a dozen internal tools, through a mix of IDocs, files, web services and an SAP Process Orchestration server. The S/4HANA conversion is the moment to turn that history into a strategy.
An integration strategy is a short set of decisions that make the next hundred interface decisions easy: which styles are preferred for which needs, which platforms run them, what standards every interface meets, who owns what, and how quality is proven. It is not a diagram of every interface; that is the inventory, which the strategy governs.
A method: SAP's Integration Solution Advisory Methodology
SAP offers the Integration Solution Advisory Methodology (ISA-M) to help enterprise architects define an integration strategy and derive guidelines. As SAP's Matthias Allgaier describes it, ISA-M provides technology-agnostic use case patterns that are later mapped to technologies for a given customer context, and it complements general enterprise architecture frameworks. It runs as a cycle of four phases.
- 1. Assess the integration strategyReview today's integration architecture by domain and use case pattern; identify future building blocks
- 2. Design the hybrid integration platformMap patterns to technologies; document the platform; derive integration guidelines
- 3. Define architecture blueprintsRefine key patterns into blueprints with components and interactions for projects
- 4. Enable the practice of empowermentRoll out guidelines and blueprints so project teams build interfaces consistently; collect feedback
Domains, styles and integration areas
ISA-M separates where integration happens from what kind of integration it is. Integration domains are the big-picture view: areas of a hybrid landscape where integration is needed, such as cloud to cloud or cloud to on-premise, and they are the entry point of an assessment. Integration styles are the basic categories: process integration (connect business processes across applications), data integration (access and synchronize data), user integration (connect user-centric apps such as mobile apps) and thing integration (connect sensors and machines). Each style is refined by use case patterns; process integration, for example, includes A2A, B2B, B2G and master data patterns. A domain combined with a style is an integration area.
| Contoso need | Domain (simplified) | Style | Use case pattern |
|---|---|---|---|
| Sales orders from Great Lakes Fleet Services | Partner to on-premise / private cloud | Process | B2B |
| Supplier master sync with procurement tools | Cloud to private cloud | Process | Master data |
| Production confirmations from test benches | Edge to private cloud | Thing | Device data to process |
| Finance data to the analytics platform | Private cloud to cloud | Data | Data replication |
| Field technician mobile app | User to private cloud | User | Mobile and API access |
Classifying Contoso's needs with ISA-M terms. Domain labels are simplified; use the current ISA-M template for the exact list.
Principles worth writing down
- Standard first. Use SAP-delivered APIs, events and prebuilt integration content before building anything. In clean core terms, integrate through released interfaces so upgrades do not break integrations and integrations do not block upgrades.
- One platform by default. A small, named set of runtimes, with exceptions approved, not discovered.
- Style by need, not by habit. Synchronous APIs where a caller needs an answer now; events where many consumers need to react; bulk data where volume matters more than latency.
- Every interface owned. A business owner and a technical owner, recorded in the catalog.
- Observable by design. Business context (order number, delivery number) travels with messages so failures can be found by the people who care.
- Secure by default. No credentials in flows, encrypted transport, least-privilege technical users.
SAP Integration Suite includes an Integration Assessment capability that implements ISA-M. SAP Learning describes it as a way to define, document and govern an integration technology strategy: you select the domains, styles and patterns relevant to you, map them to technologies with recommendation degrees, and use questionnaires in an interface request process so each new request gets a technology proposal that follows the strategy.
What would you do?
Grace asks for "the integration strategy" by Friday. The architect proposes a 60-page document listing every interface with its technical details. What is the better response?
- An integration strategy is a short set of decisions: styles, platforms, standards, ownership, proof.
- ISA-M runs in four phases: assess, design the hybrid integration platform, define blueprints, enable teams.
- Domains say where; styles (process, data, user, thing) and use case patterns say what kind; domain × style = integration area.
- Integration Assessment in SAP Integration Suite operationalizes ISA-M with questionnaires and technology proposals.
Check your understanding · not graded
Lesson check
1. What does ISA-M's first phase focus on?
2. Which list contains the four ISA-M integration styles?
3. What is an integration area in ISA-M?
4. Why is an interface inventory alone not a strategy?