Over the years I’ve been part of many conversations that revolve around how ‘BPM’ is not the same as ‘BPMN’ (in the context of process automation). The point consistently made is that even when you’re tackling work improvement scenarios that are suitable for modelling with BPMN (i.e. scenarios where the structure of work can be largely designed upfront), there are lots and lots of other important considerations you need to address before you can create a deployable process application that will automate all or part of a business process and help people work more effectively.

At the risk of repeating what you may already know, the design elements commonly needed within a process application but not addressed at all by BPMN include:

• Logic associated with providing integration links to back-end systems and data sources
• Task form and other user interface definitions
• Logic to define task management (task assignment, delegation, escalation)
• Specifics of calculations and other important rules and algorithms that are separate from the conditions you specify in BPMN gateways
• Definitions of performance monitoring models, KPIs, reports and dashboards.

This isn’t an exhaustive list, but even the items above add up to a pretty comprehensive set of things you need to deal with to get to a deployable process application.

Most of what I’ve heard in discussion around this point focuses primarily on implications for the time to deliver projects: in other words, don’t think that once you’ve created a BPM and model you're even close to a finished application for real-world deployment. However there is a bigger issue at stake here, which is: exactly what kind of provision a given BPM technology platform makes for the specification of those items in the list above—and, specifically, to what degree you’re encouraged to design and (when necessary) code these items so that each kind of concern is kept separate from all the others.

The quality of this "separation of concerns" in design might not make a huge amount of difference when you first start in implementation, but it can become incredibly important over time. And support for it turns out to be one of the most important (to my mind) differentiating points between BPM technology platforms.

Of course, because almost all BPM technology platforms centre implementation work around a graphical process model there is always likely to be a clean separation between definition of process and all of the other important design elements I’ve listed. But whereas some platforms provide a rich, well structured asset repository and clean design tools that implement the principle of "a place for everything, and everything in its place", other platforms really provide quite weak facilities of this kind. With this latter group of platforms, it’s still theoretically possible to create process applications that are relatively easy to maintain; but designers and developers are going to be pushing against the tools available rather than working with them.

Easy process application maintainability is of course one of the key parts of the BPM technology value proposition! Without the right tools, the cost and risk of managing and improving business processes in an operational environment just aren’t as easy to control as they should be.

It’s interesting to me that there’s very little attention paid to this issue in BPM technology vendors’ marketing literature; instead, vendors prefer to focus on sexy things like support for mobile devices, integration with social collaboration capabilities, cloud-based deployments and so on. When we examine BPM technology offerings in our detailed assessment reports, though, the architecture and philosophy of the of the toolset and platform in relation to application maintainability is one of the main things we dig into.

If you’re interested in finding out more about our assessment approach, you can get access to our assessment guide reports for free here and here. You can also see overviews of our most recent versions of our in-depth reports here.

What’s your view – how important do you think the principle of "a place for everything, and everything in its place" is in BPM implementation?