TOPIC:

From our latest podcast:

There is a persistent myth that you can't do complex process automation with no-code or low-code tools and there's a kernel, like most myths, of reality there. What we saw in the original flood of tools is a focus really on simplistic workflows, basic forms routing, no real ability to define in kind of a business logic. What we're seeing today in the market is the emergence of tools like FlowForma, which are able to deliver that same level of process, complexity and nuance in process flow that we would expect of what we used to call the stack or the heavy framework, also as automation tools, but delivered with a design that afford. That lends itself to the low code or no code.

Can we automate fully with just low-code or no-code tools? If not, how far away from that point are we?

Such automation in build and business operations is real and proven see the paper on what we in UK created but sadly ignored as very "disruptive" to existing self interests of suppliers and internal old "IT". The early adopter in the paper where details given has been looked after by core team. The IPR in this new approach is secure and preparing for global launch to distribute core code for international collaboration. It is just the start of a new journey for business software without need to code the business logic including workflow all done. Good news for end buyers it cannot be patented as our prior art rules as Microsoft discovered!

Yes we can now ..with no code.

What is missing in the simplistic tools is a framework on which to pin individual processes so that they make sense from a whole of business perspective. Without such a frame work you have what the CIO of Chevron Oil described as a plate of spaghetti. The chief architect of an organisation who were recently awarded recognition for their success in business transformation, put it this way, "I have 1200 processes in a cupboard."

The problem with most 'no code' vendors is that they are still building programming tools. They are solving a programming paradigm not a business paradigm. The framework needs to model the logic of business, not the logic of software development. Think spreadsheet.

We have automated whole businesses and replaced ERP software. Our first customer, a clothing manufacturer, reduced their delivery time by 80% and increased productivity by 1000%. The reason that stops most businesses from achieving this - they can't accurately define how they work. The lack of a framework is a key issue. To succeed, automation must be a strategic business issue. The CEO must lead, but you need to give him the ability to see how his business works - a top-down framework that mirrors real-life, not BPMN or some other conceptual construct. And by framework I'm really saying, model i.e. all the components of business are integrated, connected by their relationships.

Without a business logic-based framework the citizen developer will only exacerbate the problem.

Hi Anthony
You raise some good and very relevant issues which by default with our architecture as indicated in the paper are addressed.

When you build via the graphical interface direct from user business knowledge on what is required when you click to deploy it is the actual application. With the datacentric architecture all processes are automatically linked as required. It is effectively the new code and needs to be held securely “in the cupboard” and brought out to review and use where inevitable change needed. Our experience is once users and management realise that their views can now be implanted on a transparent way into a new system then defining how work delivers outcomes is easy; all in business language.

The framework we used represents the real world of work where all different types of tasks recognised and pre built just needing customised configuration as required and at a click this is declared through to the Process engine in a relational database and ready to run. No coding or compiling which enables easy change as required. Actually, easier than spreadsheet and able to handle any complexity by thinking simple step by step. Sure, if you need complex algorithms to manipulate data a programmer directed by business requirement and slots into end to end process.

You are so right executive leadership needed but our challenge was and still is how many business executives will dictate to IT? Very few if any! The digital move with the LCNC should change this but the big suppliers will not welcome.
As you will have gathered at core to delivering all has been our “business logic-based framework” and yes it really does work as exampled in our early adopters…we were at least 2 decades ahead of the game…Good to see we are no longer a lonely voice!

I'd suggest a different perspective from the one exposed by @David Chassels#. In my opinion, low-code and non-code BPM tools have advanced enough in recent years to be able to automate any real business process. That is, from a strict process perspective, there are no limitations to implement it without writing a single line of code.

From the integration point of view, there are no major limitations either. Of course, a bit more technical knowledge is required here, for example, to invoke integrations via Zapier, or WebServices. But as in the previous point, they can mostly be achieved without coding (some exceptions ahead...). This increases organization agility, and it gives breath to IT departments (specific blog post about it).

Where I think there is a difficult gap to close is in the user interface (UI). Here, it is practically impossible to design an interface that is highly customized to the organization, without coding. The better low-code BPM Suites provide simple, agile, friendly and beautiful user interfaces. That way, they mitigate the fact that they are not exactly customized to customer needs. Fair enough in many cases, and that's why this kind of application have grown so much lately. But it's definitely not enough in all cases. In particular, when complex calculations and transactions are required, it is difficult for the interface generated automatically by a non-code tool to be really good. In the same way, if integration with other systems cannot be solved by WebServices, you will also be in a scenario where the low-code tool will not meet the needs of the business. In those cases, custom development will be necessary, which will be integrated with the process engine.

In short, radical extremes are always bad. Currently, there is room for both. Low-code and non-code applications accelerate the digitalization of processes. And there are also scenarios where these tools are not enough and traditional custom developments are required.