Low code vs no code debate. Each approach contains different characteristics which suit different personas.
No Code facilitates the reuse of predefined components, typically using a drag and drop interface or a web form. Such no code platforms always include things like identity and access management, and most importantly don’t require any code to stitch components together and 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 on 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.
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 (more about this topic in this video).
There are two ways to look at the second challenge. First one 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 mistake (or manoeuvring, depending 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 a much bigger 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 and 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 resolve back to coding all that in a programming language, otherwise we would lose the Low-Code benefits entirely.
So, why believe Waylay is the 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. More about this you can find on this link. That’s the difference that we are bringing into the market!
Conway’s law and what it has to do with Waylay
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 Conway’s law, we must take into account that each of these personas have 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, backend folks and 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 behind the hood. They closely work with business owners and make sure that everything looks pretty and usable, like in this picture. 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 beautiful vertical app is impossible to deliver using No-Code tools alone.
For front-end folks, at Waylay we offer playbooks. 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 front-end 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 Waylay templates in NO TIME. Please have a look at this video, it’s super simple.
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 API’s and code snippets wrapped as reusable components, typically not longer than a dozen lines of code. For integration architects, Waylay 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 front-end 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 IIoT, 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 like 21 days. They prefer problems to be defined using more or less causal 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 Waylay is a fantastic tool, as 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 into Waylay, 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.
Waylay has something to offer to both groups. With Waylay, 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, which 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, in this video, we deal with the question of how we, as Waylay, 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 and try out different ML algorithms and fine-tuning hundreds of hyperparameters.
Where Waylay shines is not only in respect to running ML models built using such platforms, but even more importantly, satisfying the next question that happens after the model told us something, like there is an anomaly on that machine: WHAT NOW? Which 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 wet 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, till we get NLP integrated into the automation creation (which is something we are working on), 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 front end developers for finalizing the user-facing application on the other.
The biggest challenge in building OT/IT Low-Code automation tools and what can Waylay do about it
What we can see from this analysis is that 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.
When it comes to solving that challenge, there are two schools of thoughts. One is AWS way, which in a way reminds me of an old SAP business model: make things complicated and make sure there are enough incentives for system architects and companies to provide end to end solution on top. Unlike in good old days, cloud based solution come with yet another challenge that the final solution also impacts the OPEX cost, as the usage/volume component drives most of the running cost in production.
UI is how it looks. UX is how it works.
Another approach is "Apple like" approach and Waylay IO mission is to bring Apple experiences to all these communities.
Making something looks nice is only part of the solution, ever bigger deal is when you make it obvious on how it works and how end customers integrate Waylay in their solutions. Final product also includes great documentation, well-documented API calls, excellent videos and having the right place where people can gather and share their knowledge and experience of the product. And this is what we offer:
- Low-code portal that simplifies development and deployment
- Easy integration of API enabled services
- AI/ML deployment without tears
- Excellent debugging and observability
- All necessary tools in one place
- From development to production in “no time”
- Waylay’s platform has built-in state of the art security realm similar to Auth0
- Pay per use
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, powerful yet limited to a particular use case, as it is always the case with No-Code tools.
How about the future, NLP to the rescue?
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 complete software development industry. You type a sentence and code comes out.
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 based on 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 (see video) where we will empower all 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.
The reason we believe we are ahead of the competition in this respect is not because of Waylay advances in respect to NLP, but rather 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 embedded in our console in Q3 2021, and target Q4 2021/ early Q1 2022 to bring it to the market.