Low-code development is tremendously popular, allowing citizen developers and IT departments to create productivity-enhancing solutions rapidly. But it won’t lead to digital transformation unless organizations manage it strategically and think about more than one application at a time. In this article, Mike Fitzmaurice, VP of North America and Chief Evangelist, WEBCON explores how businesses can make low-code tools work for the long term.
The use of low-code development tools and platforms shows no signs of slowing. It’s no wonder: low-code provides the ability â€“ and opportunity â€“ to create software applications with little need for programming in the traditional sense, instead leveraging a graphical interface and â€œbuilding blockâ€ approach.Â
Low-code helps overcome what 86% of IT decision-makersOpens a new window say is the biggest roadblock to digital transformation: too few software developers. It often democratizes development by reducing the prerequisite knowledge required to build a solution, expanding the pool of developers beyond IT. But low-code is also a powerful tool for IT departments, which benefit from these same productivity improvements by delivering more applications, more quickly, without more (in fact, often fewer) resources.Â
This is accomplished in two ways. First, it takes less time to drag-and-drop standardized visual objects than it takes to type instructions in a specific syntax. Secondly, some low-code tools handle a lot of the mundane but necessary chores that coders typically would have to handle manually. And they’re why Gartner predicts that low-code will account for 65% of application activity by 2024.
That said, low-code can have a significant downside if organizations don’t have a long-term strategy for it. Left to themselves, citizen developers’ labors often lead to a proliferation of idiosyncratic, fragile, and unsupported applications. Without a common approach to user interfaces, data modeling, business methods, etc., low-code may yield more applications that ironically require more effort from both users and IT alike to learn, use, and maintain them.
Leveraging low-code for the long haul implies a conscious decision to ensure that applications are viable over time. Low-code development is still developing, so most of the rules for good software development should still apply. Regrettably, its ease of creation can tempt people to â€œthrow something togetherâ€ to scratch a particular itch. At scale, this backfires.
It’s generally accepted that application development only accounts for a small part (perhaps 10%) of overall solution delivery. Critical steps take place both before and after construction, including requirements gathering, negotiation, tool selection, design, specifications, debugging, profiling, security, deployment, documentation, user training, metrics, auditing, maintenance, and change management.Â
This delivery cycle matters as much or more than development, but it’s an area where few low-code tools or platforms offer a solution. That’s a shame because failing to account for these steps limits the utility, longevity, and appeal of any application and any overall digital transformation initiative.
This durability issue also has ramifications for application creators who share their handiwork. Those additional users will need training and support. They’ll have differing wants and tradeoffs from those of the original creator. They might even conflict. Those citizen developers might regard themselves to be victims of their own success.
Consistency and Reusability
Organizations are familiar with reusing software, data, and other assets. At least in low-code-land, what’s often overlooked is reusing knowledge, experience, and skills. If one thinks application building is easy, the temptation is to make each one entirely unique.
Without a conscious effort to attend to patterns, practices, and platforms, there’s no attempt to collect institutional knowledge, let alone reuse it. Individual applications may or may not succeed, but they won’t contribute to the organization becoming smarter.
In fact, a laissez-faire approach to low-code development could have the opposite effect. Zero consistency and reuse means users will be in a state of perpetual context-switching to adapt to differing solutions. Calculations, data sets, and automated activities can vary enough to send an organization into a disorganization. IT will run ragged trying to hold everything together â€“ and suffer an even more significant number of complaints â€“ that they seem to cost money yet get nothing done.
If reusability matters, if building a critical mass of information assets matters, and if â€œdigital transformationâ€ isn’t just a buzz phrase but refers to organizational evolution, then having a set of curated rules, tools, and practices is necessary. It’s not about one application but about many. It shouldn’t be about making each application individually easy to build but rather about learning enough from the first five applications to make creating the sixth, tenth, or twentieth application an unbelievably quick prospect and for the company’s users to be able to start using it with zero training.
I’ve mentioned the term â€œcurationâ€ rather than just â€œdevelopmentâ€ and â€œcatalogingâ€ for a reason. Change has to be factored into, well, everything. Expectations get violated. Needs get overlooked. Excellent work can be rendered obsolete by changing conditions. New opportunities get discovered. New feedback gets synthesized. Organizations have to adapt, and applications have to adapt with them.
Code-based professional development has been familiar with a movement known as Agile Development for years. There are many flavors of this, but familiar to most of them is the notion of short, successive development cycles and a commitment to continuous improvement.Â
Surprisingly, fewer members of the world of low-code champion these ideas. Most low-code vendors focus on the construction phase of application delivery. Some defer to the same deployment tools used by code-based development (which aren’t friendly). Most actually treat a low-code project as something disposable, to be replaced with a new, quickly developed application when needed.
That’s a shame for at least two reasons, the first is that we can’t evolve if all we do is destroy and rebuild. The second one is that we can do better work when we know it will be regularly improved; we don’t have to worry (or spend excessive time ensuring) that it won’t be perfect the first time. We can develop it quickly, collect feedback, and make each successive update better and better.Â
This brings us to scale. This includes scaling up to large deployments, but the scale I’m talking about is the ability to build more and more applications â€“ successful applications within shorter periods. Not scaling each application, but rather scaling application delivery.
You can’t scale application delivery without best practices you can rely on to free you from having to rethink everything about every application every time. You can’t scale without reusable assets. You can’t scale if every new application requires user training.Â
Moreover, you can’t scale if every application is responsible for logging, auditing, compliance, metrics, security, deployment, monitoring, etc. These admittedly boring but necessary parts of application delivery are prime candidates for being handled by a low-code application platform, but as stated before, most low-code tools focus on construction and pretend everything else is unnecessary.
Low-Code for the Long Haul
The speed and ease with which applications can be created with low-code is a powerful benefit. And with great power comesâ€¦ you know the rest. When it comes to low-code, organizations must choose between curation and chaos by thinking holistically, developing a strategy, and choosing tools carefully.
This sort of long-term strategic thinking is not something that bubbles up from users. Digital transformation, meaning organizational evolution facilitated by technology, isn’t something you let happen â€“ it’s something you make happen.Â
Low-code for the long haul should be a conscious, curated choice. It falls to enlightened CIOs and IT directors to realize this and lead it because no one else really can.