Fantasy of the No-Code Utopia
Fantasy of the No-Code Utopia
The declared ability to build large complex workflows without code seems like fantasy. Will a ‘no-code’ solution work in your organization?
No-Code Solutions
There has been much talk about workflow engines introducing no-code or low-code solutions into the market. This comes with the declared ability to build large complex workflows without having to or even know how to develop code. This is appealing to many because it opens up the possibility of building workflows to a wider group of people, especially to those who understand the workflow of the organization the best. Many organizations do not even have any developers which either essentially deprives them of any workflow automation or they must depend on the services of some external third party.
Of course, this no-code utopia is a fantasy. Complex logic and management of workflow state will always be better when written in code. And very often, business logic can get complicated. Trying to capture this logic in a pretty workflow diagram results in overly complex workflows that are worse to debug than pure code solutions and are even harder to understand. This does not mean that visual workflows are not useful. It just means that they need to be used to their specific advantages.
The Appeal of Workflows
Workflows do bring in a few definite advantages over code. The primary advantage is the ability to visualize how all the parts are connected together. It provides a clear comprehensible diagram that shows the flow of information through a job. These diagrams can be built interactively with the ability to create new flows out of existing logic and components.
While code is very good at handling complex logic and accessing complex digital storage, it is often written in a way that makes rearranging that logic for different purposes difficult. A workflow platform that encourages reusable components enforces a structure so variations of useful workflows can be built visually.
Finally, a workflow engine should have the inherent ability to track progress. Although there is nothing stopping custom code from track progress, it is code that must be added in. With development deadlines as they are, these are often the last to be implemented.
Writing Code
The primary advantage of writing code is that it can handle any level of complex logic. This is time tested over many decades of evolution of development and it provides limitless flexibility, ensuring that the only constraint is effort. There is a large body of talent who are capable of developing custom software.
The disadvantage of writing code is that within any given organization, only a select few are able to understand the code. This poses a significant risk as the organization is dependent on a small group of people to ensure that the operation runs smoothly. Often resources are very limited so changes required to match the actual working environment are delayed.
Unlike visual workflows, logic in code is very difficult to visualize. Even if the code is well written with highly reusable components, one still has to look through the code to understand what is going on. It still takes some effort even if one is a developer, however, it is completely out of reach to non-developers.
Effective use of Workflows
A workflow engine should orchestrate services and people. It should not micro-manage them. No-code / Low-code solutions can often eliminate the greatest advantage of using a workflow engine. Workflows diagrams become increasingly complex in order to support complex logic with small component nodes. This results in a unwieldy large number of nodes dealing with insignificant bits of logic required to drive the workflow. The workflow is no longer a visual tool in understanding how the components are put together. The technical requirements for building a workflow now required a specialized technical person to build them.
Furthermore, since developers would rather program than put together workflows, that technical resource is lost. The limitations of coding visual coding have been present for a long time and developers really don't want anything to do with them. They would rather use their familiar tools to build up the logic.
The workflow becomes:
So bloated that it loses its visual understanding
Requires a specialized technical person to build them
Alienates developers who don't want to work with yet another platform.
How workflow should be used
This is not to say that workflows are useless. They should just not be used to express every bit of logic. Keeping workflows as simple as possible so that they are visually understandable ensures that they are used for what they have clear advantages for, which is to provide both a high level view and to execute the orchestration of the overall information flow. The complex details should be embedded into flexible and reusable components as code with clear, easy to use interfaces.
Exactly what this level of detail looks like is dependent on the organization. At some level, having good simple predefined process nodes goes a long way. Workflows should start simple and be quickly usable. A common mistake often made is to try to capture too much in the initial implementation of a workflow. It is often best to start with the simplest workflow, possibly one that is just a set of linear processes.
Why bother with a workflow engine if all it is used for is a set of linear processes? The most important part is that this simplicity does allow for non-technical people to create workflows. It provides them a low technical means or creating a set of predefined steps that need to be done and approved before the completion of the job. This also provides transparency, accountability and tracking to the whole organization, something that is often missing at the executive level.
If complex logic is at times required, then it doesn't automatically mean that the entire workflow engine should be thrown out so that development of code can occur. It means that the developer should create a reusable component that can be easily dropped into any workflow by a non-technical person. If this is not possible, then either the component has not been well defined or there is already too much logic embedded in the workflow itself.