Modular BPM process design stems from the widely used industry practice of Modular Software Design. Modular BPM process design focuses on building processes that achieve specific goals and objectives, while standing on their own, and being completely accessible for use by any software that needs to access the BPM process.
BPM process modeling is easy to perform but properly modeling to avoid pitfalls, maximize efficiency, and anticipate potential future changes is something that is hard to do. Designing and developing BPM process models and SOA/BPM composites in a proper modular fashion is the way to go.
Goals of Modular BPM Process Design
The goals are simple:
- Create BPM processes that acheive a specific goal or related set of objectives
- Increase BPM process and application quality, robustness, and scalability
Aspects of a Proper Modular BPM Process Design
The goals are achevied by specific aspects of a proper modular BPM design
- Process are built to accomplish specific goals and objectives thereby properly defining and handling the scope of their capabilities
- Processes are built to both stand alone and to be utilized in conjunction with other processes in any order that seems fit
- Processes are available to be used by non-BPM process software and clients that need to interact with the process
- Processes become much more reusable
- Process development lines can be managed independently of one another at the various business line levels as well as the various code management levels
- The impact of process changes are better encapsulated to avoid causing unwanted changes to separate process goals and objectives
- Process can be more easily organized into their business unit homes and maintained in a logical fashion
- When used in conjunction with a database external to the BPM Engine database, data can be more easily utilized and enriched for the entire enterprise rather than for a single process, application, or solution in an unwanted silo fashion
Common Pitfalls of BPM Process Design
- Designing large processes with many different goals and objectives – the scope of a process becomes difficult to manage as processes take on too many different goals and objectives leading to the propagation of issues from portion of the process being introduced into other parts of the process
- Designing large long running processes – in order to achieve one set of functionality distinctly different pieces of functionality must be encountered before and/or after the desired functionality, there is no way to get one without the other and the length of time it takes to complete or reap the full benefits of the process increases do the cumbersome nature of larger processes that are long running
- Designing process where logical integration points are lacking or non-existent – non-modular processes generally have fewer logical integration points that can be utilized effectively by other process, application, solutions, etc. and often lack the ability to be reusable or interchangeable
- Designing processes with payloads that contain too much business relevant data – business data in the BPM Process payloads is not easily and readily available for access other than by the BPM engine itself, the data is then only useful to the BPM process that holds it
Putting It All Together
There is definitely a struggle to performing a proper modular BPM process design. Sometimes people have trouble grasping the fact that what appeared to be a simple BPM process is in reality a number of processes or components that must be designed more thoughtfully and developed as a number of separate components to be incorporated together.
Additionally, a good modular design may feel like more work but in reality more time and money is saved in the long run. It is widely accepted in the software industry that the earlier issues are dealt with in the software develoment life cycle the more time and money is saved overall.
Finally, there can be some analysis paralysis on where to draw the line between modularity and the management of the code. A general rule of thumb is that a BPM process should have a definite goal and set of objectives to define the process scope. When new or different goals and objectives start to arise while working on a process, that is a good indicator another process is needed. Also, related BPM processes and/or SOA services can generally go together in the same composite.
Avoid getting so modular that every BPM process and/or SOA service becomes it’s own minature component and/or composite. The more pieces that are created, the more difficult management of code and deployments become. If you have a happy middle ground approach, then you never get too far into the realms of too modular versus not modular enough.
Now get out there and start practicing a more modular design. Once release two, three, and higher come along you will thank yourself for the ability to more easily roll out your BPM solutions and changes!