
Let’s face it, integrating IT systems / automating processes (often referred to as Middleware) isn’t considered as eye grabbing / interesting as mobile user interfaces.
So to grab some attention and prove that UI has a place in middleware, there is a screenshot below from our SAP Process Orchestration server, exposing the processes available using the Fiori launchPad. Note. screen is from 7.4, 7.5 has the more modern Fiori LaunchPad
Like security, middleware is a specialised area of IT, which if done well, enables the real-time data exchange and governance that is key for the business models demanded by Digital Transformation. If you want to understand this in more detail, I can recommend this OpenSAP Course – it is critical to get the middleware right first, in order to get the most from S/4HANA.
For example - Do you think Uber batches up your taxi requests! Your customers expect the same service level – competition is a click/tap/swipe away.
As I have discussed in this blog, SAP’s middleware portfolio has grown massively in features and maturity since it was introduced as XI in early 2000, I now regularly see SAP Middleware winning against pure play middleware vendors.
The purpose of this blog isn’t to demonstrate the long list of newer features, such as; Real-time KPI monitoring with OpInt, Complex Event processing on high volume data streams using ESP/SDS, Monitization of API’s outside your organization with SAP API Management by APIGEE or Cloud Integration using HANA Cloud Integration.
I want to focus on how you can build the case to move from SAP Process Integration - PI (or any other Middleware solution) to SAP Process Orchestration - PO.
First let’s make sure we all understand what these two products are:
SAP Process Integration – This is an integration broker which traditionally uses BOTH ABAP and Java stacks to enable Message Based integration between IT systems using a number of adaptors to get messages into and out of these systems. It is possible to deploy PI to just run on the Java stack, but if you are doing this you might as well activate the extra PO components (see below). This blog describes how to use only the Java part of PI.
SAP Process Orchestration – This is the combination of SAP Process Integration (as above), SAP Business Process Management (used to create workflows between people and systems), SAP Business Rules Management (used to enable user defined business logic required in any business process e.g. sign off limits). It also has lots of helpful technical components like the Composite Application Framework (for creating data persistency), Enterprise Content Management (used for document management) and a light weight version of SAP Portal capabilities (used for role based access to content), all only running on the SAP Java Stack.
Simply put, SAP Process Orchestration encompasses all the tools you need to create business logic, applications and integration required to plug any gaps between your IT systems – an on-premise Extension Platform
If you have PI, BPM and BRM licenses, you can get a credit for the full value from SAP to put towards your PO license.
You have to discuss with SAP about how this is turned into a license credit and how much PO will cost you. Also as the move from PI to PO is a migration (can’t do an in place upgrade) you might want to do this over a period of time (to reduce risk), so again you need to discuss with SAP about running both in parallel for the period of the migration.
Note to SAP: A clear policy on parallel running during migration would be really helpful.
Many customers I speak to are disappointed that they have to migrate from PI to PO. In my experience PI systems are often seen as something that you don’t touch as long as they work and customer side PI skills can often be low as the integration was done during an implementation project by the SI engaged at the time – the customer team can often be in support not development mode.
I would encourage you to look at the migration as an opportunity to spring clean your middleware landscape – implementing problem interface using state-of-the-art techniques. You can look at this blog to see the huge variety of Integration Patterns that are supported by PO. This blog also outlines what you can do in your current PI environment to make the migration as easy as possible.
SAP provide a migration tool that moves/converts the PI content that can be migrated from the PI system to the PO system. The key items that can’t be moved are ccBPM logic (which is replaced by BPM in PO) and ABAP mapping logic (as you don’t have an ABAP stack!).
Once migrated you can take advantage of the 13 reasons I have listed below – You can easily build your business case from these.
I hope that using the above list you can find the value required to go through the hassle of negotiations with SAP and the migration. With state of the art SAP middleware (including PO) you can be sure that you will not hit any bottlenecks getting data into and out of your S/4 HANA landscape.
One of my longer term PI colleagues goes white when I tell her she has to work on “just PI” now she is used to the PO.
You must be a registered user to add a comment. If you've already registered, sign in. Otherwise, register and sign in.
User | Count |
---|---|
8 | |
7 | |
6 | |
4 | |
4 | |
4 | |
4 | |
3 | |
3 | |
3 |