We’ve been writing about low-code (and no-code) platforms and tools for several years now. Their appeal is obvious – instead of hand-coding apps, developers simply interact with a visual interface to assemble their applications.
Many such interfaces offer slick drag-and-drop functionality, while others use wizards or some such. Any instances where hand-coding is still necessary are relegated to isolated, minor situations, like custom widgets or bespoke integrations. Everything else, the story goes, is blissfully free from pecking out lines of code by hand.
Take a closer look, however, and it soon becomes clear that all low-code tools are not created equal. Some only tackle front-end, user interface-related tasks via low-code, leaving all the back-end tasks in the hands of hand coders.
Even more than this excess of superficiality, however, is a subtle, but more significant limitation that many low-code products exhibit – one that goes to the heart of the low-code value proposition: many of these tools don’t lower technical debt. In fact, many of them actually raise it.
Technical debt refers to the fact that fixing yesterday’s expedient but flawed technology decisions becomes more expensive and difficult over time. The problem with increasing technical debt, of course, is that sooner or later, you’ll have to pay it back. Pushing such debt into the future only racks up those interest charges.
Selecting a low-code product that lowers instead of raises technical debt, therefore, is a long-term strategic win for the organization. Here’s how to tell the difference.
Understanding the Power of Model-Based Configuration
Many web and cloud-based applications – including those that low-code tools are well-suited for – follow a basic model-view-controller (MVC) pattern.
MVC applications have three basic parts: the data (the ‘model’ part of MVC), the business logic (the ‘controller’), and the user interface (the ‘view’). Most low-code tools handle these three parts of a basic application in different ways.
Many of them have sophisticated UI capabilities but limited business logic and data capabilities. Typically, assembling a bespoke app is typically straightforward, but changing existing apps – especially when they connect with other apps – can be quite challenging.
This inflexibility in the face of change is the essence of technical debt. Even though the developer may have used low-code for one part of the app or another, when the time comes to update it, increasingly complex interdependencies limit the ability for the developer to make the necessary changes solely within the low-code environment.
At that point, they must hand-code the changes, layering on difficult to manage code which only serves to further increase the technical debt.
The solution to this mounting problem of technical debt is for the low-code platform to handle changes to each of the MVC components following a single, model-based approach. In this context, we’re not talking about the MVC ‘model’ per se. Rather, we’re referring to an abstract representation of the application that the platform represents internally as a declarative configuration that it can render as a working application.
Most if not all low-code tools follow this model-based configuration approach, although some generate executable code while others render the working application directly on their platforms. What helps certain low-code offerings to stand above the rest, however, is how they apply this model-based configuration approach to all three parts of the MVC application.
Cherwell: How Low-Code Should Work
One vendor who illustrates this consistent approach across all tiers is Cherwell. Cherwell is best known as a vendor of service management products – but in its case, it has built all its products using its low-code platform, and its customers can add or update functionality to Cherwell’s entire product suite the same way.
In Cherwell’s case, the MVC ‘model’ consists of data objects, the ‘view’ includes forms and a portal, while the ‘controller’ represents the process automations that developers can build with the platform.
Cherwell represents each of these elements as XML-based metadata, where any changes to the application at any of the three tiers involves changes to those metadata via the model-based interface.
Cherwell rolls up the three parts of MVC into applications in refers to as ‘mergeable applications,’ or ‘mApps.’ Here are the steps necessary to create a mApp:
- Define its properties and add various definitions and items that specify how to merge the mApp into the target system, say, Cherwell’s IT service management app.
- Edit the data for the mApp via the appropriate business object.
- Save and distribute the mApp, which might require the use of the Apply mApp Wizard.
These steps properly configure all three MVC tiers for the mApp via model-based configuration, and even when a developer needs to update a mApp, there’s no need for any hand-coding.
Because Cherwell is well-suited for service management applications, it is inherently workflow-centric. mApps are therefore ‘mergeable’ in the sense of merging into workflow-based applications that involve orchestrations of potentially several separate applications.
Supporting the ability to update and modify such workflows without requiring any hand-coding differentiates Cherwell from most of its low-code competition.
The Intellyx Take
The challenge with technical debt is twofold: first, organizations must reduce the complexity of existing technology in order to meet current requirements more cost-effectively. Second, organizations must put practices in place today that will continue to maintain this flexibility and cost-effectiveness into the future.
When people build applications that follow model-based configuration approaches consistently across all tiers of those applications, they are able to meet both of these technical debt challenges. Low-code platforms like Cherwell’s are showing the way.
© Intellyx LLC. Cherwell is an Intellyx customer. Intellyx retains final editorial control of this article. Image credit: Taber Andrew Bain.
