Skip to Content

SAP Business Process Management (BPM) is an area that is currently enjoying a lot of attention. But what does SAP BPM mean for your SAP landscape architecture? This article explains the differences between a traditional SAP application architecture, an SAP integration architecture and an SAP BPM architecture by using an example.



Enterprise Architecture

Organisations are facing an increasing number of changes in their processes. An enterprise architecture is essential to ensure that these changes are made both in business and IT in an effective and efficient way and with enough cohesion.

In an Enterprise Architecture several individual architectural layers can be distinguished that are able to answer the following business questions;

  • Presentation layer; which tools should I use for what, and what do my screens look like?
  • Process layer; which process step should I execute?
  • Integration layer; in which system should I do what?
  • Application layer; how should I execute the transaction in this system?
  • Database layer; in which tables will my data be stored?

The demands for the various architecture layers are very different. First of all, the database, application and integration layer on the whole need to be stable.

Furthermore, the integration layer should have an open character, meaning that data can be exchanged with various kind of applications. The number of companies that only use their SAP systems to support their entire business processes is namely virtually zero.

The presentation and process layer on the other hand require flexibility!

Enterprise Architecture 5 layers

Figure 1: Enterprise Architecture 5-layer model



Example Business Process

Using the 5-layer enterprise architecture model and a business process example we will demonstrate the differences between a traditional SAP application architecture, a more integrated SAP architecture and an SAP BPM architecture. With each situation the possibilities for optimizing the business processes will be explained.

In the example we will use a typical offer to cash process, in which external sales agents provide written quotations to the internal sales department, who in turn enter them into a non-SAP application. Next, the quotation is created in the SAP system using an interface. After the approval of the sales manager the quotation is converted into a sales order, which in turn will be delivered, billed and paid for.

offer to cash process 

Figure 2: offer to cash process



SAP application architecture
All business process logic resides in the application layer, the integration of systems is with custom code interfaces.

In a traditional SAP application architecture we see that all business process logic is determined in the application. In SAP ERP for example it is determined with the use of the SAPGUI what the screens for the end-users will look like and which process steps should be executed in what sequence. Besides that it is predetermined in which system the actions will take place, with which transactions and in which database tables the data should eventually be stored.

Integration with other non-SAP systems often takes place via point-to-point custom code interfaces. For our example this can be shown schematically as follows, with the red flows symbolizing the SAP custom code:

application architecture

Figure 3: SAP application architecture (with red flows as the SAP custom code)

Process optimization in a traditional SAP application architecture is difficult and actually only possible with more custom code in the SAP ERP system.



SAP integration architecture
All business process logic resides in the application layer, integration of systems is with standard messages or services.

A traditional SAP architecture can be unlocked by adding system integrators. Examples of systems that can perform this integration function are SAP Process Integration (PI), Tibco Business Works (BW) or Microsoft Biztalk.

In an integrated SAP architecture there is at least some integration between non-SAP and SAP systems, with the use of standardized messages or services. This can prevent the use of point-to-point custom code interfaces.

integration architecture

Figure 4: SAP integration architecture

However, the way the processes can be executed is still determined by the underlying application. In our example the written quotations will still have to be manually entered into the non-SAP quotation application by the internal sales department. With the use of a standard message they will now be automatically processed and created in SAP ERP.

Process optimization with BPM remains a difficult issue, even in the integrated SAP architecture. However, due to its open character and with the option of using Enterprise Services (ES), the availability of an integration layer is an important condition to eventually optimize companywide processes that run through several systems.



SAP BPM architecture
The business process logic is divided over several layers, integration of processes is with services.

Only with the addition of the SAP Composition Environment (CE) as a process layer, companies will have the tools available to model, build and execute processes the way the business requires, without having to use custom code in the underlying SAP systems.

In our example a BPM Composite Application (xApp) named “Offer” can be developed for the external sales agents with SAP CE. Through a web browser the sales agents gain access to the Composite Application, with which they can create new quotations and change existing quotations. These quotations are updates both in the non-SAP and the SAP ERP system via de integration layer, by means of standard SAP Enterprise Services

The manual entry of quotations by the internal sales department and the corresponding interface to SAP ERP is no longer necessary. The lead time of the quotation process has been significantly reduced, as well as the chance of errors.

BPM architecture

Figure 5: SAP BPM architecture (with dotted line as Enterprise Services)

Process optimisation with BPM has been made possible with the addition of a flexible process and presentation layer with the SAP Composition Environment (CE).




In a traditional SAP architecture all logic is determined in the applications. The various systems exchange data via interfaces, but the functionality remains within the boundaries of the existing applications.

With SAP BPM it is possible to deviate from this fixed, application based architecture. The logic is divided between various layers and therefore available for use in cross-system processes in a Service Oriented Architecture.

traditional vs soa bpm

Figure 6: Enterprise Architecture: Traditional versus BPM/SOA (Source: Sogeti).


For extensive and up to date information on SAP BPM check out the SDN site: or contact the author.


Frank Jacobs

Senior SAP Integration Consultant

Sogeti Nederland B.V.

To report this post you need to login first.


You must be Logged on to comment or reply to a post.

  1. Former Member
    Thanks for sharing this about SAP BPM explaining the clean differences between various architectures and the SAP tools fitting at different layers. Looking forward for more from you.
    Best regards,
    Prateek Raj Srivastava
  2. Vijayashankar Konam
    This blog clearly explains how architecture evolved over years and how exactly integration and BPM layers fit in an organisations SAP architecture. Good read.


  3. Former Member
    Good to see this blog, pinned well.
    As CE/PI evolve and overlap its important to point out what is the right choice for each case.

    P.s.: I guess you meant Tibco BW (Business Works) in comparison to PI, GI is the UI Technology 😉

    Best wishes

    1. Former Member Post author

      Indeed, you are correct! Tibco Business Works can be compared best with SAP PI. I probably missed this one during my several read-overs.




Leave a Reply