Capgemini Oracle Blog

Capgemini Oracle Blog

Opinions expressed on this blog reflect the writer’s views and not the position of the Capgemini Group

Shifting towards ‘build-to-change’ processes, where's the flexibility?

Categories : BPMOpinion

BPM applications are on the rise again. Finally we're able to combine functionality, exposed as services, easily together into processes, it's like playing with Lego. One of the reasons for choosing a BPM type of solution is the shift towards ‘build-to-change’ processes, as opposed to ‘build-to-last’ back-office applications. What kind of flexibility is needed in a Build-to-change type of process and what Oracle functionality can be used for that.

First of all flexibility in Business Functionality. This is probably the most need for change. We can distinguish here between process functionality and content functionality. Process functionality is about when a process task is finished what task are we going to do afterwards. Within Oracle BPM this usually is done by a service call to a simple type of Business Rules engine (like Oracle Business Rules). The result is then checked in the Gateway following the service call. The Business Rules engine enables the flexibility for deciding what path to take in the process. Content functionality is what the process is all about. The real world data objects being moved from one process part to another. The 'old' way of doing this is calling out from the process to a silo based application in order to check the data. When we want flexibility in this part using silo based applications is not an option. We most often need a Business Rules engine that can handle complexity and is easily understandable by the Business. Oracle Policy Automation, or OPA, is a prime example for this functionality. Again, the flexibility is in the Rules Engine.

Another form of flexibility is adding Exception situations. Usually when we've deployed our first version of a BPM process, we know the happy flow, and when we're lucky some bits and pieces of exception situations. At this stage we know for sure that after learning the first experiences we encounter exception parts we didn't think of. After monitoring the application for a while, for instance with BAM and/or BPM Analytics, we are able to identify situations we didn't anticipate. How can we antipate situations? As described in my previous blog "Oracle BPM Suite, The importance of sub-processes within BPMN20" the Oracle BPM stack is based upon the BPMN20 standard. One key concept in the BPMN spec is around sub-processes. As described in the BPMN20 specification, ‘Sub-Processes define a contextual scope that can be used for attribute visibility, transactional scope, for the handling of exceptions, of Events, or for compensation‘. Sub-processes act as a container to combine the BPMN components Activities, Gateways and Events, and are, in a way just like any other process.
- Sub-processes abstract the details for Business Analysts
- Sub-processes define a scope in which error handling is defined on the boundary
- Event sub-processes can be used within processes to catch Business Events, such as errors or exceptions Subprocesses can help adding flexibility in the solution with regards to Exception Situations. During the design phase we must identify what parts of the process are related and can be combined together in a scope. Combine these activities together in a sub-process. Adding exception handling later to these related set of tasks means adjustments to two parts in the process definition. First of all, define a Business Exception and secondly add a Event Sub Process, related to the sub-process. Usually the exception consists of kicking of a User Task, sending out a mail or firing a compensation type of Web sevice.

The most difficult type of flexibility is changing processes on the fly during run-time. Acting in real time on a process, making the process to skip tasks, or even adding steps to the process it self. It all sounds so easy in marketing but can be hell on earth in real time. Skipping a process task at run-time can mean missing out essential information for future parts. Another type of process is more the (Adaptive) case management type of work, a new topic in the BPM market under large discussions. A large amount of process steps, many outcomes, and changing paths. This calls for another approach then trying to model out all possible outcomes. In my recent project an Application Maintanance party is going to be end responsible for the complete run of thousands of batch jobs belonging to the Day/Month end. In this end-to-end process multiple parties are involved, dependancies exist between the jobs, and Human Tasks exist. We know that in the (near) future changes are going to take place in the Day/Month end, jobs are removed, dependencies are changed and exception handling needs to be added to the process. Our system is fed with messages from start/end/status from the diffent jobs. Trying to model such a process with all possible outcomes is unreal, from a design standpoint (you're loosing overview), and a flexibility standpoint, changing such large processes is time consuming, costly and poses risks. We've defined solution consisting of one generic handling point for those messages coming in. This component consists of a combination of BPM, BPEL, the Mediator and Business Rules. All rules concerning dependencies are checked against what happened so far. All rules concerning jobs and dependencies are stored in the database and Business Rules. The other main part is a process consisting parallel flows of the main sampling points, which check against already entered messages. Here we've added scoped sub processes which in the future can handle exceptions occuring during the sampling of all the incoming messages. In this solution we've used BPM as a means to implement generic components, the flexibility is placed elsewhere in the database and Business Rules.

Flexibility in Business Functionality and handling of Exception situations is proven and on average means a modest amount of work.
Working with changing processes on the fly during run-time and (adaptive) case management style of processes is still under debate and solutions do not provide as of yet complete solutions. Léon is presenting 'Simplifying the Workflow Process in the Utility Market' at the Oracle Online Forum, "Transform Your Business by Connecting People, Processes, and Content" July 19th Léon Smiers, Solution Architect and Oracle BPM Thought Leader for Capgemini Oracle ACE

About the author

Léon Smiers

Leave a comment

Your email address will not be published. Required fields are marked *.