13 Reasons to Migrate from SAP PI to SAP PO (and Intelligent Business Operations) – Chalk and Cheese – Key for S/4 HANA

[OwenPettiford]

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.

What is SAP Process Orchestration

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

License Conversion

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.

Migration

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.

Migration Tool

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.

13 Reasons to Migrate from PI (or other middleware product) to PO

1. B2B add on – With PO you can use the SAP B2B adaptors and trading partner management and remove the need for 3^rd party solutions to EDI or costly 3rd party adaptors (this alone can justify the business case). Read this blog by Agnieszka Domanska for more details.
2. Simplified IT Landscape – by running ononly SAP Java stack your IT landscape is simpler to manage.
3. More Throughput – The move to Java only architecture means we get a massive boost in the performance throughput.
4. Human to System / Workflow – With PO we get access to SAP BPM which allows for great Human (screen) integration and workflows, this means we automate integrations where possible and involve Human steps which need review or additional data (e.g. make mapping errors into a business task instead of a IT one). See the screenshot above to see the type of processes that can be enabled.
5. Native Business Rules – Business rules allow you to empower business users to be able to “flex” the behaviour of integrations / processes. These can be maintained in production so changes can happen at the speed of business not the speed of IT. Examples might include look up value, sign off limits, % change etc.
6. Modern User Experience – As can be seen above, Fiori has made its way into PO, so where human interaction is required this can be done using HTML5 user interfaces that work on Desktop / Tablets / Phones and Watches. The best example being the My Inbox Fiori Application.
7. Easier to Develop – Having all the tools in PO in one box it is much easier to develop complete solutions.
8. Easier to Configure / Monitor / Tune – Because the tools are all running on one technical platform, it is much easier to configure / monitor and tune a PO system vs PI, as you only have one application server to worry about. See this great server overview available in PO.
9. Value Help – The value help framework allows easy integration to Business Suite systems for reference data (e.g. Company Codes, Plants, Customer Groups etc.) which you might want to use in your applications. Read this blog by Kate Burcham for more details.
10. Java Gateway / Rest Adaptor – These technical tools allow for fast integration with SAP Fiori services and other modern restful architectures
11. Ready for Cloud – The iFlows used in the PO system use artefacts that can also be used in the HANA Cloud Integration product – so if/when you choose to use that tool for cloud – cloud or cloud on-premise integration, you can re-use work you have put into interface definitions and mappings.
12. Ready for HANA – With PO you can run your middleware on HANA (PI dual stack will not be released for HANA, instead at 7.5 you have to split the ABAP and Java Application servers on to their own SIDs) which means you can get real-time insight from the system tables, plug Operational Process Intelligence directly into the process / integration events and use HANA Smart Data Streaming for high volume IoT scenarios.
13. SAP are not developing PI dual-stack anymore – By not being on PO you are locked out of new features. So PI isn’t a burning platform (perhaps smouldering a bit), but you will be locked in the past when it comes to new features.

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.