The Long Term Problems with SAP and Integration

Executive Summary

  • SAP makes bold statements about application integration that assumes SAP’s integration competence.
  • We review SAP’s history with integration.


In its history, SAP has not been successful in creating integration applications. SAP PO is not well regarded and would be a distant second to the top integration tools in the field and they do not sell integration applications like SAP PO to anyone but pre-existing SAP accounts, usually under the concept that SAP PO is naturally designed to integrate to SAP. And for many types of integration work using data transformation scrips and other specialized integration scripts are often preferable over packaged solutions. SAP proposes that integration should be performed in ABAP, or that SAP tools should be used to create ABAP, but there are other superior languages for interface development.

Yet, nowhere is this observed in any of the SAP documentation. As an example, ABAP is not used outside of SAP customers for interface development. Languages like AWK are quite frequently used for transformation because they are naturally designed for this task.

Following SAP’s Integration Advice?

If SAP’s applications are not used in an area, and the area is programming intensive (which integration is), there is little reason to follow SAP’s advice when it comes to what language to use, or what tools to use. The entire logic for following SAP’s directives is if one is using their packaged applications.

Previous Claims Made in the Application Integration Market

Overall the integration market has for several decades been marked by claims around ease of integration brought by various products. Most of those claims have proven to not be true. That is the movement has been from using programming to using applications to perform the integration.

In more cases than not, this has proven to be negative for integration productivity and even transparency. It is apparent from SAP’s documentation and other marketing literature that SAP is not interpreting their attempts to productize integration in a way that allows them to understand why they are not making progress in the integration space. This gets into the topic of the non-programming integration paradigm.

The Non-Programming Integration Paradigm

If we follow the evolution of SAP’s integration solutions, SAP has attempted to move from programming paradigm to non-programming. This is when writing of explicit code was replaced with some transactions for customization.

A few examples are as follows:


  • 2005: SAP renamed XI to PI (Process Integration) due to modification of licensing policy, so that clients paid for traffic, but not per instance. Also, SAP extended the number of use cases in marketing materials. In the same year, SAP acquired LightHammer. LightHammer had and their integration solution aimed at the manufacturing domain. Later this solution was renamed to SAP MII, that was delivered with SAP PCo (Plant Connectivity). An additional service aimed at industrial support interfaces of data exchange like OPC. SAP MII was also built as a wrapper on top of C/C++ libraries.
  • 2011: SAP PI was renamed to SAP PO (Process Orchestration). However, it was more marketing rebranding than a technology update. This rename did not change SAP PO’s prospects in the market with PO declining in popularity further since 2011.
  • 2016: SAP presents its Cloud Platform Integration & Hybris Data Hub. The SAP Cloud Platform (renamed from SAP HCP) is designed to perform integration with remote SAP System. The Hybris Data Hub is aimed at integration the integration of SAP’s Hybris e-commerce application with a short number of functions in SAP ERP like material master data, stock value and prices.


Document Note *This is a truncated history, but it should be sufficient to illustrate the pattern we are describing.


All of the technologies listed in the previous section are based on C/C++ library that wrapped with Java library that wrapped with one of listed integration tool (much like an onion).

  • SAP has historically benefited from a large pool of specialized workers that are able to configure systems without knowing how to code. This is the standard SAP “functional consultant” as opposed to a “technical consultant.”
  • Meanwhile, vendors ranging from Oracle to Axapta to Baan frequently struggle with a shortage of well qualified IT resources to build their ecosystems. SAP easily attracted non-technical resources and converted them to consultants. Doing this they were able to develop a very large number of resources who were ready to set up all business logic in SPRO/configuration without writing a single line of code with most of these resources working in SAP consulting partners or as independent consultants rather than working for SAP itself.
  • The approach to making the configuration available within an application reduced the learning curve for configuring SAP and opened the area to more resources.

Issues with The Non-Programming Approach for Integration

  • In the mid-2000s, this might be proposed to be a reasonable trade-off (although we would have disagreed with it even then). However, at that point, there was little to integrate to most of SAP systems. However, by the end of the 2000s, we already had a massive offering of different technologies and concepts that is still growing. And these are becoming more available due to cloud service providers. This allows companies to experiment at low effort in a way that was previously not possible.
  • In recent years, we see the growth of solutions aimed at integration with SAP ERP to extend its planning, reporting or any other abilities. There has also been the massively increased popularity of mobile and web-based solutions that also aimed to be integrated to SAP.

Getting to the Heart of the Problem with SAP’s Integration Strategy

  • The biggest problem of current integration products from SAP is that SAP provides an inappropriate model of integration.
  • Features that made SAP XI/PI/PO accessible to SAP consultants are now doing them a disservice.
  • SAP PO was not designed to work with most of the contemporary technologies and protocols.

We put AIF and BRF in a similar category with SAP PO, which is why, in addition to the products not matching the SAP pronouncements about them,

Financial Disclosure

Financial Bias Disclosure

Neither this article nor any other article on the Brightwork website is paid for by a software vendor, including Oracle, SAP or their competitors. As part of our commitment to publishing independent, unbiased research; no paid media placements, commissions or incentives of any nature are allowed.

Search Our Other SAP Content

SAP Contact Form

  • Interested in Our SAP Research?

    The software space is controlled by vendors, consulting firms and IT analysts who often provide self-serving and incorrect advice at the top rates.

    • We have a better track record of being correct than any of the well-known brands.
    • If this type of accuracy interests you, contact us and we will be in touch.