We’re planning an open-source BPM migration, and one thing that keeps coming up is whether our business analysts can actually build and test workflows themselves, or if we’re going to be bottlenecked waiting for engineers to implement everything.
Right now, EA analysts spend a lot of time documenting processes and then handing them off to engineers, who then interpret the requirements and build the workflows. The handoff always loses detail. Miscommunications happen. Rework cycles are endless.
I’ve been looking at no-code and low-code builders that supposedly let non-technical people build workflows directly. The pitch is that analysts can iterate quickly, test assumptions, and actually move the migration decision forward without blocking on engineering bandwidth.
But I need to know: is this realistic? Can an analyst actually open a visual builder, construct a workflow that represents a real business process, and iterate on it without constantly hitting walls where they need a developer to fix something? Or is this one of those things that works for simple use cases but breaks down when you hit complexity?
Visual builders let analysts prototype. They won’t replace engineers, but they eliminate handoff delays. That’s the win.
I watched our business team move from two-week approval cycles to two-day iterations using a visual builder. They handle the logic and validation. Engineers handle integrations and edge cases. The separation actually works because it’s clear where the boundary is.
The key is training analysts on the platform first. They need to understand what’s possible and what isn’t before they start designing workflows. Once they know the constraints, they move fast. We saw prototype turnaround go from weeks to days.
Complexity doesn’t kill it. What kills it is unclear requirements. If an analyst understands the business logic and can describe it clearly, the builder handles it. If they’re vague or keep changing their mind, the builder just makes the rework cycle visible earlier, which is actually good.
One more thing I’d emphasize: the no-code angle only works if the platform is actually intuitive. I’ve used builders that claim to be no-code but really just move the complexity around. You want a tool where an analyst can look at a workflow and understand what it does without needing a developer to explain it.