Caveat: I have no access to internal SAP planning material, so I’m basing this blog on publicly available material. I’ve used blogs, blog comments, forum posts, etc as the basis for this blog. I also have not used the new BPM tool, so I can’t talk from personal experience.
Current situation
At this year‘s Sapphires, Introducing SAP NetWeaver Business Process Management (BPM).
Now, at SAPPHIRE 2008 in Orlando, as a first result of "Project Galaxy" SAP has announced the planned availability of "SAP NetWeaver BPM" and "SAP NetWeaver Business Rules Management (BRM)" as brand new components of SAP NetWeaver Composition Environment (CE), that will be shipped this year with SAP NetWeaver CE 7.1.1.
I liked what I saw at the conferences but I kept on thinking about Composite Processes (GP) and considered what the impact of this new environment on the existing toolset might be. Questions like „Will the new environment replace GP?“, Should I stop my GP projects“ all started popping up as I saw the various presentations.
So, I decided to sit down and write a blog in which I provide recommendations for someone (a colleague, a customer, fellow community member, etc.) who came up to me and asked “I’ve heard about the new Process Composition tool from SAP. What about GP? What should I do?“
Of course, the situation may be different based on what the individual circumstances are. For example, there is a difference between dealing with existing GP process and planed usage of the GP.
Caveat: My intention in this blog isn´t to scare anyone to make hasty decisions but rather to open discussion on topic that impacts many of us.
The future of Guided Procedures
Before I start making suggestions, let‘s take a look at some of the details that SAP has provided us so far.
In the face of the new big brother - SAP NetWeaver BPM product, GP hasn‘t disappeared. There are references in many SDN sections as well as the recently published (April 2008) Enterprise SOA Development Handbook. Thus, it is obvious that both products are planned to co-exist for some time.
In Ginger Gatling‘s blog Workflow in SAP NetWeaver, there is an excellent comparison of all workflow products in SAP NetWeaver. For our discussion, one of the most interesting parts refers to the future direction of GP:
- Guided Procedures is release with SAP NetWeaver 7.0 and SAP NetWeaver Composition Environment 7.1. A full 5-1-2 maintenance strategy applies; GP (runtime and designtime) will be supported on SAP NetWeaver CE 7.1 in parallel to the new BPM solution.
- The project codename "Galaxy" is our long-term approach for business process modeling and runtime targeting human-centric, system-centric, and ad-hoc workflows.
(I‘ve added the bold type). In her response to comments in the blog, Ginger provides an even better description of what is going to happen.
It is true that Galaxy will eventually have the capabilities we have in guided procedures and more....it is still a bit away, especially if you do not want to participate in ramp up. Guided Procedures is supported now and in the future.
- Guided Procedures will not have further major development.
- There will not be a Visual Composer-design feel for guided procedures. You will not see any major changes in the design time. What we do have in CE is a new perspective so you can see the GP, UI's (such as VC's), services all in one view and link to each one. However, the GP design time itself will not have major changes.
- There will be a 'migration' of GP's to Galaxy, but not an import. The migration will involve work on the customer side.
(I‘ve added the bold type). Thus, it appears that the functionality of Guided Procedures will be superseded in the long-term by that of the new BPM Product. Based on this assumption, what are the suggestions for users to deal with their existing and planned GP projects?
Existing installations
For those individuals with existing GP projects, there are two aspects to examine in detail: the process model and the process data. By “models, I am referring to those process models that are currently present in the GP Designtime environment. By “data”, I am referring to the data that has been created by existing process instances.
Models
As Ginger mentions, there will be a migration but not an import of existing models. What I understand this statement to mean is that the models themselves (or at least some part of them) will be able to converted into the new environment. However, as Ginger suggests, this will involve work on the customers’ side. The reason is probably connected with the fact that GP includes many callable object types (and other functionality) that are closely tied to SAP functionality. As I mentioned in a Guided Procedures Explorations: BPEL Integration – The long answer, when you attempt to move a non-standard environment to one based on standards, then something must be changed manually.
Thus, GP users have three choices in this matter
- Migration of existing models: The details about the GP migration tool are currently unknown; thus, its capabilities / limitations shall determine whether and when users should use it. I would suggest that users use this tool first to see how much of their existing GP designs are migrated. If the majority of the design can be migrated, then the newly created migrated process (now BPMN-based) could be changed in the new environment to include the missing elements.
- Recreation of existing models in new environment: If you have complex models that don’t migrate well, then you may just as well create the model from scratch in BPMN. Depending on the quality of the migration tool, this might be the option that most users desire.
- Leave the existing models in the GP environment. In this scenario, the users would have two process composition environments. These older models could be maintained using GP-based tools.
Data
The instances of existing/legacy GP processes (along with their data) are stored in the WAS and can be archived. In today’s world in which compliance associated with processes (especially those including approval steps) is a critical, the data created by such processes must be accessible for future possible audits. The question is how to deal with this requirement. Through the use of the GP API (which is very extensive!), this data could be accessed through the creation of custom web-services. Thus, the data from older GP-based process instances could still be accessed although the process themselves are no longer being used.
If GP-processes are migrated to the new environment and an auditor wanted to see data of such processes before and after the migration, then more complicated development work might be necessary to combine the two data pools of the pre- and post-migrated processes into one common view.
Planned installations
Short term
A Caveat: There is no one definition of “short-term”. I can’t say “short-term” = 6-8 months. The definition of this time period varies between and within companies. It is also influenced by SAP’s product release cycle.
The fact the new product has just been announced does not mean that it will available to all GP users soon. Different release plans within corporations might mean that the new environment might not be available although users are chomping at the bit to use it. However, processes must still be created – process improvement projects must still be performed. It is not possible to put such endeavors on hold indefinitely or until the new environment is available.
In this situation, GP can still be used. The question is “how can such processes be designed that a future migration to BPM is as painless as possible”.
Here are a few suggestions:
- Use of Visual Composer for the process UI. Visual Composer isn’t going away in the new environment; indeed, it appears to play an important role in it! Thus, the use of VC-based callable objects instead of other-specific COs (BSP, etc.) should make migration easier. The use of this technology would also make a future transition between the two environments less visible to the end-user in that the UI changes might not be necessary. Furthermore, since the ability assign a user interface to a task appears to be based on Web Dynpro (WD), this should be suitable for Visual Composer as well.
- The use of the web-service callable object to perform data-related activities. Inasmuch as the new environment is constructed to optimally use SOA-based environments, then the use of such callable objects in GP is recommended
- There are a number of exotic GP callable objects (in the “misc”. category) that might not be available in the new environment. I have no idea which of these existing callable objects (which I think are great and make process design a lot easier) are going to available in the new environment as web-services. The possible gap between existing callable object types in GP and those offered in the new environment might be an opportunity for partners or other service suppliers to support the transition to the new environment.
Long term
I think it is obvious that SAP is going to concentrate its efforts on improving the new environment instead of GP. Thus, those performing process composition tasks should plan on using the new environment for future long-term projects.
Coexistence of GP and the new BPM product
I’m assuming that there will be a certain period (especially right after the release of SAP BPM Product) when corporations who are currently using GP will have both environments (GP-based and BPM-based) simultaneously active. In a very recent SDN article “Modeling Processes with Process Composer”, a figure shows the structure of a composite application and includes both GP and the new environment:
Thus, both environments are supported by SAP in the process layer.
The fact that this dual environment will exist is also supported by the new BPM tool which will have “a new perspective so you can see the GP, UI's (such as VC's), services all in one view and link to each one.” I’m assuming that GPs can’t be edited in this perspective. I don’t know about the ability to include existing GP design elements in BPMN-based processes either.
However, in my opinion, it doesn’t make any sense to have plan long-term support for both process composition environments. Of course, the support / maintenance of existing GP-based processes is conceivable and probable in the short-term. This dual-product environment is highly inefficient, due to the higher operational costs (administers may have to use different tools to transport, monitor processes) and higher maintenance costs (developers / BPXs have to maintain /design processes in two environments). A setting where just a single process composition environment is in place just makes better business sense.
The only reason to have a dual environment is that some process requirements can only be fulfilled via the usage of GP functionality. It would be interesting to create such a list of requirements that mandate a usage of GP. Initially, such a list might be quite long. However, as the new environment matures, the list should get smaller and then eventually disappear.
Conclusion
I’ve created this blog based on every bit of relevant information that I could find. My goal was to create some sort of a decision-making matrix – not only for myself but also for others involved in process composition. The increasing awareness of the critical role of the process in organizations has led to a spotlight on BPM tools. Decisions dealing with process design and tool selection have thus gained importance as well.
I’m looking forward to working with the new BPM environment. It has great potential. However, until the time comes when I can put my arms around a BPM installation DVD and call it mine, I will continue to use Guided Procedures.
- SAP Managed Tags:
11 Comments
