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.
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!
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.
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:
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.
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.
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.
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: http://www.sdn.sap.com/irj/sdn/nw-bpm or contact the author.
Senior SAP Integration Consultant
Sogeti Nederland B.V.