The Integration Conundrum – A Point of View Paper on SAP Integration Portfolio

WRITTEN BY

I would like to begin this article by first introducing the CIO Guide that was published by SAP, documenting SAP’s vision around integrating SAP applications in both a cloud and hybrid landscape. I personally think that the guide is a great starting point to deal with one of the evolving architecture decision point around integration especially when organisations move towards adopting cloud applications.

While SAP treats the enterprise in a ‘SAPcentric’ way (this is SAP’s own disillusioned ‘Geocentric’ model of the enterprise world), most enterprises are heterogeneous (no surprises there) and the EA needs to be considerate of that fact. In this article, I would like to bring together all components and develop a single consolidated view of this portfolio, share an independent view around the SAP integration technology portfolio and the positioning of these different platforms/technologies in the enterprise.

Not many may realize, but SAP has a massive portfolio around integration (this is inclusive of the wider context of integration i.e. process optimization, DQ, Edge integration etc). A quick snapshot of this portfolio is below;

Note: The one in blue are the on-premise solutions and the others are cloud offerings, part of the SAP Cloud Platform.

There is already a good blog that introduces the cloud solutions that should provide you with a decent understanding of the capabilities and help with a choice of what to use when.

Below are extracts on the onpremise solutions;

Process Orchestration – SAP’s strategic onpremise integration solution for enterprise A2A and B2B integration along with Business Process Management and Business Rules Management.

Fitment: Enterprise landscape integration, business process optimization and automation, rules management.

Operational Process Intelligence (OpInt) – This is a solution in my view SAP’s Advanced BAM. OpInt promises Process transparency, Limitless scenario transparency and Insight to action around business processes with the key USP being the real-time data context aspect.

Fitment: Real-time insight to action for operations (linked to critical business processes)

Process Mining – A data-based process discovery tool that promises to help enterprises gain complete transparency into how processes are executed, increase process efficiency by identifying process deviations and weaknesses, improve compliance by detecting non-compliant processes and drive profitability.

Fitment: Process discovery and a foundation for business transformation

SAP Data Services (BODS) – This is SAP’s technology encapsulating data integrator and data quality. BODS is one of the most popular solutions when it comes to data provisioning and ETL, used widely in data migration and DQ led initiatives.

Fitment: Data integration and Data quality initiatives

Gateway – SAP Gateway is an open standards-based framework that developers can use to more easily connect non-SAP applications to SAP applications. It is also used to connect to and access SAP applications from mobile devices. As a result, it is a chief enabler of some of SAP’s newest and most prominent technologies, including the SAP Mobile Platform and SAP Fiori.

Fitment: UI/UX transformation for the SAP landscape

You would notice that most of the technologies have an overlap in terms of capabilities (functional and technical) and it tends to create a natural confusion for any enterprise architect team to provide guidance on tool fitment.

I would assume that a company like SAP would have consolidated their portfolio around these technologies but apparently it is either it has been a slow process at their end or that their internal strategy once again is so SAPcentric that they seem to spawn parallel products with overlapping capabilities.

A closer look might reveal that at times these products are very scenario-specific, catering to distinct use cases. Say for example Gateway – I have often wondered, wouldn’t it have been better than the capability of exposing SAP business data as ODATA services be a part of the Process Orchestration (SAP PO) suite, driving consolidation? But for two reasons, Gateway now has a strong fitment in the landscape, one being the fact that not all ERP customers would have a SAP PO license and the other being that specific use case Gateway looks to target that is enabling business data as lightweight APIs (ODATA) for the consumption of primarily UIs.

Again, from a consolidation perspective, I would have wanted to see the consolidation of distinct platforms like SAP Process Integration, SAP BRM and SAP BPM into SAP PO happening sooner. While SAP PO is now a very stable platform and is one of the leaders in this space, further consolidation could position SAP stronger at the enterprise level. An example of this would be the API management solution. As of today, API management is a separate technology component both on the cloud and on-premise. Most technology vendors have already consolidated this capability onto their ESB or integration-PaaS solutions making their platforms much more comprehensive for the new enterprise’s (read the advent of cloud, mobility and UX) integration needs.

But having said the above, SAP comes out very strongly with their portfolio and the set of technology tools provides one with an exhaustive capability list spanning most needs of enterprise integration.

On the cloud, SAP seems to be investing significantly and innovations are being rolled out for general availability very frequently. One such example would be SCP-Integration. SCP-I started out with being a cloud integration solution for mainly SAP to SAP applications (on-premise to cloud or cloud to cloud). Over the last 15 months, it has positioned itself in the iPaaS category with major capability additions around connectivity to varied systems, support for multiple protocols and the recent addition of B2B/EDI capabilities. SCP-I is a challenger in many ways, but it still serves a limited scenarios coverage. In comparison to its on-premise counterpart i.e. SAP PO, SCP-I has its shortcomings. While customers should look at taking advantage of the packaged integration content that is one of the key USP of SCP-I, two specific capability areas that deserve attention from a roadmap perspective are around the connectivity (adapters) and B2B integration.

The recent addition of SCP-Workflow and Rules packs a lot of power into the cloud offering, opening up a lot of possibilities around innovation and application development. Other individual components like the IoT services, SDI, SDS, API-M etc put together makes it one of the most competitive iPaaS currently that customers can possibly adopt.

So it comes down to one question and that is how does one make a choice around what technology to adopt? While the above can guide you to possible fitments, at an EA capability level, many decision-makers are forced to concern themselves with the choice of on-premise vs cloud solution stack.

In my many discussions with CIOs and IT stakeholders, there is an urge to go onto the cloud. I sense that though on most occasions this is driven by the long term strategy of cloud adoption, at times is also misplaced in many ways.

I would want to choose my words carefully here but what is a point of view if not for its genuineness. Most IT decision-makers are being swayed into the technology bandwagon that is cloud esp. around integration. Keeping aside an immediate benefit say via the attractive license models and a possible reduction in your OPEX, let’s not forget that each tool has its own fitment. So when it comes to investing in an on-premise solution vs an iPaaS to manage the enterprise integration needs, I believe the decision has to be predominantly driven based on the answers to the below questions;

• Is the enterprise landscape predominantly on-premise or cloud?
• Does your immediate roadmap include multiple cloud applications?
• What are the various integration points and the protocols in your landscape?
• How much B2B/EDI heavy are you as an organization?
• Is connected devices part of your IT strategy?
• Do you manage data on the cloud (read analytics, reporting etc)?
• Do you have a microservices architecture planned?
• Do you have an imminent need to govern and monetize your APIs?

Asking these questions will help strengthen your decision making. A simple rule of thumb I believe works well is that if more than 80% of enterprise applications are on-premise, then investing in an on-premise solution to manage integration is ideal. If it is that 80% of your applications are on the cloud, iPaaS is the way to go. But you will find that most companies are in a process of transition and hence the importance of a hybrid architecture where both the on-premise solution and the iPaaS become complementary. Even in this case, one is forced to answer the question of what to use where. Here we need to scrutinize the capability of platforms (keeping a close track on their roadmap).

A good example would be to say EDI integration. Many large organizations depend on the EDI solution to run most of their business. Hence EDI becomes mission-critical. Imagine you are a customer with your core ERP solution on-premise, using a legacy EDI solution running a large set of interfaces with a large set of trading partners and are looking to modernize. If you are faced with a decision to use SAP PO vs SCP-I, at this point in time, I would be inclined to use SAP PO due to the stable core and the rich capability the platform provides around EDI/B2B. On the other hand, if you had a relatively smaller EDI landscape, one would choose to onboard trading partners onto SCP-I because the trade-off can be managed. Do note that these decisions are time frame driven. In say 6 months from today, SAP decides to close all gaps around the capabilities/functionalities in this space, one will lean towards using an iPaaS solution for doing EDI.

Also is the fact that of having a consolidated landscape. If you are an enterprise heavily invested in on-premise applications, will it make sense that you use iPaaS solutions for your B2B and also your A2A? Why would you want to integrate two on-premise applications via an iPaaS solution? The answer always lies in your enterprise strategy around cloud adoption. This is also where the hybrid landscape gets reinforced. If you are heavily on-premise in the application space with that estate continued to be retained on-premise in the long term, I would place my bets on an on-premise solution for integration and for the scenario that is vice versa on an iPaaS solution. But most cases when you are embarking on a cloud journey, hybrid integration would find its fitment. The idea is to be aware of the capabilities of the platforms and base your decision along with your business needs.

I personally feel that for the next 5 years, the relevance of the hybrid landscape will become more and more prominent. IT decision-makers and Enterprise architects will have to define decision points and enforce the right usage of platforms, primarily driven through use case fitments.

We look forward to meeting you at the SAP Sapphire and ASUG Annual Conference 2018, 05-07 Jun, Orlando, FL. We are at Booth-1089C.
To see Session Catalog: Click here