.Disclaimer: by "architecture in the wild" I mean situations (I've personally encountered) where sheer reality surpasses known (& somehow theoretical) standards / patterns :) in a way that does not impose any obvious solution. It doesn't mean (usually) that everything is so utterly broken, in majority of cases these are completely valid scenarios. With a twist ;D.

TL;DR - microservices, low coupling, cross-functional teams, continuous delivery: we hear these terms repeated like some kind of mantra. While in fact, many companies accesses their domain functionality via BPMs & their alikes - that seem quite perpendicular to these concepts. This blog post series describes potential ways to fill the gaps BPMs were intended to deal with.

Today's dish has many names: workflows, service orchestration, business process orchestration. Let's stick with "workflow", for the sake of brevity. As it's one of these unfortunate terms that lack a single, common definition, why don't we introduce our own one? :)

Workflow - implementation of a process that spans across: services (functional modules), deployment units (technical instances), actors (process participants) & time. Workflow is supposed to have a precise state (consistent at a given moment) that contains instance-specific data.

OK, so now, when we've set some foundations for ubiquitous language ;), let's try to answer the following question:

How do we approach implementing workflows according to modern standards & principles of open architecture?

It actually makes sense to start with a dose of doubt: do we need workflows at all? They stink of distributed transactions / complex compensation rules, look like a magnet for excessive coupling & appear to clone long-forsaken idea of heavyweight ESB orchestrators.

But, in fact, large enterprises think "in processes": work is being passed between people & domain systems, manual steps intertwine with automated ones - it's the most typical mechanism of control: to split workflows into steps, set their ownership & ensure the smooth flow of tasks (for the sake of efficiency).

Big, bad & ugly (all at the same time)

How is it usually approached technically? By introducing a dedicated systems - so called BPM (Business Process Manager, e.g. Activiti, Camunda or bunch of enterprisey, expensive rubbish) that contains the orchestration logic, preferably in a visually composable way, so business people can design & "develop" processes (using integrations with particular applications / services as workflow steps) on their own.

Btw. if this sound similar to "classic" ESB (Enterprise Service Bus), it's not by accident. Simplifying slightly: ESB is BPM w/o human-facing activities.

This model may sound sensible, but it has its own (severe!) flaws, e.g.:

  1. centralised orchestration logic impedes developer's agility (ease to change, time to deliver), complicates trouble-shooting & creates a potential SPoF (Single Point of Failure)

  2. the idea of RAD-style (RAD = Rapid Application Development) visual development has failed miserably many times, same happens for all the BPMs I've seen: "code" is (ironically) hard to grok, versioning is challenging & unclear, creating any sort of compensation logic (in case of "partial failure") is a freaking nightmare.

  3. Visual composition of complex processes requires some kind of shared conceptual model / notations. Sadly, all the ones that have been proposed (incl. the most popular one - BPMN) have failed in a very similar way UML did for software design. They may be OK for some high-level drafts, but not when you're into detailed perspectives. Programming languages are models built on abstractions that have been finetuned for all these purposes for decades - nothing better was invented until this very day.

  4. if your business peeps are pushing to take over the development ("so we don't have to wait for the release", etc.), that means that something is VERY broken & your org is going for an insane workaround (by giving up all good practices of our industry), instead of fixing it.

Part II (alternatives to BPM) can be found here.

Pic: © infografx - Fotolia.com

Share this post