Exploring SAP Integration Solution Advisory Methodology

As with the application development & automation as well as with the data & analytics dimensions of SAP BTP there is a methodology SAP provides for organizations to follow in designing and implementing their integration architecture. The SAP Integration Solution Advisory Methodology (ISA-M) is designed to accelerate the design and implementation of hybrid integration platforms, promoting a more agile and governed approach to enterprise integration for organizations to follow. It provides a structured approach to enhance an organization's integration maturity by guiding them through a series of phases which are assessment, design, best practices, and enablement.

The ISA-M is a structured approach provided by SAP to help organizations define and implement their integration strategy. It focuses on aligning business requirements with technical capabilities to create a robust, flexible, and future-proof integration landscape. Think of it as a roadmap for navigating the complexities of integrating different systems and data within and beyond an enterprise.

The following is the structure of the SAP Integration Solution Advisory Methodology.

• Phase 1: Assess Your Integration Strategy: Understanding the current state of an organization's IT landscape, business processes, and integration needs
• Phase 2: Design Your Hybrid Integration Platform: Defining the overall integration strategy and architecture that will meet an organization's business requirements
• Phase 3: Define Integration Best Practices: Reusing predefined architectural blueprints and adapting them to fulfil an organizations needs
• Phase 4: Enable a Practice of Empowerment: Creating a culture of integration excellence by empowering the team

The ISA-M can be used by everyone. Enterprise architects can use it to define company wide guidelines for the selection of integration technologies. Solution architects likewise use ISA-M to define best practices for integration. Finally software architects use the methodology to determine the most appropriate integration technologies for a given integration scenario, including its implementation.

When going through the four phases of the SAP Integration Solution Advisory Methodology, a series of deliverables is created. In the following table these deliverables are listed by phase.

To explore the ISA-M in detail please see SAP Integration Solution Advisory Methodology and in addition a learning journey, Getting Started with SAP Integration Solution Advisory Methodologyis also available. For purposes of this learning journey we will narrow our focus specifically to look at Phase 1 of the ISA-M (Assess Your Integration Strategy) and how that can be accomplished using the Integration Assessment Tool which is available as part of SAP Integration Suite.

The deliverables discussed in the prior section can be created using a series of templates each of which can be downloaded from the official SAP Integration Solution Advisory Methodology website. For the first phase (Assess Your Integration Strategy) a tool based approach is also available in addition to templates namely the Integration Assessment capability of SAP Integration Suite.

Certain data must be maintained under the "Settings" and "Configure" sections of the Integration Assessment tool to be able to use its functionality. This data is listed in the below list and briefly defined:

• Integration Domains
• Integration Styles
• Integration Use Case Patterns
• Integration Areas
• Key Characteristics
• Deployment Models
• Questionnaires
• Vendor
• Application (Profile)
• Application (Instance)
• Technology (Profile)
• Technology (Instance)

Here we see different integration domains which cover the different directions of information flow for a integration scenario. A "Cloud2Cloud" scenario could be for example SAP S/4HANA Cloud integrating with SAP Sales Cloud. A "Cloud2OnPremise" scenario could be SAP Commerce Cloud integrating with SAP S/4HANA.

Here we see different integration styles such as "Data Integration" which seeks to synchronize data across different databases (i.e., between an on premise database and SAP HANA Cloud) or "Process Integration" which seeks to achieve integration at the application level (i.e., a JAVA application running on SAP BTP, Cloud Foundry Runtime integrating with an ABAP application running on SAP S/4HANA Cloud ABAP Environment).

Here we see use case patterns which cover the "purpose" or "motive" for the integration scenario. The "Application to Application (A2A)" pattern is used when both the sending and receiving components are home grown and managed applications whereas a "B2G" pattern is assigned when the scenario calls for integration with a governmental entity (e.g., tax authority).

The integration of an integration domain an style becomes an Integration Area. "IP-1" for example combines the "OnPremise2OnPremise" domain with the "Process Integration" style. "IP-7" combines the "User2OnPremise" domain and the "Analytics Integration" style. Note "IP-13" which is customer defined and comprises the "Cloud2OnPremise" domain and the "Cross Use Cases" style.

"Key Characteristics" help with matching specific requirements (i.e., "I need the capability for end users to manage interfaces") to an actual solution with those capabilities (i.e., "SAP Application Interface Framework").

Deployment models become important if a scenario requires a system deployed in a specific way. For example a scenario based off of the "IP-3" (Cloud2Cloud) integration area would mean both the sender and receiver must be deployed in a public or private cloud not on premise.

The questionnaire is where questions can be maintained which in turn will be asked to users when using the "Request" functionality of Integration Assessment. This way interface requests can be thoroughly analyzed and suggestions for technologies and products can be more accurate.

Vendors can be SAP or non-SAP depending on the case.

The application is maintained under "Application Profile". This is an exhaustive list including both SAP and non-SAP applications. An entry here doesn't mean the customer actually has the application installed in their landscape.

An entry here does represent an actual application instance (based off an application profile) exists in the organizations landscape. Instance names are freely definable by the customer. In this case looking at the graphic, imagine a customer using both SAP S/4HANA and SAP S/4HANA Cloud as well as a non-SAP application Salesforce. In the graphic we see how these can be registered as application instances.

Technology profiles are maintained in the same way as application profiles are. The difference is that the entries represent technical solutions (i.e., SAP Integration Suite, SAP Event Mesh) as opposed to functional ones (i.e., SAP Ariba).

As with application instances these represent specific deployments of different SAP (or non-SAP) technological solutions. In this case the customer has SAP AIF, SAP Integration Suite, Cloud Integration and SAP Event Mesh deployed. Note that for each the deployment model (cloud or on premise) is noted.

When looking at the sample SAP BTP Solution Architecture Diagram above we see the appropriate master data (i.e., Application Instances, Technology Instances, etc.) that could be maintained in Integration Assessment.

Let's walt through a practical example illustrating how a request is entered end to end.

Once the appropriate master data for the Integration Assessment tool has been maintained then users can then start to enter requests for business solutions and interfaces. The master data is utilized in the creation and execution of requests. A variety of roles can perform this step. Potentially LOB owners, integration designers & developers and even in appropriate cases architects themselves. Let's look at the end to end process of entering requests using an example. After creating a new business partner in an SAP S/4HANA system (on premise), this business partner is to be synchronized with Salesforce. Instead of using an event-based architecture, the business process checks every 10 minutes whether a new business partner has been created.

Using this example as context the first step would be for someone to enter a "Business Solution Request".

A wizard is started. After filling in the basic data, the interface request is created. For purposes of our example assume the following data is entered:

The Interface Request is now created next. When creating the interface request the source and target application instances (SAP S/4HANA and Salesforce respectively in this example) are entered and the style is chosen. This way when the Integration Assessment tool executes it can reference integration domains, styles use cases and patterns along with the actual application and technology instances deployed by the organization.

It should also be noted that the wizard offers the possibility to attach documents to better document the business request.

After the initial creation of the interface request (step 3) it can be further defined by utilizing the "Requirements Analysis" functionality .

In this example the relevant pattern is A2A integration.

In this step three things are necessary:

• Whether a mapping is required (simple or advanced)
• Whether SAP predefined integration content will be used (if any exists)
• Whether SAP Integration Suite Integration Advisor will be utilized

In this step we see how a predefined iFlow aligned with the scenario is available and is thus selected. This content is retrieved from SAP Business Accelerator Hub.

In the next step three additional questions are answered:

• Whether technology or application (or both) connectors are used
• Whether protocol conversions are necessary (i.e., the source system uses iDoc format but the receiving system requires SOAP protocol
• Whether B2B/EDI scenarios are relevant for the request

In the final step before running the analysis it is specified whether the interface requires enduser monitoring and whether the receiver should get notified of certain errors is they occur during message processing. Answering yes to the first question implies that SAP AIF will be needed. Answering yes to the second question limits the results of the analysis to adapters that support that functionality.

Once all questions in the wizard have been answered the analysis begins and an output result in the form of a report is shown. Base on our example it is noticed that both SAP AIF and SAP Integration Suite, Cloud integration cover the various requirements (i.e., Transformations, Monitoring and Operations) of the request 100% ( 3 out of 4 via Cloud Integration and 1 out of 4 via AIF).

As previously mentioned the analysis takes into account actual deployed products and their capabilities. Since this is the case selecting them from the relevant drop downs should be a straightforward and simple process.

Here we see a completed Business Solution Request / Interface Request. At any time in the future due to a change in circumstances the request can be reopened and the analysis performed again.

Note the solution diagram based off of the example. Also note the specific SAP products and SAP BTP services mentioned:

• SAP S/4HANA on Premise with available Business Partner API in SAP Gateway
• SAP Application Interface Framework in the SAP S/4HANA on Premise
• SAP Connectivity service
• Cloud Integration capability within SAP Integration Suite
• Open Connectors capability within SAP Integration Suite
• API Management capability within SAP Integration Suite
• SAP Cloud Identity Services
• SAP Cloud Connector