Mendix wrote a blog about low-code principles, We were so excited about this, we’d like to share this blog with you.
“You’re going to let who do what?”
That’s the reaction many professional developers and IT leaders have to the notion of democratizing the development process with low-code and letting non-professional ‘citizen’ developers — business analysts, engineers, domain experts, and others — create applications. Their next reaction often is: If you can’t see the code, how can you be sure that an application adheres to the enterprise’s established standards, best practices, and architectural considerations?
IT’s protective attitude toward its technology landscape was born when computers first reached the fingertips of “average” users. Their concerns were legitimate then and, to a large extent, still are today. Some would argue that, with technology continuously evolving at a breakneck pace, the need to keep a grip on the architecture, tools, and human component is greater than ever. So it is no surprise then, that principle #8 of the Low-Code Manifesto is:
GOVERNANCE & CONTROL:
ROBUST GOVERNANCE AND CONTROL PROCESSES AND PROTOCOLS ARE ESSENTIAL.
Definitions are important here, as there are at least three different flavors of governance. One is about conforming to the internal rules — best practices, standards, cultural norms — to keep people from breaking things. This is our main subject here. Another is about conforming to external rules and regulations, for example, specific regulatory requirements for financial applications. The third is the CIO-level definition, meaning to make sure that IT strategy supports business strategy and delivers quantifiable results. While our focus here is the first definition, it will become clear also that low-code does a stellar job supporting definitions two and three.
Control, on the other hand, means simply control, as in, IT is in control of what happens throughout the entire technology ecosystem — who is allowed access, where they are allowed access, what they are allowed to do there, what tools they are allowed to use. IT needs to be in charge because it is responsible for the integrity of the entire technology stack.
The line between governance and control can be a bit fuzzy. They go hand-in-hand. That’s why we consider them together, as a single low-code principle.
THE MORE FREEDOM YOU HAVE, THE MORE GOVERNANCE AND CONTROL YOU NEED
One of the great benefits of low-code is that it invites a much broader pool of talent to participate in creating applications, including non-technical types not trained in development. Business users can try their hand at building apps or map out their ideas for the technical team. Novice developers can hone their skills building whatever they can imagine. And of course, seasoned developers can use every exciting new technology to push innovation to the limit. Low-code gives creators of every skill level the tools to make all kinds of applications. It gives them freedom to create.
But they can’t have the freedom to cause problems. It’s even more important to have robust controls in place for low-code than in traditional development platforms, precisely so that inexperienced or overly ambitious application makers don’t inadvertently wreak havoc on critical enterprise systems.
When you have a culture of innovation, you have to have strong guardrails. When you’re moving fast, when teams bring diverse skill sets to the process, when teams are given the autonomy to excel — this is when controls are of paramount importance.
But you can’t control everything, nor should you want to. To tie the hands of creativity defeats the purpose. It’s a delicate balancing act, freedom vs. control, innovation vs. risk management. The platform itself needs to promote and enforce the appropriate balance.
PREVENT, DETECT, CORRECT
There are three primary aspects to controlling risk. Prevention, to state the obvious, focuses on keeping problems from starting in the first place. Detection focuses on finding potential or actual issues. And correction, again to be obvious, focuses on fixing what gets broken.
The typical mindset is that preventing a problem is better than having to fix it after it surfaces. The drawback with this approach — and it’s a serious one — is that, when too many controls are embedded, creativity is stifled and the whole process is slowed down, both of which are anathema to a low-code approach. The actual cost of prevention or the opportunity cost when innovation is stymied can be higher than the cost in time and money to make a repair.
The low-code approach focuses more on detection and correction, saving prevention only for the things that can do great damage. The idea is to minimize the impact (or “limit the blast radius”) of any mistakes or missteps. Low-code’s microservices- and cloud-based architectureinherently isolates the fallout when a mistake is made. It also makes it easier and much faster to identify and repair the issue.
That said, low-code does have significant preventive safety mechanisms built-in, particularly, controlling which tools users have access to and giving them building blocks that won’t let them break things. [“Don’t give power tools to small children,” as the saying goes.]
GOVERNANCE AND CONTROL, LOW-CODE-STYLE
Low-code, properly engineered, incorporates all of the time-tested governance and control tools and conventions of traditional development, updates them, and augments them with the powers of the newest technologies, particularly artificial intelligence and automation. In general, low-code is engineered to make it easy for users to do the right thing and hard to do the wrong thing, in three important ways.
To start with, low-code makes many of the technical choices to configure the application, so the developer doesn’t have to. Common and routine tasks are automated, so there are fewer decisions, and therefore fewer errors, to be made.
Then, throughout the process, artificial intelligence guides the developer on best next steps and constantly checks the work.
Finally, with low-code, the entire application lifecycle is infused with automated quality control. Everything that can be automated needs to be automated to ensure quality and compliance: consistency checks of everything, refactoring, identity control, ongoing testing and monitoring, backups, everything.
VISIBILITY, INSIGHT, CONTROL
To exercise effective governance and control requires visibility. If you can’t see what people are doing, you can’t make sure they’re doing the right thing. With low-code’s rich metadata, there is virtually nothing that cannot be measured. Everything is traceable and auditable. Everything can be checked. Everything can be monitored. The insights gained not only help IT leaders to maintain control, but also can help them to make sure everyone is pulling in the right direction to achieve business impact — to satisfy that third definition of governance so dear to CIOs.
Those new to low-code sometimes make the mistaken assumption that, because it’s so easy and fast to use, it must be light on governance and control. In fact, quite the opposite is true: It has all the governance and control of traditional platforms and then some (which also contributes to making it fast and easy to use, to complete that circular thought).
To put a spin on the popular expression: Move fast and don’t break things. Low-code has your back.
Get in touch
