The Computer Weekly Developer Network gets high-brow on low-code and no-code (LC/NC) technologies in an analysis series designed to uncover some of the nuances and particularities of this approach to software application development.
Looking at the core mechanics of the applications, suites, platforms and services in this space, we seek to understand not just how apps are being built this way, but also… what shape, form, function and status these apps exist as… and what the implications are for enterprise software built this way, once it exists in live production environments.
This post is written by Jaco Vermuelen, CTO at BML Digital – a company known for its work as a consultancy that demystifies digital transformation, focused on simplifying the technologies most relevant to modern business.
Vermuelen writes as follows…
When it comes to the changes that low-code and no-code models are bringing about, the threat of ‘shadow IT’ needs to be more properly understood. So many platforms have embraced LC/NC – spanning not just the likes of Salesforce but also Microsoft Dynamics and a host of start-ups – that impactful change was inevitable. But this idea of LC/NC ‘following’ shadow IT, can mislead thinking. Yes, LC/NC has given rise to a lot of ‘non-IT’ people creating their own apps, but these need to be seen as simply being outside of governance, not some shadow set of functions.
To throw around terms like ‘shadow IT’ misses a lot of the important nuance about these apps. For example, they are typically developed at the business operations level, as a reactive ‘quick fix’ built around a refinement, or the duplication of an existing app from one department or business function to another.
This itself demonstrates that LC/NC can enable faster change, but that it needs to be overseen to be effective. Governance should never restrict, but rather function as the most solid foundation for business. It is a delicate balancing act to safely capitalise on the benefits of LC/NC, without an enterprise drowning in the collective efforts of business managers all experimenting with the software estate.
This balance firstly requires an understanding of the differences between low-code and no-code. Low-code refers to tools such as Microsoft PowerApps, Azure and AWS, that still enable some element of coding and typically are part of more complex arrangements that are still managed by the IT team. By comparison, the pure drag and drop of no-code, as seen in the likes of Bubble.io and SalesForce, is more aimed at issues of configuration and thus usually appeals more to operational managers
To encourage this use, many businesses have looked at their culture and accelerated a ‘controlled enablement’ of non-IT teams responsible for influencing the development of these applications.
This has been focused with a lot of training of line-of-business (LoB) figureheads on the platforms, including some governance awareness. Typically, a lot of younger operational managers are very eager to experiment and take a ‘do it myself’ approach because of their previous exposure to technology. LC/NC has been driven in part by the invisible, but consistent migration from the legacy thinking idea that a business manager ‘needs to give this to IT’ when it comes to any decision around technology.
Regardless of these differences in definition and use, it is undeniable that LC/NC tools do open and democratise software development – especially when starting a project from scratch. However, LC/NC is often brought to bear on minor changes / tweaks to existing software and especially for IT, the low-code approaches open more creative options, based on a combination of functionalities. The problem is how to ensure these options work for the enterprise.
The first step in this is discovering exactly what it is that people want the software to do. This critical first step is often overlooked or misunderstood. LoB managers or operational leaders have embraced LC/NC because it enables them to tinker and play with the options of alternative processes. They want to see what can be done: where processes can be quicker or slicker. It is rarely an issue of going rogue but more undergoing refinement.
There are deeper levels to this – capturing the motivation behind these changes (i.e. why do they want to change things) and then anticipating the cross-functional impact it has throughout the business, can ensure LC/NC is seen as a hero rather than a potential villain.
Small delineated agility
Our experience has been that, in exploring LC/NC, boards need this motivation and an awareness of the wider impact to assess any IT-related change, look to where it may have been done already, develop a plan in case things to wrong and then green light the change itself. This typically favours small, clearly delineated, agile teams that ensure the use of LC/NC falls within the appropriate governance framework.
When it comes to the immediate future of LC/NC, there is likely to be more growth in the back-office business functions, because as an approach LC/NC is applicable across the board. There are – by design – few limitations to who can deploy the approach and there is a growth in capability-specific low code platforms.
But it is not entirely plain sailing. Whilst superficial licensing costs are not high, the per processing charges that are typical on a lot of platforms can become very expensive, very quickly. There is an undoubted premium for the ease and convenience of LC/NC and it can soon become a substantial, ongoing operational cost.
This is likely to stay for the short term as there is the unmistakable whiff of proprietary ownership on these platforms and at the moment enterprises are better off going with these rather than with OS options.