Workflow Development: How It All Began …

D Melnik
3 min readMar 28, 2019


We have been developing workflow management solutions since 2011 as an outsourcing company, but only in 2015 we successfully launched our first product. We’ve made great progress since then, gained a lot of experience, and at the moment at OptimaJet we offer three key workflow management solutions — Workflow Engine, Workflow Server and DWKit. Since 2015 we have received more than 700 requests from different development teams and are planning to implement new features our customers are so looking forward to.

We feel it’s high time we told our story.

Several years ago we were asked to design a complex budgeting organism to be used by one of the departments in a huge bank. The problem was that our client was planning to restructure the department and connect employees from other departments to its system. In other words, our job was to develop a document approval workflow within the existing project.

There were three paths for us to choose from: custom development, using any available open source solution (ObjectFlow, Stateless, Jazz, Workflow Foundation, etc.) or purchasing a workflow platform (K2, Nintex, Camunda, WorkflowGen, etc.) with existing business logic migrating to it. As for developing our own solution from scratch — that was tempting, challenging and seemed like a lot of fun, but we realized that we had no BPMN2 and no visual designer, there would be lots of errors and the instrument itself would be too complicated to support. Purchasing a platform also did not seem to be a wise decision: too costly, must be integrated with the existing software (and we know, that it’s not always possible), some training needed.

In that case option # 2 (choosing an open source project) made a lot of sense! At least we thought so at the time.

But 6 months later we were already kicking ourselves. We wrote thousands of lines of code to realize few relatively simple workflows (hello, open-source!), nothing was as easy as it had seemed in the beginning. And our client was asking for more, and more, and more…

We were stuck. It turned out that no open source product we were able to find could actually solve our problems. Parallel document approval workflow between employees was functioning, but that’s about it. It was impossible to update approval and version control routes without upgrading the application. There was no dynamic set of steps for each document and graphic process designer did not work in admin mode.

That was the moment when we decided that we should build a solution of our own. We needed a component that would include an HTML-5 designer, basic set of elements, business terms (Command, Role, Transition), process schema updates in current version, inbox/outbox folders for each user and process simulation. And that is how we created Workflow Engine.

It proved to be a most efficient workflow tool, which allowed us to avoid many development errors, but we were still dealing with WinForms and wasted a lot of precious time on creating forms and changing data models (any minor change implied modifying several data layers and recompilation). It was obvious that we had to modernize our existing project, but it was impossible to rewrite the project afresh.

I’m sure you know how it goes: the dev team come and say something like “We need to rewrite our project based on a new technology. It’ll take 6 months and loads of money!” Any average manager in this case will be terrified and won’t even dare to pass this to the client. It is kind of obvious that it might take up to 18 months and the project will still be far from ideal.

So, once again we started looking for a perfect platform that would answer all our prayers. But that’s the story we’ll save for another day.