From modular software to modular business
Just like a house or a bridge is made from bricks and stone, programs are made of pieces of code. Code is mostly bundled in modules. So for programmers their programs have long been modular. Currently, the infrastructure is also becoming more and more modular with Docker containers and cloud computing. Unfortunately the business cannot take advantage of the same type of modularity as programmers and admins do.
We live in house of bricks and stone, but they are tied together by cement. Once the cement has dried we can live in it. In software, we could say, once the program is compiled, it can be used. So the software is modular, but once it ready for usage, it’s fixed like stone.
Fortunately software is much more flexible than buildings and infrastructure. Think for example of music. When a recording is stored into a digital file it can be copied over the internet many times. It would be like copy a house or a bridge with one push of the button.
Is low-code the solution?
To copy is easy, there is however a problem with this approach. Mostly we don’t want an exact copy, but we want to change things. The house must have an extra bedroom or the bridge an extra lane.
In software the traditional way of doing this is as follows: The new requirements are captured in issues. Thereafter, the programmer adjust his program, compiles and distribute it to its users. The way to give users more power is by creating settings or configuration files. This made the software a bit more flexible. Still, this approach isn’t flexible enough to react on changing circumstances and bridging the gap between IT and business.
Low-code is one of the approaches to bridge this gap. Instead of coding it tries with visual building blocks and modeling tools to create functionality. It’s not so easy to create a low-code platform. For different parts of the program, like user interfaces, data model and business logic, other types of visualization is needed.
With code this is easier as everything is represented by text. This makes it universal. For years there have been projects to create low-code platforms, but these mostly led to inflexible and non-portable programs. Recently Mendix, Betty Blocks, Progress Kinvey and Outsystems made good progress with the low-code approach. Of course, it is still not as portable and open as most programming languages, but real applications can be made.
The low-code approach brings programming closer to the business, but this still doesn’t solve the issue that programs are only modular during creation and not while they are running.
You also see that low-code platforms pack more and more functionality (to create flexible programs) that the applications are harder to create (and in the end done by low-code platform specialist). So low-code is part of the solution, but not the solution. At the end it’s still business software.
What we try to achieve is modular business. By this I mean that business doesn’t run on software, but the software runs on the business. The business is the software. This is a more higher-level and direct approach, I call runtime delivery.
Runtime delivery means that the building blocks are available online for business directly. So it’s not a low-code platform to create applications, but it are ‘high-code’ services to build businesses. The building blocks are doing only one thing (separate-of-concerns) for a specific domain while acting completely independent of other services.
It’s not really about the cloud which manages and runs those services. It’s about the building blocks to develop business. This extra layer will business developers who now use Excel (and sometimes already low-code platforms) to create functionality on business level.
A good example for runtime delivery is a business rules engine. For example Progress Corticon is a business rule engine which runs totally independent of other software. Rules are created by ‘If…Then…Else’ constructions. Such rules are understandable and changeable by the business directly. Each rules is building block.
Another example is Apache NiFi. This project originated with the NSA to create data flows and change them directly in the browser. Such flows are easy accessible and understandable by the business.
Flowbased-programming can get complex however, but NiFi can group a data flow (one function) together this can run in separate container and can be used as a building block by the business. So IT may create the building blocks, but the business uses these building blocks to make real business flows.
The beauty is that all the building blocks of the examples can run together to create a business designed for change. The blocks need to be as close to the business as possible so that the business can use and change the functionality itself.
Modular software building modular business. It’s more a mindset than about technology.