The use of low-code platforms is expanding, driven by the idea that non-developers working with the right tools can take a more active role in the development process. Application development has never been more complex due to the staggering number of components required for modern multi-tiered application development, which makes the idea of utilizing business resources to relieve the burden so compelling. However, this also creates new challenges around preserving data integrity and security.

Application developers have skills that business people do not have, which become especially important when building mission-critical or large-scale applications.  Application developers need to understand good data design principles, data relationships and transactional integrity — skills that are vital to the integrity of corporate data yet missing in business people.  

Business people have expertise in business process definition (i.e., workflow with associated presentation). Low-code platforms provide the tools to define business process workflow and presentation and typically allow connection to existing corporate data sources (databases).  This leads to two separate problems, depending on whether IT (and auditors) will allow direct access to corporate data:

  1. If direct access is not allowed, data is usually exported (or, worse still, duplicated) in the low-code platform and synchronized with the corporate databases, leading to multiple sources of the “truth”.  Further, exporting and synchronizing data still requires effort from IT, negating some of the benefits.
  2. If direct access is allowed, the low-code platform is tightly coupled to the corporate data implementation, making it impossible for the IT department to employ new environments (cloud) and technology (NoSQL, change database engines) without waiting for all low code platform implementations to make the required changes. Further, allowing direct access to corporate data increases the risk of corrupt or bad data due to misunderstandings between Business and IT.

Other concerns are often cited, such as an increase in unsupported applications, or business rules either not being enforced or conflicting with documented rules.

So, how can an organization leverage the knowledge and skills of its business people to help build an application, without introducing data integrity, security and other issues?  

Separation of Presentation and Business Logic

The answer is surprisingly simple, but requires a services model with two parts:

  1. The complete, total, 100% separation of the presentation and business logic layers.
  2. The employment of a messaging model for communication between the two layers that is platform and language agnostic, to allow controlled access to corporate data via defined services that encapsulate business rules and data validation.   

The complete separation of presentation and business logic is not possible in traditional single-tiered and two-tiered architectures (i.e. mainframe and client/server architectures respectively), simply because presentation and business logic are intricately tied together and must therefore be coded together.  Although presentation and business logic are usually tied together in multi-tiered architectures, these architectures do enable the complete separation of presentation and business logic.

This separation can only occur, however, with a messaging model that allows the two layers to communicate with one another.

Separation of Responsibilities

The complete separation of presentation and business logic leads to the complete separation of responsibilities, enabling business and IT to specialize in what they do best.  That is, business can design and build the presentation layer and IT can code business logic, design databases, uphold the integrity of corporate data and enforce security.  Note that the separation allows business to not just design the presentation layer – something it has been actively doing since the beginning of the information age – but also safely and independently build (i.e. code) the presentation layer using low-code tools (including workflow tools).  

Specifically, responsibilities can be separated as follows:

Business responsibilities:

  • Build the presentation layer using prototyping and other tools.
  • Use, and reuse, business logic services provided by IT.
  • Sign off on business logic services via a user acceptance test environment.
  • Provide business rules and data validation requirements to IT.

IT responsibilities:

  • Provide a secure, reusable, ever-growing repository of business logic services that can be exposed to any low-code platform using any presentation tool.
  • Maintain a single “source of truth” for both business logic and data (i.e. maintain central, controlled points for each).
  • Ensure that corporate data has integrity.
  • Ensure that business logic and data is secure.

The separation of business logic and data using a services model, and the resultant separation of responsibilities, leads to the following benefits:

  • Business and IT can specialize in what they do best, each independently developing presentation and business logic.
  • Collaboration is fostered between the two areas.
  • There is no need to replicate data.
  • Business logic and data have a single source of “truth”.
  • Business logic and data remain secure.
  • Data integrity is upheld.
  • Businesses can quickly take advantage of new services as they are made available.
  • IT can change the deployment of business logic and corporate data (cloud, new tech, etc.) without impacting the low-code platform because it is isolated behind the service layer.

The use of a services model enforcing the complete separation of presentation and business logic provides all the benefits of low coding, with none of the drawbacks.  The “low” component of low coding, as executed by business resources, is restricted to presentation only. The more complex, and far more dangerous, coding is executed by highly trained IT resources.