Three pros and cons of BPM microservices

While microservices architecture - a new approach to building applications - is emerging as the next step in business process management (BPM) application development, it's not a step to be taken lightly.

That's the view of Steve Weissman, founder of Boston, USA-based process improvement and information governance consultancy, Holly Group. He points out that BPM has been undergoing significant changes in approach over the years, not least of which has been a shift from what he calls "monolithic solution with baked-in user directories, rules engines (and) messaging backbones" to more a more modular approach that allows for the mixing, matching and leveraging of Web services and interoperability mechanisms.

He points out that BPM application development is highly complex, usually having to accommodate wildly different user devices, several generations of database and document technologies, multiple media types and uncertain bandwidth capacities.

Microservice architecture is defined as "a method of developing software applications as a suite of independently deployable, small, modular services in which each service runs a unique process and communicates through a well-defined, lightweight mechanism to serve a business goal". The microservice architecture enables the continuous delivery/deployment of large, complex applications.

According to Weissman, from a general application development perspective, the advantages associated with building applications by building microservices are rooted in the isolation of individual capabilities within individual microservices.

Essentially, Weissman maintains, they represent the logical next step in the journey from monolith to module for BPM, taking componentisation of complex BPM applications to the next level and enabling the wringing of extra benefits from what, he says, is a somewhat tired technology.

Applied intelligently to BPM application development, microservices can:

1. Effectively "stream" functionality on demand. Unbundling specific functionalities from one another can open the door to anticipating and preloading process next steps in the same way that Web pages get queued up.
2. Mask process interruptions by insulating the moving parts from each other. A fault in one section of the process would not necessary bring the entire process to a halt.
3. Make it easier to deal with unavoidable change by being able to add new capabilities without having to amend the core application. This flexibility not only reduces the technical difficulty of changes in business workflows, it also reduces cost.

However, before jumping on the microservices bandwagon for BPM, Weissman warns that there are certain caveats that should be considered:

1. There are still no confirmed standards that govern how microservices talk to each other. You could therefore end up making a commitment to an approach that ends up falling by the wayside.
2. The simplicity wrought by microservices, could also contribute to unexpected complexity. Having separate modules or strands for each component of a task, means that there are more modules or stands that would have to be checked if that task stops working as it should.
3. There could be a limited on how far you would be able to go in distilling each function into an independent microservice before the effort required does not deliver the anticipated returns.