Low-code application development is not new. As early as the 1990’s, Microsoft Access was used by non-IT developers to build business applications. Employees who understood the business and had some technical aptitude were able to quickly build solutions without having to wait for IT. They could move faster than IT because they could focus on their specific business area and didn’t have to follow disciplined software development practices.
Over time, more and more features were added to these business-developed applications and their value grew within the company. However, because these applications weren’t built following proven and disciplined software development practices, they started to experience issues with quality, scalability, reliability, and security.
Below is a typical sequence of events that was repeated in many organizations:
- Business area develops application to meet their business needs with little or no help from IT.
- Business application no longer works, provides inaccurate results, experiences performance issues, etc.
- Business area escalates the issue so they can get IT involved to fix the application. (Bring in the experts!)
- IT inherits a poorly developed business application that they are expected to repair and maintain.
- IT resents these applications and the business areas that use them.
Scoundrels and Rascals Deliver Business Value
IT started calling these efforts “Rogue IT” or “Shadow IT”. Synonyms for “rogue” are “scoundrel” or “rascal” – not necessarily the best terms to call fellow employees. But it is easy to understand the frustration from IT – especially from Software Engineers who ended up getting support calls (sometimes in the middle of the night) on these poorly written applications.
Regardless, these “rogue” applications did benefit the company in several ways:
- Business value was delivered quickly by employees with strong business expertise.
- They were low-cost proofs-of-concept that validated the solution before engaging IT.
- Introduced new technology to the company.
- Helped to nudge IT to reduce bureaucracy and become more agile.
Low-Code Application Platforms Explode
Fast forward to the present and Microsoft Access has been replaced by low-code application platforms (LCAP). In 2019, Gartner evaluated 18 LCAP vendors – and there were many others that did not meet their evaluation criteria.
Experts project that over 500 million new applications will be built in the next five years. This is more than all the applications built in the last 40 years.
IT will need help to meet this demand.
Gartner estimates that by 2024, three quarters of large enterprises will be using at least four low-code development tools for both IT and business development; plus, 65% of application development will be low-code in this same timeframe.
The Rise of Citizen Developers
Employees who develop using these tools are now called “citizen developers” – a much more friendly term than “rogue” or “shadow”. (Although, I still frequently hear these terms used by IT.) Let’s face it: rogue/shadow/citizen development is not going away. Companies continue to demand innovative technology solutions to delight their customers. Skilled IT software engineers are scarce and in high demand. Low-code applications can help fill some of this gap.
Create a Low-Code Application Development Value Stream
Close collaboration between IT and business areas is important to establish an environment where low-code development can flourish. Jointly, they should build a pipeline or application development value stream that enables and encourages low-code development while avoiding building maintenance nightmares or error-prone solutions.
Here’s how you can create impactful collaboration between IT and business areas:
Educating and Coaching
IT knows how to build accurate, reliable, scalable, and secure software. These skills should be shared with citizen developers in business areas so they also can build accurate, reliable, scalable, secure low-code solutions.
Low-code in IT
To better understand low-code application platforms, IT should learn and be able to build low-code applications. This not only helps IT understand the low-code platform being used by business areas, but it also introduces them to another option for quickly delivering business technology demands.
IT can work with business areas to automate key aspects of the low-code application development value stream. DevOps practices can increase speed and quality by automating the pipeline. A framework can also be established to encourage reusability.
Agility with Appropriate Governance
The term “governance” gets a bad rap when organizations adopt agile practices. However, some level of governance is important to ensure good product development practices are followed – especially securing corporate data. The key is striking the right balance between appropriate governance and excessive bureaucracy.
Communities of Practice (CoP)
A team of employees who have an interest or passion for LCAP development can reinforce sound development practices and should include team members from IT. A CoP can help determine if a low-code solution is right for a given business problem, encourage reuse, and share lessons learned among citizen developers.
Get Started and Improve
Don’t delay getting started until all the aforementioned items are in place. Get started, experiment, learn, and improve. Prioritize those things that will deliver the greatest value to your citizen developers and (ultimately) your customers.
Collaboration is Key to Future Success
Organizations will continue to demand innovative, high-value, and high-quality technology solutions that can be quickly delivered. High demand for new applications, coupled with the scarcity of skilled IT software engineers, will require other solutions to meet this demand.
Adopting low-code application platforms may be a viable solution but will require collaboration between IT and business areas to be responsive to business needs while avoiding the pitfalls of the past.
Hopefully this will avoid our calling each other rogues, scoundrels and rascals in the future.