This is the second in a series of articles on low-code. This article:

  • Identifies the four “domains” of an application.
  • Explains how low-code platforms address each of those domains.
  • Explains why low-code platforms must be carefully selected to ensure optimal and sustainable solutions.

Word count 1400, reading time 7 minutes.

This is the second article in a series about low-code. See also the first article in the series, What Is Low-Code?


In this article, I will go into more technical depth about low-code to answer some of the most common questions about how low-code works.

The Four Domains of an Application

Let’s start with the anatomy of a typical app. Taking an Enterprise Architecture view, there are four “domains” we can use to fully describe any app1. These are the app’s:

  • User interface
  • Logic
  • Data
  • Infrastructure

I will take each of the four domains in turn and describe some of the approaches used by the low-code vendors together with some pluses and minuses of the various approaches.

The User Interface

Starting with the UI, it should be obvious that building a user interface for an application should be a visual process.

The benefit of being able to see a window frame or card or other visual element on a palette and “dragging” it onto what will a user-facing screen clearly has its advantages. Most application development environments or IDEs, and most low-code tools, do this pretty well. The difficult decisions are the design-time decisions about which UI elements to use. For example, whether to use columns, or “cards”, the amount of graphical vs. textual communication, and so on.

At this point, most users are comfortable with the UI styles that originated in Facebook, Twitter and other Internet apps and encapsulated in frameworks such as Angular and React, with the latter being possibly the most universal. A key consideration here is not only choosing the right elements but making choices that will be applicable across an arbitrary number of devices, some of which you may not know about yet. For example, you may not think you need a mobile version of your particular app but you will if the application lives long enough.

The Application’s Logic

Next down in the architecture stack is the application logic. Looking back to computer science 101, applications for the most part will fall into one or more of a few categories. Three such categories are:

  • Transformation of information by a procedure or “workflow”
  • Control operations (both objects and functions)
  • Use of an algorithm, ranging from a simple interest calculation to deep learning

Most informational technology (IT) applications use the first, operational technology applications the second. The third, algorithms, are used in both categories.

When it comes to specifying application logic, or “programming”, the possibilities are endless. At the low end you have visual programming such as the fun and simple Blockly for kids and newbies. (Try it, it’s fun: https://developers.google.com/blockly/) At the high end are the sophisticated integrated development environments (IDEs) and “tool chains” used by professional developers.

Given this range, one could imagine the ideal solution would be visual and easy to use environment on one hand and a powerful environment on the other hand. That ideal solution is the essence of low-code.

Low-code’s core concept for application logic is to have you draw it when you can and script or program it when you need something more. When it comes to IT applications, most can be structured as a workflow. So, you start by drawing that. How about what happens at each step of that workflow? Here is where the low-code platform really shines. Or doesn’t. Possibly the majority of what you do on a node of a workflow is something you’ve done a hundred times. You should expect to not to have to program that. For nodes where some custom logic is needed – something that makes your business unique – easy scripting is ideal.

If what you need is too sophisticated for simple scripting, you can invoke an existing application or service such as a REST call to some microservice that embodies the logic you need. In many cases, you will need to talk to existing systems such as an ERP or CRM system, and you should expect robust support for this. Something off-the-shelf for common systems (e.g., SAP), an API proxy for many other things (e.g., via Mulesoft), and the ability to do web calls for everything else.

The Application’s Data

The foundation of most businesses is the continuum of data, information, and knowledge. With regard to this data, there are still some unsettled points of view on a few topics. Key questions are:

  • As much data as possible (just in case) or something more groomed?
  • Structured (if possible) or unstructured?
  • Keep the data in place or import it?

I generally answer these questions as “yes”, “yes” and keep it in place. By keeping your data in-place you don’t need to import it then return it. That eliminates the need to pay to store it again and it makes it faster to build an application.

But not every low-code platform defaults to those answers. So you’ll need to keep a lookout.

The Application’s Infrastructure

The fourth and final domain is infrastructure. Here I’m talking about compute (processing), network, and storage.

The most macro question is on-premise or cloud? It should be obvious that much like you want to build as few custom UIs as possible, do as little programming as possible and spend as little time manipulating the data as possible, the same concept should apply to infrastructure.

So, the answer for infrastructure is do it in the cloud. Even if you have capacity with your own on-prem infrastructure, on-prem always requires more work than if you use a public cloud. Cost is a more complex issue.

Despite this, many CTOs have concerns about the privacy and security of the public cloud, and about disaster recovery. Address this with your vendor by insisting on seeing certifications for all of the above and getting appropriate SLAs. Remember that for the super-sensitive data (for example, “the launch codes”), you can always work with only encrypted versions of your data (that is, some data is never stored in the clear), or you can employ a tokenization scheme. It’s worth it to go to the cloud.

A secondary concern about using the cloud is when part of your application, such as a mobile field device, might go offline. This is an area of concern which is still not fully resolved. In the meantime, if your application’s off-line bits are primarily IoT related, consider AWS Greengrass as part of your overall architecture.

The Future of Low-code

If you’re like most CTOs and CIOs, you are loath to add yet another platform to your already lengthy list. So unless it’s a one-off, you’ll want to rationalize low-code as a strategic direction only if you can retire two or more other platforms. This implies that you feel good about the low-code vendor long term. Both of these are easy to do.

As an application category, low-code is here to stay and will continue to grow rapidly. With that said, I see two challenges.

The first is what I call the “bloatware conundrum”. Application suites and platforms tend to get bigger and bigger over time. Over time, key customers insist on new features and before you know it you have Microsoft Word: hundreds of features with most users using a fraction of the features. The result of this bloatware in increasing bugginess, longer training times, longer learning curves for new users, etc. all which starts to cut into your productivity. The best low-code vendors will use a combination of restraint (think Apple) plus AI and related technologies to keep the platform easy to understand and use.

The second challenge is the offline world. We still have a lot of things – the oil tanker for example – which are by nature not always on-line. The vendors will certainly need to step up to this challenge since the world will not be universally connected any time soon.

What Does This All Mean For You?

Low-code is here to stay. And it really should be part of every IT technology portfolio. Low-code should also be considered for many of your operational systems (e.g., power grid, manufacturing floor).

But — and this is key — you must not only choose low-code for the right problems, you’ll also need to carefully choose the right platform since it’ll be a long-term decision. Remember that low-code doesn’t mean low design. Lastly, because applications will be faster to build and maintain, you’ll get more done. That doesn’t mean there’ll be less to do. Remember that backlog?

Need Help?

Let Telegraph Hill help you with your journey. We have the experience and expertise to get your there. We can help with both the strategic direction and the tactical applications.

1 I’ve taken some liberties. The leading EA standard is TOGAF which describes the domains in slightly different terms. See https://www.opengroup.org/togaf.

About the Author

Tahl Milburn

Tahl Milburn

Consulting CTO

Tahl has cultivated a diverse career in technology ranging from CTO of a Fortune 500 company (Providian Financial) to founder, CTO and hands-on developer for IoT healthcare startup Lifestate.io.

As a Managing Director of a consulting practice at Cisco, Tahl delivered results across nine counties and multiple industries including financial services, healthcare, energy, federal clients and others. His deep expertise includes Enterprise Architecture (VP at Visa), IT governance and resourcing, organizational change management and technical strategies, having delivered, for example, information security strategies to three Fortune 500 companies.

His expertise and passion includes advising on emerging technologies including IoT, low-code, and, affective computing.