No-Code vs. Low-Code, Turing Completeness, and Conway’s Law
Learn how no-code, low-code, Turing completeness, and Conway's law can all come together to form a collection of services suitable for a variety of use cases.
Join the DZone community and get the full member experience.Join For Free
No-code facilitates the reuse of predefined components, typically using a drag and drop interface or a web form. Such platforms always include things like identity and access management, and most importantly don’t require any code to stitch components together, therefore reducing the need for engineers to spend time architecting databases, APIs, or internal workflows. They are always related to one particular task and audience, like web development, spreadsheets, analytics, market automation, etc. Airtable, Zapier, Webflow, Retool, Waylay Digital Twin solution, and similar apps can be found in this category.
On the other hand, low-code has a different set of goals and user personas in mind. The major misconception about low-code is that the “low” in low-code means that a person with hardly any knowledge of coding is the user of such a platform.
In my view, the goal of a low-code platform is to enable developers to code and deploy their apps at a very fast rate, with minimal setup effort and with the added confidence in what the platform provides out of the box. In that sense, a low-code platform reduces the complexity of the application development process, shortening the time to market. The basic building block of the low-code platform is usually a small snippet of code, wrapped as a reusable component that is applicable across different use cases, just like a Lego brick.
No-Code vs. Low-Code
So, how does that differ from no-code, which is also about “stitching” components (code snippets) together? First, low-code should allow developers to develop and publish new components, which requires coding. Second, the platform must allow these code snippets to be connected and synchronized in an async manner, which is not as trivial a problem as it sounds.
There are two ways to look at the second challenge. The first way is to create a vertical-specific low-code platform, which limits what “low coders” can do by providing them with a safety net in the form of a predefined way on how stitching should be done, leaving no room for mistakes (or maneuvering, depending on how you look at it). Since this is driven by a “make the common case fast” philosophy, it also limits possible uses, as anything more challenging or not envisioned by the tool provider becomes hard, if not impossible, to do. If the purpose of the end application deviates even slightly from what is provided by the predefined components, one has to write extensible code or re-write the component entirely. Most low-code platforms require coding in specific languages, sometimes proprietary ones, making the achievement of the end-goal even more complex.
The second way is to provide a horizontal, general-purpose low-code platform, which facilitates the creation of custom components (using code) and provides the engine, the APIs, and the user interfaces required to combine and execute them as part of the bigger application. This approach brings more flexibility, with the caveat that vertical aspects need to be built on top, with a slightly larger effort (as the platform concepts are domain agnostic). In the next section, we are going to discuss why we believe this to be the better approach in the long run.
Turing Completeness: Its Relation to Low-Code and RPA Tools
Experienced developers and system architects are always skeptical when they hear about yet another model-based low-code platform. They feel that soon they will discover “gotchas” — instead of frameworks helping them with implementation, they will need to work around the limitations imposed by them.
There is a term used in computability theory called Turing completeness. If somebody says, “My new thing is Turing complete,” that means that in principle it could be used to solve any computational problem. Software languages are Turing complete. When serverless hit the mainstream, it was widely accepted that serverless was the best candidate for “the low-code lego brick approach.” And that brings us to the story of Turing complete automation. If we are to use code snippets to implement the application logic, we need an extremely powerful and flexible rules engine that can orchestrate them without needing to result back to coding all that in a programming language. Otherwise, we would lose the low-code benefits entirely.
So, why believe Waylay could be your answer? First, like many solutions in the RPA space, the Waylay platform comes with a broad collection of components and services suitable for a wide spectrum of use cases, like a Swiss Army knife. But what makes it stand out is its “secret sauce” — the most powerful rule automation engine, which can orchestrate these components in an almost Turing complete way, while still providing a low-code experience. That's the difference that we are bringing into the market!
Any organization that designs a system (defined broadly) will produce a design whose structure is a copy of the organization’s communication structure.
— Melvin E. Conway
Waylay is a purposefully built OT/IT automation low-code platform. It is also a place where many personas meet: OT specialists, IT folks (serverless coders, integration architects, backend and frontend developers), data scientists, and business owners. Having them converge at one single “platform place,” where they can collaborate, contribute, and deliver a solution together, sounds like Mission Impossible.
If we are to defy laws of physics, in this case with Conway’s law, we must take into account that each of these personas has different expectations and knowledge about low-code/no-code and, moreover, that they are not necessarily interested in reading such long blogs in order to catch the semantical difference between these two concepts. Therefore, let us look back at personas and what Waylay has to offer to each of them.
Frontend and Backend Folks, and the Rise of Serverless and Integration Architects
To use a stereotype, frontend folks are all about React/Vue, webpack, CSS, and user experience. They are not necessarily interested in all the nitty-gritty details that happen under the hood. They closely work with business owners and make sure that everything looks pretty and usable. For them, the low-code platform means nothing, as they will interact with it using APIs that already provide a high-level abstraction. They dislike no-code even more, as any great user experience and any beautiful vertical app are impossible to deliver using no-code tools alone.
When integrating our rules engine into your automation scenario, it is well possible that some of the input arguments to run a task might come from another database or application. In order to avoid hard coding the mapping between input arguments and templates in your application (such as an email address for one specific sensor), Waylay comes with the concept of template variables, represented as a JSON schema associated with a template. This allows the template creator (e.g. the integration architect) to specify upfront which input arguments are required at runtime, which makes building frontend applications on top of it very easy, as there are many form builders that work out-of-the-box based on JSON schemas. With this feature, customers can build their own no-code applications on top of the templates in no time.
How about backend people? In my view, backend in the classical sense with a LAMP stack and monolith is fine — if you are fine with it, too. Still, we believe that in the modern era of cloud computing, this job will disappear and will be replaced by other roles, such as DevOps, serverless coders, or integration architects.
In Waylay, we entertain the last two roles: serverless coders, who know everything about APIs, and code snippets wrapped as reusable components, typically not longer than a dozen lines of code. For integration architects, it is a fun dream come true, as they leverage these components to capture an end-to-end flow as a template in a true low-code way. The same playbook feature that targets the no-code part in the frontend enables them to put a polymorphic spin on the template, further enhancing its flexibility.
OT people know everything about SCADA, PLCs, machines, and industrial processes. These are the folks from the trenches. They often feel rather agitated when the other personas talk about IoT, feeling that they are trespassing in the realm of their experience and deep knowledge built over the decades — something you can’t grasp and “teach yourself” in just 21 days. They prefer problems to be defined using more or less casual relationships — that is to say, create automation rules based on knowledge modeling techniques, and if needed, enchanted by ML, but not the other way around by having black box models going beyond running anomaly detections and predictions to guide repair actions, etc.
For them, the rules engine enables them to mix their own experience and expert knowledge with the latest advances in cloud technology. Still, they often lack coding skills, so if we want to bring these people in, we often need to pair them with integration architects and/or data scientists.
Here I noticed a little bit of a generation gap. Younger data scientists are very good at Python, as in this respect, University curriculums have been heavily influenced and improved over the last decade by the needs of the industry. Previous generations are still more comfortable with either Matlab or only no-code tools.
Now there's something for both groups. We can deploy machine learning models from all state-of-the-art machine learning frameworks — such as sklearn, TensorFlow, PyTorch, or XGBoost — and perform inference on live or historical data. Deploying machine learning models using Waylay APIs or our Python SDK is a rather simple task, but it still requires some level of knowledge of machine learning concepts and coding, like Python and Jupyter notebooks.
Nevertheless, when data scientists work on a particular use case such as anomaly detection or prediction modeling, they are faced with other challenges first that need to be addressed before even reaching the low-code platform:
- Which type of ML algorithm should be used for this problem?
- Which ML platform fits the problem best?
- Is the quality of the data good enough to solve this problem?
For instance, we deal with the question of how we can enable data scientists to create a machine learning model without having experience in programming. As mentioned earlier, no-code platforms are applications that enable non-technical users to build applications, or in this case ML models, by dragging and dropping pieces of software or data on canvas. These ML/AI platforms enable users without any previous coding experience or even machine learning knowledge to build a machine learning model starting from a dataset using no-code.
With BigML, as one example of this kind of AI platform, you can create a machine learning model from scratch in a simple way, without needing to know a lot about coding, using their dashboard (no-code) or their Python SDK (low-code). Through this application, it is possible to experiment with a certain dataset, try out different ML algorithms, and fine-tune hundreds of hyperparameters.
It is important to satisfy the next question that happens after the model has told us something (like when there is an anomaly on that machine), the question of "What now?" This brings us to the next persona in line: the business owner.
Business owners don’t care about coding, and why should they? But still, the idea of a citizen developer attracts them. The idea that everyone in the organization is empowered to contribute and deliver working software in a shorter time is the dream of every business owner. No more need to talk to all these terrible software people or set up long and expensive integration projects!
In my mind, until we get NLP integrated into the automation creation, this remains, to a certain extent, wishful thinking. For business owners, the best use of the Waylay platform is to pair them with integration architects on the one hand, and frontend developers for finalizing the user-facing application on the other.
Biggest Challenge in Building OT/IT Low-Code Automation Tools
What we can see from this analysis is that the two most important persona groups in any OT/IT adoption cycle, business owners and OT people, can’t do anything without help from integration architects or serverless developers. That’s where the challenge lies.
In Waylay, next to the low-code automation tool, we also offer the no-code Digital Twin solution which is primarily focused on business owners. It doesn’t suffer from this problem as it is completely sandboxed within the Salesforce ecosystem. It is simple and powerful, yet it is limited to a particular use case, as is always the case with no-code tools.
The Future and NLP
Is it possible to solve the problem of no-code automation tools in a new disruptive way? As we all witness, CodexAI is about to disrupt the entire software development industry. You type a sentence and code is produced.
At Waylay, we are already working on the prototype and have filed the patent for NLP-based automation. This is a true no-code-based solution, which in the first instance will be limited to things that are more or less the voice control equivalent for rules invocation. A more ambitious approach that we are also working on is automatic rules generation based on capabilities discovered in libraries of sensors (Machine X, if the pressure is > 100 and temperature > 40 then create a Salesforce ticket and send SMS ticket to John) which will be voice fingerprinted for future audits. That way, we envision a not-so-distant future where we will empower OT/IT personas to make use of Waylay by simply expressing their intents using natural language, via voice or similar devices, that generate free text.
Lately, we've been making advances in respect to NLP due to the combination of the recent work of others in the domain of NLP coupled with our patented rules engine, which provides a powerful set of explainability features required by the industry. This enables advanced rules to be created using recent developments in the NLP domain, such as GPT-3. Waylay has already filed a patent on this topic and is already in a very advanced production stage. We are looking at the first working prototype to be embedded in our console in Q3 2021 and we're targeting Q4 2021/early Q1 2022 to bring it to the market.
Published at DZone with permission of Veselin Pizurica, DZone MVB. See the original article here.
Opinions expressed by DZone contributors are their own.