It seems to me when we run out of new things to talk about in the world of technology, we dig into that old bag of yesteryear and bring out some oldies but goodies. This is where we get to play “one up” against the other guy to show how much history we bring with us.
“I remember playing Star Trek on the old TRS-80 (the Trash 80 for us cool kids). It was written in BASIC and we changed what the characters were saying…”oh really Mr. Spock? Now that’s just not logical”
“Yeah, I remember playing Beyond Zork on my Apple II―I had to type all my commands using the keyboard!”
“Remember playing back the saved program from the cassette tape of the Atari 800 to see what source code sounded like?”
“I used punch cards and a card reader to run my first programs on the mainframe.” CHECK MATE!
As an old-time programmer, it’s amazing to see so many old concepts re-incarnated with different terminology and technology in order to address the same issues we were trying to solve in the last century (literally, last century―stretching a point to make a point here). The important thread to understanding these concepts is not the history of solutions meant to fix a particular issue, but rather identifying the need to address the same problem across generations of software development and exploring why the solutions weren’t able to correct the problem before. Were the solutions just ahead of their time or were there more deeply rooted issues?
Low-Code by any other name….
The concept of low-code has been around…well, since the beginning of programming. Perhaps it wasn’t called low-code or no-code back then (4GL, CASE, RAD, etc.), but the need for what a low-code solution tries to accomplish has been a priority since Alan Turing yelled at his staff “Why is it taking you so long to code that?!?!” (Please no comments on this quote―I made it up―but I wouldn’t be surprised if it happened.)
The core of the issue is how to reduce dependency on expensive resources to program our systems. Additionally, how do we accomplish this while speeding up the development lifecycle?
The objectives and approach of a low-code solution can be broken down into two distinct areas.
First, how can a company reduce the need for developers? Basic supply and demand rules apply here; where there is an increasing demand and a limited supply, the cost goes up. And as every analyst will attest, the demand for application development continues to increase at a record pace. A low-code solution provides a non-technical user the ability to create an application through a graphical point and click user interface with no-code, or perhaps only a low amount of code required. The low-code application will build the program, and produce any necessary code, based on the low-tech user’s input.
Second, how can we accomplish this magical feat and also speed up the process? Part of the logic behind a low-code solution is that instead of having the power users dictate their requirements to a business analyst who documents the request and routes it to a developer (who may not understand the business, but creates the necessary code anyway), can’t we speed up the process by having the end user build the application? All they would have to do is point and click away. Press the magic button and abracadabra…new program.
So, What’s the Issue???
The low-code approach led to several major issues, most notably, the propagation of many, many, many, small, unconnected applications supporting a narrow scope of business functions. These applications were built independently to what end users interpreted as the correct business rules when, in reality, the business rules may not have been correct or had limited validity beyond their specific business area. While this approach probably made many end users happy, what was lacking was adherence to an enterprise strategy and governance that ensured data quality and consistency across systems. These solutions did not always support best practices (think version control, integration testing, etc.) and often increased security risks. In the end, different parts of the organization would accept their local system’s data as gospel, but the information rarely matched across business functions due to differing logic. Clearly, this does not make a very good decision-making strategy.
Another issue was the volume of applications that drove critical business functions across the organization. Over time, the original authors moved on, and IT departments were left trying to support hundreds, if not thousands of applications built on rapidly aging and outdated technology with limited, if any documentation. Try retiring thousands of undocumented applications without knowing the impact of the system across other business functions. (I have been part of efforts like this and it can seriously ruin your summer vacation). Ultimately, the lack of oversight, governance, and best practices created a larger mess than the benefits of creating applications fast.
What’s different about Today’s Low-Code?
A few companies have progressed the concepts of low-code into a more strategic and holistic approach. There are enterprise platforms today that allow a low-tech user to manage their application’s data model, business logic, and data relationships by using a point and click front end. This information is then treated as data and is stored in a database or other medium. This industrial low-code approach allows low-tech users to build a single data model across multiple enterprise applications on a platform while managing business rules for all the applications consistently. This critical information becomes portable and allows the platform to be upgradable and adaptable because the information doesn’t sit in a siloed app, but resides as part of the larger environment. Most important, critical changes like business rules can be made over time by a non-technical user, not expensive programmers.
Of course, there are many companies still offering a modernized version of the low-code/no-code solutions based on the original concepts outlined earlier. These solutions allow low-tech users to rapidly build simple apps by connecting a data source to a visual output to deliver real time information, without the need to create code. Some of these apps also provide write back functionality or work within typical business functionality like a workflow process. These are great use cases for these solutions and are particularly effective getting operational information to users as it happens. Bravo!
The issues I see with this model are the same issues experienced in previous generations of low-code. Without the proper governance and strategy, apps get created faster than can be controlled. These solutions are tactical and do not provide a centralized place to manage consistent business rules, leaving critical business logic disconnected and separated between systems. Furthermore, as business logic changes or technology needs to be upgraded, the business is now responsible for determining the impact of the business change across hundreds or thousands of apps and begin the process of making the necessary changes. (Ouch, been there, done that, don’t want to go back there).
Conclusion
While low-code solutions have been around for a long time, re-appearing in different forms, they have struggled to maintain a presence in development landscapes. That said, the need to develop systems cheaper and quicker has not changed and the fact that people keep coming back to low code concepts is a good indication that there is a valid solution that can be derived.
Many low-code solutions today focus on the rapid creation of small, simple apps that can deliver information to a user in real time. The question is not about finding valid use cases (there are) or whether the solution works (it does), but more important, whether companies have the courage to govern the development efforts before the landscape overruns the business’s ability to manage it. Time will tell, but please don’t call me to clean up the mess.
The new approach of industrial low-code takes the low-code concept to a new level. Companies, like Aras, have designed their platforms using the low-code concept, significantly reducing the amount of code necessary to build applications. By modeling the business and its processes, Aras Innovator creates a data model that supports business rules and data relationships all done by low tech users in the easy to use UI. Aras’ industrial low-code solution is constructed on a rich set of platform services that builds enterprise applications, all on one platform. This resilient platform provides a secure, upgradable, and scalable environment that adapts to new business requirements often without the need of programmers.
While these two approaches both utilize low-code concepts, they really can’t be compared to each other. One is a reincarnation of past efforts that comes with the same risks that were seen at the time, and the other is a major step forward for application development.
Finally, after generations of software development, the goal of reducing the dependency on expensive developers, while also reducing development lifecycle time, has come to fruition. Perhaps Alan Turing can rest a little easier (again, no comments please).