Our bank runs nine BPMN orchestration processes in production. It now also runs five flow-based orchestration processes in production, on the same runtime. Some people are surprised to learn they are the same product with two different authoring experiences. This is the post explaining why we did it that way and what we learned.
In 2022 we picked a BPMN-style process orchestration platform to run the serious end-to-end workflows at the bank. KYC refresh. Customer onboarding. Core reconciliations. The BPMN designer was a good fit for these, because business analysts could read the diagrams, auditors could trace approvals on the diagrams, and risk committees could sign off by pointing at shapes.
This worked for the workflows it was designed for. It did not work for our developer teams.
Our platform team and our growing population of developer-adjacent automation engineers wanted to build orchestration the way they build anything else. In code-adjacent structures. With version control as the source of truth. With a runtime feel closer to an actual program than a drawing. They were not interested in clicking through a BPMN palette. They wanted to express a flow as, well, a flow.
So they did what developers always do when the approved tool does not meet their needs. They built it around. We found bot developers hand-rolling orchestration logic inside individual bots. We found platform engineers writing stateful code to simulate what our orchestration engine could already do if they would agree to draw a diagram. This was bad for a lot of reasons.
The obvious path was to tell developers to use the BPMN designer and move on. We could have enforced it. We did not, for three reasons.
First, the BPMN designer is the right tool for the analyst audience and trying to make it also the right tool for developers would compromise both. Second, hand-rolled orchestration was giving us observability gaps and operational risk that we could see in the incident numbers. Third, the vendor we had picked offered a new flow-based authoring experience on the exact same runtime. It was not a separate product. It was a different front door into the same house.
That third point is the one that actually made this decision easy. If the two experiences had been separate products on separate runtimes, we would have said no. Maintaining two independent orchestration platforms at a mid-size bank is a recipe for divergent implementations and a five-year migration project down the road. But because they shared a runtime, a deploy pipeline, and an observability model, we were effectively giving developers a different IDE for the same engine. That we could commit to.
One runtime, two authoring experiences. Analysts get diagrams. Developers get flows. Auditors still trace the same execution. This is not a compromise. This is the shape the problem always had.
A few things that matter for anyone evaluating a similar setup.
The authoring experience for flows feels like writing code adjacent to a canvas. You can look at a visual graph of the flow when you want to, and you can work in structured code when you do not. The two views stay in sync. Neither is the source of truth in a way that leaves the other stale.
Deploys happen through the same CI pipeline as our BPMN processes. Same gates. Same rollback tooling. Same observability surface. If I am on call and a flow fails in production, I do not have to switch tools to investigate. The trace looks the same whether it came from a BPMN or a flow.
Generation of starter flows by our coding agent works surprisingly well. This was the part we were most skeptical about. The agent does not replace the engineer. It does produce a workable first draft of a flow when given a clear brief, and that draft saves our engineers the tedious part of wiring up the common primitives. The engineer then edits, challenges, and ships.
Here are the fair pushbacks we got internally, with what we said.
Will developers and analysts diverge? Maybe. We mitigate this by making flows visible to the BPMN surface as well. Analysts can read a flow as a graph if they want to. Developers can read a BPMN as a structured artifact if they want to. Same runtime means the artifacts do not fork.
What if the vendor deprecates one of the two authoring experiences? We think the shared runtime insulates us. If the authoring surface changes, our investment in the runtime, the processes we have modeled, and the observability we have built all carry forward. This is the benefit of betting on the engine, not the editor.
How do you avoid fragmentation in engineering style? A very short style guide. A reference implementation for each common pattern. Code review across both BPMN and flow authoring. A shared rotation that touches both. The trick is not letting the flow team become its own tribe.
The 4x number is the one I get asked about most. It is measured by cycle time from "spec agreed" to "shipped to production" on our last eight dev-owned workflows, compared to the eight dev-owned workflows before we rolled out flow-based authoring. It is a real number but it is specific to workflows that were a bad fit for the BPMN designer in the first place. If we tried to rebuild our KYC refresh in flows we do not think the number would be 4x.
If your workflow is going to be read by a risk committee, start in BPMN. If your workflow is going to be maintained by a four-engineer team shipping changes weekly, start in flows. If your workflow has meaningful branches that depend on runtime state in ways that do not draw cleanly as a diagram, skip both and use case management. We have a whole other post about that last category.
We would roll out flow authoring to the developer audience six months earlier than we did. We waited until we had nine BPMN processes live before we introduced flows, partly out of an abundance of caution about fragmenting the platform. In hindsight the split audience was a real signal we could have acted on sooner.
We would have written the style guide before we shipped the first flow, not after. The style guide is four pages long and took two weeks to draft. We waited three months before drafting it because we wanted to see how engineers were using flows in practice. This was too cautious. Four pages does not slow anyone down, and earlier guardrails would have saved two of the five flows from needing a style pass before code review.
Other than that, we are pretty happy. Five flows in ninety days is more than we shipped in BPMN in some quarters. The engineers building them are happier than they were when they were hand-rolling orchestration inside bots. And I still get to sleep through the night, which is my own personal measure of platform health.