Introduction to Atlantis
No matter where you are, or what you do within SAP; one of the powerful aspects of the SAP Mentors is the support you get when you propose a good idea to them. Atlantis is an idea that I strongly believe in that a few mentors have rallied behind. It is trying to build an initially small community (not just SAP Mentors) who investigate software industry best practices or SAP Architectural questions but with a focus on providing the resultant discussion in the form of a blog or webcast to the wider SAP community.
That's the nutshell version of Atlantis which will get covered in more depth in the SAP Mentor Quarterly due in the next few weeks; and this is the blog around the first discussion which asked the question: When to use PI, BPM and Business (ABAP) Workflow?
The answer is obviously an "It Depends" answer but we'll at least try highlight what typically would be the right answer given certain scenarios. If you disagree with anything; then let's discuss as it's only through discussion that we will get to the most appropriate answer for others to benefit.
So What's the Answer?
In in order to get the discussion going, I enlisted the help of Al Templeton and Matthias Steiner to review a starting position paper that I put together titled "The answer according to Matt for analysis and debate". Below is what it said:
The Main Question - Where does BPM leave PI and ABAP Workflow?
BPM is the new kid on the block, and what a top dog it’s making out to be from a marketing perspective. It seems to do workflow, integration and all in an easy to understand business language, but with that in mind, where does that leave PI and ABAP Workflow?
Let’s start with PI. I do worry about PI becoming JAVA only with potentially people coming to the conclusion that ccBPM within PI gets moved to BPM; but for the sake of this discussion; if you are doing B2B and/or require service orchestration (compared with process orchestration); you need a good ESB and PI is for you in today’s world (feel free to debate this discussion still)
So moving on, if you are looking to undertake business process optimisation efforts within your organisation, then the value of BPMN being used within BPM is definitely a major plus. The ability to take your ARIS or System Architect models directly into an execution environment sounds very promising.
Even without an external modelling tool, BPM itself offers a business view of processes, though whether or not you can consider it a stand-alone BPM tool to give to business users is a different story altogether. That said, I haven’t heard much on Gravity for a while so that could be addressing those user needs? eg. I typically struggle ever putting something built within eclipse as an application in front of business users, but again, I’ve never tried to lock down an installation of eclipse with BPM to be focussed on Business users, so maybe it’s possible. Note - In terms of publishing the models to the web and allowing all users to comment on the process, I don’t see that in the picture yet, while a lot of BPMN modelling tools are exploring this collaboration functionality.
So if you still need to model out of an ARIS or System Architect modelling tool; the benefit from a BPMN perspective is more around having a much more standard approach to developing workflow which can leverage your company's process maps. Big plus for BPM there over Workflow (see below for what SAP could do to increase ABAP Workflow’s usefulness here).
But what if you are not doing process modelling...Well it is still a plus as you are going to find many consultants out there who know BPMN in varying degrees while ABAP Workflow is definitely a niche skill.
Another plus is that for the most part - it’s mostly model driven architecture with benefits that go along with that like not having much code generated for you automatically , and checks that can be done on your modelling that would in other environments, be much harder to track (refer to Thorsten’s blog recently for more about this). Workflow is also mostly model driven, though tends to rely on knowing more about many business objects methods, classes, functions, etc; though I imagine that BPM also requires this access, so I’m not sure how BPM makes this any easier. It almost seems that for the same task, you would need to expose everything to BPM somehow.
In terms of the actual workflow engine itself; this is where I find it hard to find the right use-case to invest in BPM for. i.e. BPM is not free while most people do have Workflow sitting there dormant ready to go for free. Obviously, orchestrating processes in a BPM fashion with SOA architectures where you have a reasonable enterprise architecture is an awesome use-case. You can start to measure your processes end to end, make process changes and measure the benefits in near real-time. This is definitely a nirvana situation. Unfortunately, many SAP shops don’t have much more than the big ERP, SRM and BI boxes with some B2B integration. i.e. The bigger you are, the bigger benefit I can see BPM being. Alternatively, if you don’t have ERP, BPM would fit the niche of a workflow engine perfectly. This also doesn’t take into account the cost of customers that have 0 JAVA stacks and the overhead of getting up to speed on support of that, so you don’t get BPM on a whim for that reason.
For those who do most of their workflows directly in the one or two systems, it almost doesn’t make sense to use BPM from the additional complexity of calling back to these systems in my mind. I haven’t personally been involved in what happens in BPM but I see it must be an overly complex overhead in BPM to do the following:
- Where you need to go to a person’s manager, or do role assignments, I assume you need to use a service to provide this;
- The numerous Web Service/RFC calls you need to add on top of this within BPM since business data is typically in the back-end systems
Both of these are trivial in ABAP workflow of course.
Similarly, I’m not sure what it takes skills wise when you have a scenario that requires custom development within BPM. i.e. When BPM needs additional logic beyond standard BPMN notation to do things.. I do get nervous that a tool like BPM makes everything so easy, that once you hit a hard bit, the consultants don’t actually have any experience with going outside the box. That’s not a great reason to say it’s a negative for BPM, but it’s like Windows and UNIX - Windows is so easy, that system administrators are usually much less competent than UNIX administrators. Hence, although you can run production systems on Windows now days, no one in their right mind typically does! Anyway, this is something I’m keen for others more experienced in BPM to comment on (i.e. The use of the whole CE stack is probably required here for defining assistant services).
The actual interface itself has some interesting thoughts to add to it. For those running major ERP shops - the web world is probably still not used by most with people using SAPGUI most of the time. Hence BPM is going to be a bit separate for you. That said, making a pretty UI for BPM is much easier to set-up (at least from a WD4J perspective), and with WD4A being supported from 7.3 - you can at least focus your developers on one UI technology for the most part. That said, from a prettiness perspective, ABAP Workflow does allow overrides in the UWL to be used, but if you don’t have a UWL - ABAP workflow UI’s tend to be pretty ugly. (On a side note - I highly recommend overriding standard screens for high numbers of users and the use of email links to open the screen with Single Sign-On but I digress).
Well there’s a whole bunch of opinions mostly dumped out pretty much. It more looks like a BPM comparison report than anything else so let me sum up my answer to the original question of “When to use BPM vs PI vs ABAP Workflow”?
Firstly, it’s still important to understand eventing in ABAP (which I consider part of Workflow). Hence knowledge of about 20% of workflow capabilities is required even with BPM if you have an ERP system in my opinion.
If you don’t have ERP and need a workflow engine - get BPM. There are lots of benefits to doing that which I won’t cover - but it’s definitely a good contender. Note - There are some other players in this same market so it’s not a slam dunk selection process and will depend on your circumstances.
If you have predominantly an ERP, BI, SRM, APO system landscape without any other significant business systems that business users interact within a single process (i.e. most workflow processes stay within the one box), get a UWL set-up and stick with ABAP workflow. If you only have the one ERP - it’s probably not even worth setting up the UWL (though you do lose some flexibility then).
Finally, if you have a complex system landscape with MES/Control systems, reactive supply chain information, etc; all happening and requiring process coordination across the whole lot - BPM is for you (but still get a UWL).
In terms of integration, Workflow and BPM can provide simple interface capabilities, but for your core integration between systems (not involving people), select an appropriate middleware tool like PI and don’t look back. That said, BPM and ABAP workflow is good for integration that has a strong set of business logic, while middleware typically should not contain detailed business logic. eg. Imagine a scenario where you pick up a detailed shipping document and you need to process the information to create various orders and deliveries based on its arrival automatically with user decision steps. I would not do that all in PI.
Final note - The combination of BPM, SOA and real-time and near real-time insight into your business processes is the next big thing for business so regardless of the decision above - this needs to be considered. i.e. ABAP workflow is not being heavily invested in if you see the lack of recent changes in it; hence you may be left developing frameworks to measure and quickly modify your processes and it’s always hard to sell building a custom solution that other products will get out of the box in the long run (like BPM and event insight - though does anyone know if Event Insight will support Workflow?).
Second Level Summary
The above attempts to address the question of what to use, but in reality, the question is when do you use each technology. My opinion, single back-ended workflows should remain within the backend next to the business data they are interacting with. Complex cross system processes should go into BPM. Now what about in the middle of those two or if you only have a small amount of cross system processes - well ABAP Workflow can call Web Services asynchronously really well so I think I would steer closer to staying within the one workflow tool and even managing some external processes within ABAP workflow - that said, you need a good enterprise architecture before committing to this approach. It’s kind of like saying that ABAP Workflow is your company wide workflow engine of choice so big call.
Is Workflow Hype Coming?
In addition, Today’s (ed: This was a while back but you can hear it here) JonERP podcast with Thorsten Franz highlighted that if Workflow was given a UI overhaul - it could minimise the gap between BPM and ABAP Workflow substantially. Time will tell if enough hype is given to ABAP workflow to get this going but I’m a believer that ABAP Workflow will reinvigorate itself in the future as the potential is huge (Caveat - I’m also part of WIT so I am obviously quite opinionated about this).
Obviously, writing a semi-blog as a starting point was probably a bad idea in hind sight as it argued a certain position a little too early, but the feedback that eventuated, not to mention the guest appearance, did result in some good thoughts which I'll attempt to cover below. Future Atlantis blogs will take a different approach and try to summarise the outcome better, so forgive me going over the timeline like this but it seemed the best way to explain what happened in this situation but will be harder to follow.
In summary, those from customers or working closely with customers tended to already be leveraging ABAP workflow, and the business case to leverage BPM was difficult to understand at these places (licensing, hardware, lack of integration with ABAP Workflow were some examples). In fact, the business case for using ABAP Workflow was more a fact that you typically already have it (and in my opinion, if you're not using it - then you're missing some great opportunities to improve process efficiency in your organisation).
To digress for a second, an important FYI from fellow mentor Tammy Powlas highlighted that "ASUG has a webcast on Workflow and BPM given by Ted Sohn, SAP Platinum Consultant, on March 22nd and it is open to non-ASUG members at this link".
Moving on...There was discussion about BRF Plus within ABAP which was considered a good stepping stone towards getting some of the same power in the ABAP stack as is already available on the JAVA BPM stack and that BRF Plus will be more tightly integrated with ABAP Workflow in the future.
It's at this point that in parallel to this activity, the SAP Workflow Influence Team (@SAP_WIT) met with SAP's BPM Solution Management Lead and they kindly offered to comment on the discussion with a very in depth response which I'll try paraphrase as best as I can below with my comments added in brackets (I'm sure I need to add some kind of waiver here so please don't rely on my paraphrasing to be 100% correct).
The decision to use BPM or any orchestration engine of SAP's really comes down to use-cases and for new projects to adopt the most appropriate solution. The big factor for BPM was the focus on the enterprise architecture. If the landscape was a single ERP style environment, then BPM was less desirable. But if you had a complex environment consisting of various different components requiring business process orchestration, BPM, along with BRM, could be an excellent solution. (Note - For more complex integration scenarios, PI is still recommended though BPM could tackle smaller integration issues).
The choice becomes harder when you're between those scenarios and that's where these further comments could assist.
So continuing on: From the strategic angle; it is apparent and should definitely be factored in that SAP are focussing their $'s on BPM and the JAVA PI stack over ABAP Workflow (though SAP_WIT is still trying to influence further improvements and focus in the future).
Considering modelling aspects, BPM uses BPMN, and if you don't want to go the whole hog with a full ARIS or similar process modelling approach; then BPM does offer you the tools to take advantage of to go down a top-down appraoch to process modelling. That said, it does not replace the full functionality of an ARIS style modelling tool.
It's at this point, a nice use-case was highlighted, and that was the use of the forthcoming Gravity functionality within StreamWorks being a "business playground" for designing processes that can be exported and imported into BPM. I won't go into details but the BPMN 2.0 XML Serialization will be an important interoperability aspect for all these modelling tools (including third parties) going forward.
There was mention of using BPM to tackle the scenarios currently handled by PI's ccBPM in the future, though timelines for this weren't mentioned. (Probably something for PI customers to consider in terms of the JAVA only PI and BPM stack pushing the dual-stack PI out of the picture in the future).
They also mentioned the growing support of possibilities for UI's within BPM (which is obviously a rapidly changing area with all the mobility scenarios that will interact with workflow in the future).
A Couple of Final Responses
In response to the above, Al raised the question about the separation of concerns that needs to happen between BPMN (within BPM) and the way to model stateful integration patterns (which is a great topic, but I won't try to expand on this now as it sounds like we need a whole separate Atlantis topic to get into this in detail). His also made the following comment which was succint and well worth quoting directly:
"Looking at use cases, the easy one is the BPM across multiple systems. But what of the case when you only have ERP. To me the way to look at this is to look at using either BPM or Business Workflow. I don't believe in this scenario there is room for both. The decisions then comes down to (assuming your not scared off by cost and infrastructure) your current WF investment, your willingness to re-skill and your desire to embrace BPMN modelling. For example, if you are not a heavy WF user, and you want to start modelling your processes via BPMN and then make them executable then BPM is your tool - but turn off your WF engine ;) If you don't really care for BPMN etc then Business Workflow will give you the same result with much less fanfare. See - it depends!"
And the final comment from Dagfinn with some very wise words around ARIS:
"For large customers looking at controlling their enterprise architecture, BPM is just too narrow. You need a solution such as ARIS if you are serious about processes and how they impact the enterprise. "
He goes on to state that Gravity may be a great intermediary tool to work with the business in defining/redefining processes though ensuring that ARIS is always the master is key.
He also highlighted one of the most important considerations when modelling processes in any orchestration tool, and that is around measuring your processes, ideally getting them onto a dashboard or similar.
For reference, BPM and Workflow themselves don't do this by themselves (without lots of custom development), but I believe that is where Event Insight is heading, though you guessed it, more licensing and infrastructure to achieve this nirvana.
Great Discussion and Thanks to the Atlantis Team
So in summary, we probably still haven't answered the question directly, but there's a lot of information above to help you make a more informed decision. It definitely does depend, and strategically, the decision is not easy. I hope this information was of value to a few out there, but regardless, this did lead down an interesting path, and thanks go to all the current members of Atlantis which I hope to grow into a much larger group once we get the format working just right.