What is No-code

Like most myths, this is grounded in some reality. The idea of using visual tools for software development has indeed been around for a long time. The principles behind visual computer- aided software engineering (CASE) tools were first explored as early as the 1970s. However, while the principles of visual drag-and-drop software assembly have been around for a while, the vast majority of early attempts still involved relatively specialized and complex development and architectural knowledge to set up, maintain, and use these toolsets — and they were fairly complex to apply in practice. This all contributed to low usage, except for a brave set of early adopters.

As a result, business users resorted to applying other “homegrown” tools, such as spreadsheet macros, scripting languages, or Microsoft Access databases. While these apps were relatively easier to build, they nearly always began to show performance issues, expose security flaws, or were difficult to maintain as they became more broadly used. Only recently (since the mid-2000s) has the combination of ubiquitous cloud computing, advances in software platforms, and broad adoption of modern application programming interface (API) protocols begun to truly address many of the historical challenges of software engineering in a manner that is enterprise ready. So, while the promise of no-code may have been around for decades, the act of making it simple, easy, and scalable to enterprise needs has been a relatively recent development.

This is demonstrably untrue. If you’re a software developer reading this, don’t worry — your job is safe! To help keep pace with the increasing appetite for new digital apps, it’s essential to include the business function and nontraditional developers in the development process. Given the projected explosion of cloud-native digital apps and services mentioned previously, it will take all of the DIY developers (and more) to just help keep up with meeting this insatiable app demand.

Also, there are plenty of app scenarios that will still require software developers to work with no-code teams (as part of fusion teams that will be outlined in more detail in Chapter 4) because the innovation around new software development languages and frameworks will not slow down.

Software developers will always be needed to push the boundaries of innovation because they are the ones who explore advancements and create the development frameworks or libraries before they are released as standardized components of no-code tools. Typically, there is an adoption and maturation cycle, where development approaches get tested and matured first by software developers until market demand is established. At that point, they will usually be offered as mainstream, prebuilt no-code components.

This is untrue, but many articles often mention the terms “low-code/no-code” in a single breath, leading readers to believe they are simply different flavors of the same approach. However, while they may both use visual abstractions to reduce the complexity of software development, low-code and no-code are two distinct platforms offering different benefits and are designed for different users.

Low-code platforms have evolved from previous concepts of “Rapid Application Development,” and they don’t attempt to replace programming fully. Instead, they lower the amount of code that must be written (hence the name). Typically, this means that the user of low-code is still a developer of some type, albeit perhaps a more junior one. One of the major benefits of low-code is the ability to make less experienced developers productive easily — they can quickly adopt a standard framework and tools that avoid many of the common pitfalls or complexities that one can face with professional development. However, at the core, there is an inherent learning curve and complexity to low-code, as it still essentially offers a value proposition to IT that enables the development of custom software. Knowledge of proper application design and architecture and some lightweight coding knowledge (typically, JavaScript or some scripting language) is needed to build a low-code app.

No-code platforms, in contrast, are intended to be used by nondevelopers, which means that they attempt to fully remove the need for coding when building apps. No-code users typically sit outside of IT, usually inside a business unit or functional team, which will be explored in greater depth in Chapter 4. As such, the benefit of the no-code platform is that it speaks the language of the nondeveloper — typically focusing on allowing the no-code creator to model the industry domain (e.g., objects or rules) and business process (e.g., forms, workflows) using familiar terms and visual models. There can be a learning curve with the tools — as there is with any new software — but users do not need to learn any scripting or programming languages to finish building the application.

Given the differences in target users and the expectations of programming knowledge, this means that platforms tend to focus on either low-code or no-code, but not both.

This is very untrue. However, given the software development shortage and significant backlog of apps unmet by IT, it’s understandable that IT would worry that the business function may charge ahead with building apps that may be completely insecure, noncompliant, unreliable, and risk data loss or leaks. It’s also a common fear that the explosion of apps built with no-code platforms may result in inconsistencies and wasted investments and create a nightmare to update and maintain.

However, as the saying goes — “if you can’t beat them, join them” — and this is one fight that IT will typically lose if it tries to police the use of innovation. Rather than fighting the business function of building new apps, no-code platforms offer solutions for building apps while simultaneously implementing controls and governance to ensure proper use. Modern generations of no-code platforms offer the full range of governance and reporting capabilities needed to ensure that apps will have the ability to be monitored for compliance, security, and maintainability. By giving a standard set of tools for building apps that are business-friendly, it encourages the use of a standard platform that is “blessed” by IT and that can be consistently governed.

So, this myth would be true if your use of no-code is not properly managed, but we’ll provide the right no-code methodology steps as well as checks and balances to ensure proper governance, which will be covered in more depth in later chapters. This whole Playbook, in fact, is aimed at enabling the enterprise to embed secure no-code development processes into their standard practices and governance models and to help IT and the business function collaborate more effectively together.

No-code platforms indeed result in lowering the cost of building apps, which means that many lightweight app scenarios, especially ones that might not have been previously considered because of scarce development talent, can now be justified. It’s also true that the speed and lower costs of app building can result in greater exploration or ideation activities. This often results in building opportunistic apps to experiment with new ideas. These apps may start out simple to test viability and business value quickly.

However, not all mission-critical scenarios demand professional developers. An application’s level of business criticality has more to do with the selection of the business process and domain. No-code apps can be used to automate business and mission-critical processes. Suppose that the mission-critical app relies on systems of record (and most do). In that case, it may be that software developers are involved in the project to help establish some of the initial APIs and data integrations or to set up some of the more sophisticated components. But this doesn’t preclude business stakeholders from building or maintaining significant parts of the app (we will explore more on this idea of combined teams of business and software developers in Chapter 4).

While no-code definitely should apply some learnings from traditional software development, such as Agile or DevOps practices, it would be a mistake to simply treat no-code the same as other ways of development. It's important to tailor the development practices to take advantage of the unique strengths of no-code platforms, which intentionally insulate and abstract you from many details that can trip you up with traditional development. Furthermore, the fact that no-code brings nondevelopers more directly into the app-building process also means that you should expect a different set of skill sets and backgrounds to be part of a no-code team.

Tailoring the methodology used for projects is a key first step, and we’ll discuss this further in Chapter 6 when we present the No-code Methodology Framework. This no-code methodology is a scalable model that allows no-code technology to be made available to a much larger population of knowledge workers. The framework will give you the confidence to bet on this approach.

There’s a myth that no-code projects are “closed” and somehow conflict with the use of traditional software development techniques. Some believe that a no-code approach constrains you to only using no-code tools and, therefore, may not be suitable for more complex types of enterprise applications. However, as outlined above, no-code development can address a wide spectrum of application types, from simple to mission-critical. The fusion team approach that we will discuss in Chapter 4 allows participants with different skills and from different domains to distribute tasks and collaborate on building and launching apps. Fusion teams include both no-code creators and software developers and represent a very efficient and synergetic way of delivering enterprise-grade applications using no-code.