IT-Analysis.com
IT-Analysis.com Logo
Business Issues Channels Enterprise Services SME Technology
Module Header
Craig WentworthMWD Advisors
Craig Wentworth
16th April - Egnyte the blue touchpaper...
Louella FernandesLouella Fernandes
Louella Fernandes
11th April - Managed Print Services: Are SMBs Ready?
Louella FernandesLouella Fernandes
Louella Fernandes
11th April - The Managed Print Services (MPS) Opportunity for SMBs
Simon HollowayThe Holloway Angle
Simon Holloway
11th April - Intellinote - capture anything!
David NorfolkThe Norfolk Punt
David Norfolk
11th April - On the road to Morocco

Blogs > MWD Advisors

Developing process applications: a place for everything, and everything in its place
Neil Ward-Dutton By: Neil Ward-Dutton, Research Director, MWD Advisors
Published: 3rd February 2012
This work is licensed under a Creative Commons License
Logo for MWD Advisors

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?

Advertisement



Published by: IT Analysis Communications Ltd.
T: +44 (0)190 888 0760 | F: +44 (0)190 888 0761
Email: