I've recently been asked to prepare a BPM[1] architecture. I was vaguely aware of BPMN[2], but never came across a BPM before. I've had colleagues tell me that they were on a BPM intensive project. It needed real knowledge and seemed to be an expert thing. As for my consultancy company, BPM skills are great because of the complexity they induce and the niche it creates. They were proud to be able to provide such an expert. Two years after, the same developers got off the project because it had gotten out of hand and were fed up with its complexity.

A-Typical-BPM-Workflow

The project along with the BPM technology had abandoned its original promise.

Allow non-technical users to write business functionalities without asking a developer to do it.

A Business Analyst's dream

Imagine being able to make software without developers. Seems wonderful! No more pesky developers to depend on for getting real work done. Who better than business analysts to write down business needs and have them get executed in production? Imagine the time to market gain with such a perspective; Get requirements directly from the business analyst's brain into production!

Okay, we all know how that will end up. Edge cases, security aspects, performance issues, and incomplete requirements are all things that are likely to ruin this dream. These pesky aspects require a developer's perspective and expertise. Such that in the end, the BA[3] friendly tool will be handed over to a developer, while the BA goes back to his/her comfort zone. The developer is left alone with a tool which is unfit for development. And by that, I mean that basic requirements of a developer's work such as versioning, unit testing, scripted deployment and collaborative work are a nightmare if ever possible. Also, these types of tool tend to be graphical, which means that refactoring tasks are inapplicable.

Good marketing

It's not the first time I've encountered this type of promise, sold by tech ignorant salesmen to even more tech ignorant managers. I've heard it before for ETL[4] tools such as Talend, or for code generators the like of Model Driven Architecture. Don't get me wrong, Talend has its uses, but only for small, disposable and uncritical needs.

Reality

Once this type of tool is used, it is so monolithic in its design, that it is impossible to remove it. Some may say that it resembles a framework in many aspects. I came across this Twitter thread about BPM engines.

Screenshot-2018-3-19-Sam-Newman-on-Twitter-1-

I still think BPMN is a good thing for communicating about business processes, but BPM engines are more questionable. Although I've seen one that looks to fit in with Domain Driven Design. This means that BPM is invoked by the application and not the other way around. If the application represents a bounded context, the scope of a BPM process may not be larger than the context it fits in.

If the collaboration between bounded context needs to be represented with BPM, it can also be done, but it must be externalized.

TLDR; False promises

All in all, vendors whose leitmotif and promises are about selling a product that allows non-technical users to do a developer's job are toxic. There should be a warning sign that goes on every time you think you can build software without writing code. I'm not saying some things can't be done without any coding, but they are either very limited and/or full of constraints (if you can live with them take the opportunity). They come with a lot of commercial configurations, training, and probably expensive specific upgrades. Most of these systems have a lock-in as part of their business model. They are difficult to get out of: think SAP, Salesforce, and AWS for example.

My advice is to stay away from these types of systems altogether.

Comments are welcome in the Disqus below.


  1. Business Processing Model ↩︎

  2. Business Processing Model Notation ↩︎

  3. Business Analyst ↩︎

  4. Extract Transform Load ↩︎