The challenge with ‘low code’ solutions
Something that has become pretty topical of late, is this concept of a low code solution. Precisely what it is, really depends on your personal interpretation but in a nutshell it is a set of software development tools, procedures and methods that minimize the amount of hand-coding that you have to do to arrive at a finished solution. I have worked with a variety of RAD applications over the years, each operating at their own level of maturity according to where the market was at. Rapid Application Development tools are nothing new, but the modern-day vendors are bringing focus with a slightly different twist.
One of the noisiest vendors in this space is OutSystems who industry analysts Forrester have on their Q2 2016 Low Code Development Platform in the Forrester Wave strong present day solution providers with a robust strategy and effectively a leadership position.
Other contenders are interestingly, are Salesforce, Appian and Mendix. Each vendor has a slightly different way of tackling the constant battle of creating business solutions that meet the needs of the business but are quick to deploy and easy to maintain. They’re all shouting ‘low code’ though.
Rapid Application Development pretty much sums up what the ‘low code’ solutions are trying to achieve but I believe that they can only really be successful based on a couple of fundamental assumptions.
API’s present and accounted for
The first assumption is that all the necessary integration APIs are present and available for pushing and pulling data to and from systems. Since most systems do not operate in a vacuum, you have to have integration methods for referencing or persisting data in various repositories otherwise you may just as well stick with manual methods.
Most modern day ERP, Financial and CRM systems do have APIs but these are typically delivered based on a vanilla configuration and deployment model. When you choose to customize or enhance your systems to align with what you believe are unique and market differentiating attributes you have to ensure that your APIs are also modified or adjusted to cope with the customization. Think of this as a catch-up.
Often this catch-up is the last thing on the minds of those implementing the system or updating its configuration, unless of course down and upstream integration is figured as a critical path item in the deployment or change.
The process is stable and not too complex
Now this is a little contentious, because after-all, isn’t one of the reasons you implement a RAD solution — the ability to quickly tweak and adjust to align with requirements?
On face value I would say yes, but at the same time, RAD solutions, even low code ones do need to be designed, tested and implemented. This is not a lightweight exercise.
While building with RAD tools is faster than classic hand coded solutions, most RAD solutions will take a month or two to deploy at the very least. What you can deploy in hours or days is usually very simple, very easy and more of an MVS or minimally viable solution than a completed solution. This is well aligned with an agile methodology.
If the process is still in a tremendous state of flux, you’re still trying to work out all the participants, the rules, the workflows and minimum data coverage then you will go through many cycles of build and deploy before you arrive at a solution that is effectively agreed as usable. This is of course one of the reasons that a RAD might be a great choice but it can hurt if the expectations were something complete, delivered quickly.
The more stable and defined the process, the easier the scoping, build, test and deploy will be. Consider RAD sweet spot as being one where the process is pretty well bedded in with low volatility and the requirements are somewhat known up front.
For more on this thought, consider a read of the A Leader’s Framework for Decision Making in HBR from November 2007
The process is suitable and appropriate
This is also a little contentious but bear with me as I elaborate on what I mean here.
I believe that most processes can be easily automated or at the very least improved using structured data entry and access methods that are somewhat prescriptive and consistent.
I also believe that when you wrap those methods with workflows for collaboration you close the loop on a great deal of the friction that occurs in businesses around information processing. This template based approach to data handling in particular, however carries a significant amount of edges that can fray.
Fraying in the process occurs when the reference data is very volatile and not very static and is growing exponentially to cover a plethora of scenarios, it also frays when there are too many interdependencies between choices and not enough prescription. Consider online shopping for example.
If you search for chocolate and are presented with hundred choices, what is the next step in your decision tree? Depending on the reason for your search, you may have pinpoint precision in terms of understanding what it is you want. Are you a dark chocolate lover, a chocolate lover who likes added things, like nuts or raisins, or are you brand sensitive? Once you have cleared that hurdle, how about unit size? Are you looking for a small bar, a large bar or something in between. Most online retailers will give you many, many choices. Now look back to your original requirements. You may find that none of the choices on offer are actually what you need.
You only have to look at mature shopping mechanisms like eBay or Amazon or your online supermarket to get an idea of what works and what doesn’t — and these are massive solutions developed for generic use. In all the choice, filtering and indexing sometimes you simply cannot easily find what you want even though you know it is in (or out) there somewhere.
So my view is that sometimes the most painful business problems get tackled with the belief that a RAD solution is the way to only to discover that in the end, it doesn’t cover all the nuances and aspects of the business problem because the logic for handling all the combinations or permutations is simply too large for the RAD to cope with.
The solution hockey stick
I view the potential problem with RAD as being one where the hockey stick effect kicks in and kills the solution development initiative because it is overly ambitious about what the RAD can do.
The requirements start out simply enough and check all the boxes for a RAD solution but very quickly the more sophistication you inject into the requirements, the more bullet proofing you try to establish and the more participants and data sets that you add, the harder it becomes to be able to check more boxes that suggest that the solution will be aligned, work and can be delivered in a reasonable time frame.
There is a sweet spot for RAD and ‘low code’ solutions in particular and it is one where the existing process, manual or automated, has a pattern of activity that can be easily replaced with something more elegant and more efficient. You want it delivered fast and you want it delivered using agile methods — fast cycles of iterative improvement but with a clearly defined end point.
The question in the minds of those selecting these solutions has to be whether or not they want to settle for something less ambitious but achievable. Tackle a big problem with the wrong tool and you will fail or you will endure tremendous hardship in trying to achieve success because the requirements are too complex, the environment too volatile and the systems inaccessible.
I think a clue has to be, if your business has tried to build this solution or address this problem before and failed, what were the reasons? Unless those reasons have been addressed, a RAD solution probably isn’t the way to try and solve the problem.