Skip to Content
Technical Articles

New version of the SAP Integration Solution Advisory Methodology Template released

SAP has recently published the whitepaper Intelligent Enterprises are Integrated Enterprises which  stresses the role of integration for becoming an intelligent enterprise. With this strategy SAP is aiming at facilitating a seamless integration of end-to-end business processes, spanning across integrated intelligent suite solutions as well as third-party solutions. The SAP Integration Solution Advisory Methodology (ISA-M) is the integration methodology for the intelligent enterprise: It helps enterprise architects to define and execute an integration strategy for their organization. ISA-M offers a simple approach for designing and implementing a hybrid integration platform which supports both – current and future integration requirements along an organization’s digital transformation projects.

The key element of ISA-M is a Powerpoint template which not only outlines the scope of this methodology but also provides integration best practices and accelerators. This format allows customers and partners to adapt and enrich the SAP delivered content in order to reflect customer context factors (e.g. existing investments, available skill sets). We are pleased to inform you that a new version of the ISA-M template (3.3) has been released. Based on the feedback from our community with more than 1,700 registered customers, partners and SAP consultants the ISA-M template has been updated and enriched with new concepts and best practices.

This blog describes the key updates and enhancements of the ISA-M template version 3.3. A detailed list of changes can be found in the release notes which is part of the ISA-M template.

Introducing the ISA-M Cycle

According to the way how SAP customers and partners are adopting ISA-M a four-staged cycle has been introduced to structure the concepts within the ISA-M template. This cycle outlines the different use cases of this methodology (figure 1):

Figure 1: SAP Integration Solution Advisory Methodology Cycle

Let’s now take a look at the single use cases of this cycle, the scope of SAP delivered accelerators and tasks to perform by enterprise architects. This will also include content-wise updates and enhancements which with the ISA-M template version 3.3.

1. Assess your Integration Strategy

ISA-M offers a stepwise approach which allows customers and partners to assess the current integration strategy of an organization: Starting with a high-level scoping on the level of integration domains which is followed with the scoping of integration styles and related use case patterns. Enterprise architects can select the ones from the SAP delivered template which are relevant for their organization as of today and/or midterm. The definition of integration domains, integration styles and use case patterns is outlined in the following.

Scoping of Integration Domains

As part of the first stage customers and partners revisit their current integration architecture by identifying current and future integration domains within their integration architecture. Integration domains are typical integration areas within a hybrid system landscape such as on premise to cloud, user to cloud and more (see figure 2).

Figure 2: Integration Domains of the SAP Integration Solution Advisory Methodology

Integration Domain updates with ISA-M version 3.3

The number of integration domains has been reduced: The integration domains B2B (business-to-business) and B2G (business-to-government) are discontinued. Both actually better fit to the category of integration use case patterns. Therefore, B2B Integration and B2G Integration are now defined as new integration use cases of the process integration style (see Integration Use Case Pattern updates with ISA-M version 3.3 of this blog). Furthermore, private cloud has been added to business application landscape illustration (see figure 2) as the third deployment option – in addition to on premise and public cloud deployments.

Scoping of Integration Use Case Patterns

Next, enterprise architects may select relevant integration use cases patterns (see figure 3). Use case patterns are technology agnostic and can be mapped to particular integration technologies. For this purpose, the ISA-M template provides a library of use case pattern definitions which are grouped along integration styles. Integration styles cover key integration archetypes such as process-, data-, user- and thing integration. Use case patterns which cannot be mapped to a single integration style are classified as cross use cases. An example of a cross use case is Event Based Integration which can for instance be applied along process and thing integration scenarios: For the first one business events allow a loosely coupled integration of business applications by applying an event driven architecture with publish & subscribe model for distributing events. In case of thing integration use cases large volumes of notification events from physical devices are typically issued and processed. Customers and partners can extend the pre-delivered catalog of integration use case patterns by adding custom ones as needed.

Figure 3: List of pre-defined Integration Use Case Patterns

Integration Use Case Pattern updates with ISA-M version 3.3:

The catalog of integration use case patterns has been updated by introducing some emerging patterns and discontinuing a few ones. The following tables summarize the changes of the patterns per integration style and cross use cases.

For the Process Integration Style:

Change Pattern Reason
Discontinued Business Network Integration Integration is similiar to the ones of other lines of business applications and therefore can be subsumed under the ‘A2A Integration’ pattern.
New Master Data Integration Replacing the ‘Master Data Synchronization’ pattern of the Data Integration Style as most of such integrations follow the characteristics of the Process Integration Style (e.g. near real time integration, exchange of single objects).
New B2G Integration Integration has got specific integration characteristics such as support of country specific legal requirements (e.g. document formats, protocol support, security).
As-is A2A Integration
As-is B2B Integration

For the Data Integration Style:

Change Pattern Reason
Discontnued Master Data Synchronization Replaced by the ‘Master Data Integration’ style of the Process Integration Style.
New Data Orchestration Emerging pattern representing data pipelining scenarios to process disparate kinds of data across diverse application landscapes.
As-is Data Replication (ETL)
As-is Data Virtualization
As-is Data Quality Management

For the User Integration Style

Change Pattern Reason
Discontinued Desktop Integration Most modern user interfaces are browser based and can be subsumed under the ‘UI Integration’ pattern.
New Chatbot Integration Emerging pattern using digital assistant technologies allowing users to interact with business applications via chat functionality or natural language.
As-is Mobile Integration

For the Thing Integration Style:

There are no changes regarding the patterns which still are Thing to Analytics, Thing to Process, Thing to Data Lake and Thing to Thing.

For the Cross Use Cases:

Change Pattern Reason
New Robot Process Automation Emerging pattern using digital bot technologies to automate workflows and processes across user interfaces and applications.
New Digital Integration Hub Emerging pattern to enable high-scale API-based access to business application data and data sources, while minimizing workload on these systems.
As-is API-Managed Integration
As-is Event-Based Integration
As-is Stream Analytics
As-is Workflow Management

2. Design your Hybrid Integration Platform

For shaping an organization’s hybrid integration platform, the set of relevant integration domains and use case patterns of the previous stage are mapped to integration technology and service categories (see figure 4). This mapping is highly influenced by the customer context, such as existing investments, commercial aspects and more. In most cases a single integration platform might not be sufficient to support pervasive integration needs. Therefore, enterprise architects may need to combine several technologies such as Integration Platform as a Service, IoT Platform to design an organization’s hybrid integration platform.

Figure 4: Mapping the integration styles and use case patterns to integration technology categories

For doing so, the ISA-M template provides sample technology mappings using SAP integration technologies. These are complemented with key characteristics and more which help not only to design but also to document the scope of the hybrid integration platform.

Technology Mapping updates with ISA-M version 3.3

The technology mapping visual has been enhanced to include a mapping to integration technology categories such as ESB, iPaaS (see figure 4). Furthermore, some sample technology mappings have been updated for introducing the latest SAP integration technologies. For example the sample mapping for the Data Integration Style has been updated referring now to the SAP Data Intelligence solution (see figure 5).

Figure 5: Sample technology mapping of the Data Integration Style

SAP Data Intelligence offers data orchestration capabilities which includes the former SAP Data Hub product combined with SAP Leonardo Machine Learning Foundation. This solution allows to pipeline data of different formats across diverse data sources and also to enable data-driven business processes with the help of machine learning technologies. More information about SAP Data Intelligence can be found at the blog SAP Data Intelligence: Next evolution of SAP Data Hub.

Please check out the release notes of the ISA-M template version 3.3 regarding further updates of sample technology mappings.

3. Define Integration Best Practices

Once the design of the hybrid integration platform has been completed, integration best practices are defined in order to safeguard the implementation of integration scenarios. This allows a proper handover of integration requirements towards internal or external integration developers and can set the scope for quality assurance of implemented integration scenarios. For this purpose, enterprise architects can create architecture blueprints for the relevant integration use case patterns (incl. integration domains) for the hybrid integration platform. These blueprints describe and document the scope and the interaction of integration technologies with business applications.

Integration Best Practices updates with ISA-M version 3.3

A new section for defining integration best practices has been introduced to the ISA-M template with version 3.3. Architecture blueprint samples are provided which illustrate the use and orchestration of SAP integration technologies along SAP and Non-SAP business applications. The blueprints are defined on the level of integration use case patterns in combination with respective integration domains (such as Mobile Integration for User2OnPremise). Figure 6 shows the architecture blueprint sample of the cross use case pattern Digital Integration Hub (Cloud to On Premise and Cloud):

Figure 5: Architecture blueprint sample of the Digital Integration Hub use case pattern

The Digital Integration Hub is an emerging integration pattern aiming at delivering a high responsive frontend API access layer which is decoupled from the business application data sources. This can be achieved by introducing a high-performing in-memory data layer (using SAP HANA database) between the front-end API layer and the business applications. The data residing in the in-memory data layer is aggregated and synchronized through event-based integration (using SAP Cloud Platform Enterprise Messaging), A2A integration (using SAP Cloud Platform Integration) or data replication pattern (using SAP Smart Data Integration). For more information about how to implement the Digital Integration Hub use case please check out a recorded session about Digital Integration Hub: Building Agile Data Grids and Microservices

Each architecture blueprint sample is complemented with characteristics and selection criteria which helps integration developers to choose the right blueprint for an integration scenario. Furthermore an infosheet per architecture blueprints delivers further information about the solution scope, when and how to apply this blueprint. Further general recommendations such as integration do’s and don’ts are shared which helps to avoid common pitfalls with regards to integration developments. The pre-delivered library of architecture blueprints can be adapted and extended with customer specific blueprints with using the provided template.

4. Enable a Practice of Empowerment

Once the integration best practices have been defined, they can be rolled out into the organization and beyond (towards external integration developers). By doing so project teams can be empowered to develop interfaces in an agile way based on the defined integration strategy. This phase also provides a feedback channel for incorporating lessons learned into the integration strategy.

As part of this use case organizational aspects and processes are covered such as introducing an Integration Competency Center. This also helps to establish integration as a recognized discipline within an organization, not only to support but also to enable digital transformation projects. Furthermore, with the help of this methodology integration expertise can be scaled out into the organization, too: For instance by introducing areas for self-service integration implemented by business personas (so called citizen integrators).

Enable a Practice of Empowerment updates with ISA-M version 3.3

For this ISA-M use case a new section has been added to the ISA-M template which describes common integration roles and tasks in an SAP context. In accordance with the use cases of the new ISA-M Cycle the integration maturity levels have been udpated (see figure 6)

Figure 6: Integration maturity levels when applying the ISA-M

With the help of the SAP Integration Solution Advisory Methodology you can raise the integration maturity level of an organization by adopting a proven methodical approach: This ensures a profound definition, rollout and execution of an integration strategy which fits best to an organization’s overall context (such as enterprise architecture strategy).

Want to get started with ISA-M?

When you would like to explore and adopt the SAP Integration Solution Advisory Methodology within your organization you may use the free template (see figure 7):

Figure 7: ISA-M template version 3.3

Just walk along the use cases of the ISA-M cycle for improving your integration competencies. More information about ISA-M and related SAP integration technologies can be found at the CIO Guide: Process and Data Integration in Hybrid Landscapes.

If you are interested in receiving access to the ISA-M template please send a mail to If you are already applying ISA-M and you have some ideas for further improving this methodology we’d be more than happy if you could share with us your findings via, too.

You must be Logged on to comment or reply to a post.
  • It will immensely help Integration Architects for defining integration strategy on organization level.

    Thank you Katrin for valued blog.!


  • Hello Katrin Ahsen , It is a great blog. It may be helpful to take integration architects and developers on a journey on how integration evolved in last decade and a few basic guidelines that we can use to procure multiple SAP tools  based on pattern and use case.

    If you think it is useful, please link this into your blog as I linked your new template into mine.

    I will also be glad to hear your feedback if you think i need to modify any sections.

  • Thank you for describing these interesting conceptualizations. Integration is a word with many possible meanings, and it is important to have a clear understanding when exactly it should enter the stage, lest I fall into the trap of calling next to everything an integration problem. Is there a definition of the SAP view of “integration” (as a goal of products and technologies) to be looked up? And I wonder – could this methodology be connected to a discussion of *essential* aspects of the problem: names and structures; basic challenges (domain models vs. message content) and basic options (e.g. using reference structures and vocabularies as bridges)? I’d like to see the broad elaboration of the integration challenge (ISA-M) complemented by a deep one.