DevOps, low-code and configuration-based platforms

Disclaimer: Due to the controversial nature of my post which could potentially question the necessity of the products of many established businesses, I have to state that the views expressed below are my own opinions and not those of my employer or colleagues.

There is a repeating pattern that I have observed over the past 18 years of my career in software engineering. There is always a new configuration-based tool that comes along that promises to free your business from being held to ransom by developers. Typical justifications usually consist of claims that code leads to long lead times for change, growing technical debt and high cost.

Instead of addressing these issues individually, these platforms usually attempt to invent a new way of working. Essentially defining a new way for analysts, developers and information workers to express their intentions to an underlying computer. You can usually identify such approaches by phrases such as “code generator”, “4GL (4th generation language)”, “low-code”, “drag and drop development”, “content management”, “configuration driven”, “no-code” or “integration platform”.

These approaches are not only inefficient, but they also counteract many of the benefits that following a DevOps approach should bring. To fully understand the repercussions of relying on such a platform for application development, it must be looked at from multiple perspectives.

Flexibility and levels of abstraction

In essence, all programming languages, frameworks and systems act as a set of rules and constraints in which humans can express and digitise processes. These processes can be combined to form simple or complex business applications, games, or dynamic frameworks that that will be crystallised into applications by other parties.

The further away a developer moves from machine language, the more abstract the language becomes resulting in less flexibility and control. On the extremes, you find machine language at the bottom of the stack and purely configuration or data driven applications at the top of the stack. An ideal compromise of these extremes exists, but careful consideration should be given to choose the appropriate layer to start development on for your business application.

How complex the business process is that you are attempting to automate should be a major factor in determining how far up or down the stack you should be developing. Also consider where your organisation’s competitive edge lies, if it is in the efficiency of its processes, chances are that you would want as much flexibility as possible in digitising those processes. Mature businesses that operate on ever decreasing margins typically have complex processes with enough exceptions and special cases that is close to impossible to fully set out in drag and drop or template-based development platforms.

Platform size, knowledge base and skill availability

The sheer size of the companies or groups of people that develop platforms is typically a good indicator of how future proof a platform is, how much investment into building knowledge bases occurs and how available skilled resources are in the market.

A Large platform provider like Microsoft employs upwards of 130,000 employees. That is a very large number of people contributing to a shared vision in the form of languages, service and integration frameworks, patterns and practices and training material. Once you expand this number to include Microsoft’s partner network and other certified Microsoft developers, you have a pool of millions of people worldwide with the necessary skills to develop and support your application.

Configuration- and low-code-based platforms are typically provided by much smaller companies. The table below provides a rudimentary comparison of some popular development platforms in the market. It does not consider the proportion of employees that contribute and support the development platforms, but rather serves as stimulus to start a conversation and a thought process.

Organisations across the world are forever trying to improve efficiency and profitability through innovation. If a person attempts to imagine the scale at which reusable abstract buildings blocks would need to be built to keep up with all this innovation, it becomes evident that the smaller platforms just can’t keep up.

Universities and colleges also recognise the importance of developing in programming languages and provide the market with a steady flow of trained professionals that are ready to hit the ground running. Introducing proprietary frameworks or platforms typically increase the on-boarding time for graduates and seasoned developers alike. The only group spared from the increased on-boarding is usually the small pool of skilled resources in the market, although these typically come at rates much higher than a typical mid-level developer.

There is another approach, harness commodity developer skills by providing structured development practices that manage risk and prevent developers from going off on a tangent.

Testability and units of work

One of the key concepts in DevOps that enables agile and efficient development life cycles is automated testing. Being able to run automated unit tests, integration tests and UI tests in immutable environments that are consistent with production give teams the ability to assess the impact of their changes before they are integrated into a shared code base. The more configuration points that exist that are environment specific, the less reliable your test results become.

Having test environments that are consistent with production is key in gaining trust in test results. The recent uptick in the usage of infrastructure as code platforms like Docker, Kubernetes are good example of how the use of code has been used as a way of ensuring consistency across environments. Why not follow the same approach for your application logic and content?

Features are typically developed independent of release cycles. In an ideal environment, automated testing can be executed for these features in isolated environments to determine their readiness. Once these features reach a predetermined level of quality, they can be earmarked for a release and bundled into a release into a shared test environment. An ideal testing workflow like described in this paragraph is only possible with the use of mature DevOps tools like orchestration, build servers and automated deployments.

Integration options

As you move up and down the stack, the number of platform choices increase. As you consider introducing platforms into your technology ecosystem, also consider how these platforms will communicate with existing applications already in your technology ecosystem. Most enterprise grade system can be extended or consumed via generic API’s. API’s are usually fairly easily consumed from code-based applications. Configuration-based applications typically require the platforms to comply to common communication protocols and or have platform specific connectors. In the worst case, yet another abstract configuration-based tool like an integration tool needs to be introduced to mediate between incompatible proprietary systems.

Conclusion and recommendations

I would like to conclude by listing a few “smells” to look out far and some alternative approaches to consider. Instead of relying heavily on the promises made by the vendors of proprietary configuration platforms, consider looking at ways to leverage the commodity skills of developers skilled in common languages. Vendors make promises and can be held accountable through contracts and the legal system, but at the end of the day, they are not responsible to keep your business competitive. 

Pre-built systems still have their place, but only in automating business processes that can be classified as stock standard, run of the mill. These processed are typically not where your competitive edge lies. Other examples include software packages that focuses on solving a single business process that is standard across organisations.

• Instead of integration platforms, consider code-based integration that can be tested and deployed to consistent environments using your CI/CD pipeline.
• Instead of monolithic content management systems, consider authoring content in existing languages like HTML. Options include training content authors in HTML or transforming your team by adding junior developers to be paired up with content authors. When you have an efficient delivery pipeline, all changes, including content changes, can be pushed to production multiple times per day. Imagine testing content changes in a test environment and having those electronically signed off in your delivery pipeline which continues to push the approved change to production automatically.
• Instead of modelling your competitive business processes in inherently constrained configuration based workflow or BPM tools, consider building these processes in flexible programming languages like F# or C#.

Platform abstraction has already been invented and cloud platforms from the giants like Azure, AWS and Google Cloud accept code-based applications whilst removing the pain of managing the infrastructure. Any abstractions over their PaaS and FaaS platforms create unnecessary constraints and dependency on specialised resource who might not be around a few years from now.