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.

A Case Study of SAP to SAP Integration

I am frequently asked how difficult it is to connect various best of breed planning solutions to SAP. I typically answer that integration between planning systems and SAP is greatly overrated in terms of difficulty. I often comment that planning systems have the benefit of have only a few interactions with ERP execution systems. I also tell people that ask that I have integrated planning systems to SAP roughly five times (both serving as the integration application engineer and managing the integration) and have never run into a major complication or missed deadline (unlike my experience with actually implementing supply chain application modules).

However, what is most interesting about the question, and an assumption that is often unexamined is that SAP ERP is not simply naturally integrated with its own planning system. The primary integration device between APO and SAP ERP is the Core Interface or CIF. The CIF takes a great deal of work to get working properly, lacks transparency, has weak error checking and consumes significant resources to “dial in” and get working properly. Secondly, the CIF requires more maintenance than any adapter that I have created (as part of a team) from scratch. I have known this for a number of years as I have been working with APO since 2002, however, recently I learned something else about the integration between SAP ERP and APO which I did not fully appreciate before, and this relates to the lack of controllability of the interface on the part of the implementing company. To explain this I will need to describe a recent experience.

Sales Orders and Forecast Consumption

APO has a setting which controls if and how Sales Orders consume the forecast. There are three quantities associated with a Sales Order, a Requirements Quantity, an Original Quantity, and a Confirmed Quantity. SAP gives you the option of consuming the forecast from any of these quantities. This would seem pretty straightforward, however, it isn’t. This is because the consumption is not only controlled by directly telling the system through APO configuration, which of this quantity to use to consume the forecast but this feature is also controlled by a field on the Sales Order called the Requirements Type. Using one Requirements Type causes consumption of the forecast to occur, using a different setting turns consumption for Sales Orders off. In the company I was consulting for, we spent quite some time attempting to troubleshoot this problem. Furthermore, the documentation on this issue was slight and we had to raise a note to SAP. The lesson from this experience is that the values on the transactions that flow from SAP ERP control important functions within APO. However, is this desirable?

SAP would clearly say this is desirable. However, my experience is that it isn’t. SAP developed from an execution system, and entered into the planning market in my view, primarily at the nudging of analysts who very shortsightedly declared ERP “dead” back in the late 1990’s (which brings up the topic of the accuracy level of software analyst firm’s projections). SAP brought their extreme complexity and detail-oriented approach which they had developed from their experience in execution systems to APO, which is not an execution system. Unfortunately, this has not been a very good match.

Why Planning Systems Should be Designed Differently from Execution Systems

Planning systems deal at a more aggregated level than execution systems, and having three quantities associated with a Sales Order is not necessary, and having configuration in the ERP system that controls important functions such as forecast consumption in APO is really more of a liability. As a planning consultant, I want to entirely control the consumption within APO, and I don’t want to be surprised like this that I then have to sort out with the ERP team. This glitch prevented the client from using the consumption logic for several months. The issue is that SAP has never seemed to understand that planning systems are different from execution systems, and this has resulted in a difficult to implement software suite in APO vs. best of breed vendors.

For those that don’t think this one setting is that big of an issue, it should be understood that this is just one setting (and a not well-documented setting). There are hundreds of settings like this, and every time I arrive on a project because the project documentation is not well maintained in 90% of the instances, I have to check everyone one of these settings. This is why it takes so long to troubleshoot APO vs. other planning software. The importance of not documenting everything in APO was highlighted by the experience described here.

Integration Transparency

In the cases that I have created custom integration harnesses, I never ran into these problems because I was able to control the meaning of the transported objects (Sales Orders, On Hand, Stock Transfers, Purchase Orders, etc..) much more easily than with the CIF. However, with the CIF, you end up getting unwelcome surprises exactly like this. SAP has taken the approach that there should be tremendous complexity in the logic of the integration between their ERP system and APO. I think don’t think this has been a correct decision.

The Problem: A Lack of Fact-Checking of SAP

There are two fundamental problems around SAP. The first is the exaggeration of SAP, which means that companies that purchased SAP end up getting far less than they were promised. The second is that the SAP consulting companies simply repeat whatever SAP says. This means that on virtually all accounts there is no independent entity that can contradict statements by SAP.

Being Part of the Solution: Fact-Checking SAP and Consulting Firms

We can provide feedback from multiple SAP accounts that provide realistic information around SAP products — and this reduces the dependence on biased entities like SAP and all of the large SAP consulting firms that parrot what SAP says. We offer fact-checking services that are entirely research-based and that can stop inaccurate information dead in its tracks. SAP and the consulting firms rely on providing information without any fact-checking entity to contradict the information they provide.

If you need independent advice and fact-checking that is outside of the SAP and SAP consulting system, reach out to us with the messenger to the bottom right of the page.

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 Integration Content