English | EN 
Often before we can apply any technology or create a statement of work, stakeholders will ask to accelerate the process so that they can quickly see the comparison between a solution aligned with their worldview and a bad strawman solution that proves and justifies their plan. There are times when it is difficult to find minute line item details even though the comparison itself takes place at a higher, aggregate level. Currently, my focus is on Low Code Business Application solutions, so it tends to be about the choice of Low versus “Pro” Code with the requestor looking to reinforce their position.
As the discussion crosses over effort and costs, it often refers to licensing and its apparent arcane nuances and permutations that people in my industry prefer to delegate to someone, anyone else. As a result of that and without further context, the promises that appear on Forrester or Gartner appear weak since traditional coding has been around long enough in organizations to quantify the cost and effort of their projects and have support from DevOps tools such as Azure DevOps in my area of specialization.
The purpose of this article is not to advocate or promote Low Code or its capabilities as the Panacea but, rather, to explore how to make the most out of modern tools (dare we call them the “tools of the ’20s”?) with a focus on metrics and measurement, in particular, the all mighty and holy Return on Investment (ROI). Studies commissioned by vendors such as Microsoft and Forrester (THE TOTAL ECONOMIC IMPACT™ OF MICROSOFT POWER PLATFORM) have delved deep into this topic but this article brings us all closer to the surface for a better understanding.
In a recent discussion with fellow Microsoft MVPs, one of them challenged me: “I work in Switzerland, where the SMB market is gaining momentum. On a global scale, those are small companies. Especially accounts with a thousand seats or more show huge interest in low code solutions. However, still, we do business case calculations per app (or even flow), which is the exact opposite of what we should do. Most people have experience in custom software development (either in-house or external) and try to calculate on a per-project or per app basis. It isn’t that easy to explain that a low-code platform is indeed a platform with an ‘economy of scale’ and benefits from every use case built on that platform. Licensing is still too complex, and business value discussions often fall short when we follow the ‘rapidly build apps’ narrative.”
Thus, there were several issues here – given the exact same set of requirements, and this is KEY, Low Code mitigates a number of things that would need to be built and supported for traditional apps to work. A traditional code piece already has a pattern in place (something we hope is a given these days) where modifications are data driven or easily inserted into the build code, so a Low Code alternative will not stand up any ROI against that because, technically, those changes are already “low code” in nature. Similarly, the Traditional code world understands such as “set up all your patterns and infrastructure and architect smartly to make your changes data driven, etc”.
What people have been comparing is not that state against low code but the efforts well before that where you have to set everything up in addition to meeting the requirements AND making it convenient way (future proof for lack of an alternative term). Using someone’s low code environment essentially takes care of all the extra outside the requirements and, hence the “savings”. An attempt to “size” one over the other should include the extra bits from setting up the DevOps, the core code pieces, the infrastructure and the post-delivery maintenance.
As complex as licensing it may seem, it is a lot simpler than putting numbers on raw building of those other pieces as, since post-delivery is at best an estimate whereas low code is an assured fixed and predictable cost. This is why it’s been more generalized rather than specific. Consider each workflow for example, what is the “value” of the infrastructure, security and admin already built in? As opposed to the traditional code version where you must ensure the supporting infrastructure meets organizational or industry requirements. Would someone say their small business can compete better than a big company like Amazon or Google or Microsoft or a company that specialize in Low Code capabilities such as Mendix, Appian, OutSystems, UI Path, or even extended capabilities such as ServiceNow or SAP?
Many of us in the developer community assume that there will be re-use and all the good things contained in professional software architecture but the reality is that the wheel is re-invented more times than we realize. Even Low Code Powers can’t solve this problem as one can easily take a set of Excel files from a single organization and there can be quite a few variations in exactly the same output except perhaps in places where they treat organizational content as code. Consider that there is a happy medium where the level of “control” of content or code is managed appropriately for its size and criticality to the business of the organization.
So on that basis, I am concluding that Low Code always presents an “acceleration” or a handicap as they say in golf which puts us ahead of the game to “start” the solution … but there will always be traditional code solutions because there will be new things that will certainly defy the wheel-design du jour and sometimes we need to start well before that line because the starting point just isn’t appropriate.
But wait! We cannot leave it there because there is still one major aspect to this discussion that will be the subject of my next blog (yes, I am setting up the sequel MCU style at the end.) In summary, there is still room for all types of coding to exist and be applied even if the concept behind low code is to increase ROI through a better starting point and potentially cleaner application lifecycle. But ultimately choosing one or the other or even the mix, will still depend on a lot of factors not to mention the organization’s goals and culture itself. The one thing that should be the next step to follow up on this topic is to address GOVERNANCE. Spoiler alert: Centers of Excellence and Governance policies can make or break the solutions in all aspects of code but for Low Code and the push for the so-called “Citizen developers”, it becomes Critical.
References:
