To Dual Stack or not to Dual Stack, is the question!

[Shabarish_Nair]

One of the questions that is going to drive a lot of discussions in the new wave of PI projects will be around the direction a customer seeks regarding the various SAP PI product versions available currently. May it be a fresh implementation, a migration or an upgrade project, the adoption of the “Single stack” vs the “Dual stack” needs to be debated.

There was already some thoughts shared by a Which instalation option to choose SAP PI 7.3 dual Stack or  SAP PI 7.3 single stackand this blog looks at adding some more dimensions to that discussion.

In his blog ‘Installation Options for Process Integration and Orchestration Use Cases, Alexander Bundschuh puts to rest a common misconception that from PI 7.31 the ABAP stack is no more available. There is indeed a clear confirmation that SAP will continue to support the dual stack until 2020 (at least). But SAP will now no longer look to invest in new features or innovations on the ABAP stack but will be focusing its energy on the JAVA side of things.

The option we will have is to go ahead for a Dual stack installation of PI or look at implementing single stack SAP Process Orchestration.

I will like to not henceforth confuse the reader with the word Single stack since Advanced Adapter Engine Extended (AEX) is also a single stack installation but differs tremendously from SAP NW Process Orchestration.

Now one thing that seems to stand out when we talk about Process Orchestration is the unavailability of ccBPM support and the new NW BPM in PI. Will this be a major criterion for decision making?

The fact remains that when executing large scale integration projects, you simply cannot live without a BPM scenario. Hence going for a single stack installation (the AEX) without the support for integration processes sounds a bit absurd and bold to me.

If we choose to go ahead with a new implementation, I will prefer to recommend that customers adopt the SAP NW Process Orchestration suite to reap the benefits of PI, BPM and BRM in their integration scenarios. Looking at some of the major players in the EAI space, it is very clear that the leaders in this space are already on a similar platform. SAP with 7.31 is only trying hard to catch up with them and thus provision a comprehensive suite when it comes to its own very SOA/EAI offering. Also with the open statement from SAP that its investments will be focused on enhancing Process Orchestration suite, it only makes sense to have your investments parked here.

Now what about customers who are already on a XI/PI platform and seeking directions?

ccBPM scenarios in the current landscape?

Let’s look at it from a volumetric perspective. Suppose the number of scenarios that involve ccBPM is less, it is only advised that some effort is spend on migrating it onto NW BPM and thus be in a position to adopt Process Orchestration. Now in case of a high number of ccBPM scenarios, efforts, testing and criticality will be major criteria to proceed. There is a risk quotient on making a drastic architectural change on a high number of interfaces in the landscape.

On the other hand, Process Orchestration is relatively new. The skill-set to fulfil this will be scarce. There will be a demand on the PI consultants to scale up to meet these new skills. So the organization has multiple factors to consider before moving onto Process Orchestration. If time and money are immediate constraints, look at moving to a dual stack installation but plan for a sooner movement to Process Orchestration in the future.

Is it really worth spending all that effort?

I have only got to try my hands on the Orchestration suite during TechEd. I maybe a bit harsh here but it may not be a complete solution at this point in time.

If an organization indeed has identified that it will require spending a considerable effort in moving to the new architecture, maybe a wait and watch approach could make sense.

Wait for the Process Orchestration suite to mature. Looking at the aggressive investments that SAP is making in this field, I am predicting a new EHP will additional features and all those bug fixes by end of 2012 (NetWeaver 7.32?). By that time, customers should also get sufficient time on their hands to understand what it will really take to move their BPEL solutions onto BPMN. Remember, this is not going to be conversion of standards activity but this should be thought through in terms of the whole BPM process and coming out with process improvements instead of a one to one migration. It gives customers a window of opportunity to fine tune their designs and enable it for the future human centric integration processes.

Apart from the BPM, if your organization utilizes a good amount of business rules, the platform provided by Process orchestration will seem ripe enough. Remember that Process Orchestration is a combination of SAP PI, NW BPM and SAP BRM. Hence the earlier you move to this platform the better. In case business rules are under utilized in your existing implementation or is managed using a different mechanism, you can hold your plans and then later look at options to move to Process Orchestration.

To me one thing is very clear. For any customers who are currently on XI 2.0/3.0 or PI 7.0, it would only be a useless gamble in going the intermediate way of choosing PI 7.11. It has to be PI 7.3/PI7.31 which offers you tremendous benefits. The question is only around  the dual stack or the java only installation and as for new implementations, Process Orchestration has to be the way forward.

I am very keen on seeing what will be SAP’s recommendation. Hope they will release an article or whitepaper with some case studies around this. But until then hope that the community members including the SAP team on SCN drops a comment on what their thoughts are on this subject.

PS: One more thing that should be part of the consideration is the federated PI architecture and how it will help your organization. Refer this demo to understand it better.