A couple of weeks ago I blogged about one of the boring, but important, design considerations that plays a role in delivering the promise of BPM technology: separation of concerns. In this post, I want to highlight its equally unsexy-but-important sibling: support for managed change in process applications.
A big part of the whole point of using specialised, model-driven tools to build process applications—rather than just modelling processes in Visio, PowerPoint etc and then coding something custom, or giving everyone a printed procedure manual to follow—is the fact that the model-driven approach is supposed to make it easier to change things later, change them relatively quickly, and change them with confidence.
Perhaps surprisingly, then, support for change management in many BPM technology platforms is pretty patchy! Who’d a thunk it?
Here’s what I consider a starter list of change management related facilities that are necessary for a platform to support the promise of BPM technology:
- Is version control provided at the model element level (rather than at the source file level—which may be different)?
- Is version control available for all model artefacts that exist (processes, rules, calendars, organisations/roles/groups, events, goals, etc)?
- Is it possible to package up versions of many related models and assets into configurations, which are themselves managed as versionable assets?
- Can multiple application configurations be stored, maintained and deployed in parallel?
- Is there decent support for impact analysis—showing the potential impact of changes to process, organisational, information models, rules or implementation details?
- Is it simple to trace historical changes throughout models, for audit purposes?
- Is any explicit support provided for managing the staged rollout of new processes or versions (to make it easier to deploy in large distributed environments)?
Advanced capabilities that I always look for include:
- The ability to specify that only certain users or roles can deploy new processes or changed processes
- The ability to specify processes that can be used to manage process application deployment publication
- The ability to migrate currently running instances to new process models on deployment.
Quite often, I’ll find that even the “starter” list isn’t addressed very well. Thankfully, the stock response I used to get to my question about change management facilities (“oh, you can always use the built-in source code control facilities in Eclipse”) is getting less common—but, as far as I can see, there’s still a long way to go before these features become commodities. If you’re serious about a BPM initiative and want to use specialised tools to help, this is something you should really think about.
As we renew our BPM technology assessment reports over the coming quarter, we’ll be digging into change management and calling out what, exactly, is available from all the key players. What do you think we’ll find?
If you’re interested in finding out more about our assessment approach, you can get access to our existing assessment guide reports for free here and here. You can also see overviews of our most recent versions of our in-depth reports here. We’ll be making a few changes to the assessment approach for our coming round of work, but the current reports are still relevant.