Traditional vs Modern BPM - why should I care?

Traditional BPM vs. modern ... what is this about?

In this article I'd like to touch a bit BPM in general and how it evolves to mainly ask the question - should I still care about BPM? Hmmm ... let's look into it then...

Proper business context put on top of generic process engine (or case management) is complete game changing activity. Users don't see this as a huge "server" installation but instead see what they usually work with - their domain. By domain I mean naming convention, information entities etc instead of generic BPM terms such as:

• process
• process instance
• process variables

Instead of trying to make business people (from different domains, sometimes completely unrelated) to unify on the terminology and being process engine/bpm oriented, modern BPM solution should aim at making themselves being part of the ecosystem rather then be outsider. This does make a lot of sense when you look at it from end user point of view. In many cases end users would like:

• to feel comfortable in the system that supports my daily work
• to understand the terminology used in the system - non IT language preferred 
• to be able to extend its features and capabilities easily 
• possible to federate with other systems - aggregated UI approach 

these are just few points and I am sure many business users could come up with quite a long list in this area. 

Nevertheless, what's is the point here? Main one is to not look at BPM as traditional setup anymore but use it to innovate your domain by utilizing the knowledge that is present in each and every coworker in your company. The assets that modern BPM should promote is collectively gathered knowledge of your domain and the way you work to make profit. 

I used term 'traditional BPM', what I mean by that is rather big and complex installation of BPM Platforms of any kind. A centralized servers that are meant to do all the heavy lifting for entire company without much of an effort ... at least that what slides say, right? :) Traditional BPM that aimed at solving all problems did not really paid off as it was expected mainly due to complexity it brought. It had few major drawbacks identified throughout number of years:

• difficult to learn - usually a big product suites
• difficult to maintain - complexity grow with deployments on the platform where upgrades or maintenance activities become harder and harder
• difficult to scale - usually because of chosen centralized architecture (which btw was meant to solve the problems with maintainability)
• generated components had their limitation - first thing that end users end up with was the UI components were either tightly coupled to the product or not powerful enough

Traditional BPM

Due to those BPM initiatives in organizations were usually expensive and time consuming activities. Moreover, many of them failed to deliver because of the outweighs between expectations/promises and the actual capabilities of the product/solution.  

BPM projects often made a promise to bridge the gap between IT and business but in the end (one way or another) IT took control and drifted away of business making the delivered solution not so business focused any more. Some of these were caused by the limitation mentioned above but some were because the chosen architecture was simply not suitable for the needs of the business domain. 

I keep saying "business domain" or "business context" and I really mean it - this is the most important aspect of the work when dealing with business (ops ... I did it again) knowledge. The key to the success is the knowledge to be used in IT solution and not vice versa (IT solution altering the way business is done to fit the product/technology).

So if the traditional BPM does not meet its promises, should I still care about BPM at all?

The short answer is yes, though look for alternatives on how to use BPM - as I call it modern BPM. The slightly longer answer is - traditional BPM did have a success stories as well so it does provide a solid ground for next generation of BPM solutions. It did give proper and stable specifications:

• BPMN2
• DMN
• CMMN

to just name the few. So conceptually it is still valid and useful, what is more important is how it is actually realized. The modern BPM is about scoping your solutions to the domain, in other words proper partitioning of your domain will help you solve or overcome some of the issues exposed by traditional BPM. 

First and foremost principles of the modern BPM is

avoid centralization 

Don't attempt to make huge "farm like" installation that should deal with all your processes within the organization (regardless of its size) - sooner or later it will grow ... Keep it small to the minimum to cover given domain or part of the domain. If your domain is Human Resources think about partitioning it to smaller pieces:

• employee catalogue 
• payroll 
• absence 
• contract management
• benefits and development plan
• etc

with that separation you can easily

• evolve in isolation
• maintain separately - upgrades, deployments etc
• scale individual parts
• federate systems to build portal like entry points for end users
• use different technology stack/products for individual parts

always put things in business context

keep in mind why things are done the way they are - that's because of business context. If you understand your domain make sure it is captured as knowledge and then used within the IT solutions - this is where BPM practices come in handy. That's the whole point of having BPM in your toolbox - once the business knowledge (business processes, business rules, information entities) is collected it can be directly used for execution.

make tailored UI

Make use of any tools/frameworks/etc you have available to build state of the art tailored UI for the domain. Don't expect generic platforms to generate complete and comprehensive application for you - reason for that it most likely the platform does not know the domain so what it will provide might be limited. Though don't throw away that idea directly, this might be a good start for extending it to fit your needs. All depends on your domain and business context ... I know again :)

Modern BPM

To summarize, modern BPM is about using the tool in more modern way but still the same tool - process/rule engine. Although the tool needs to be capable of doing so - meaning it should be suitable for lightweight deployment architectures. That can easily scale and evolve but still provide value to the business in a matter of days on both months or years of IT projects. 

Next article will give an example of such system to show what can be done in less than a week of time... stay tuned!