18/03/2021 | Olivier Eyraud, Business solution manager, Hardis Group
Low-code/no-code platforms, which allow users to design their own business applications, offer the potential to accelerate digital transformation. But in what contexts are these platforms recommended? Are they suited to all circumstances? And what governance and support role should IT departments play?
Developing simple and pilot applications, internally and externally
Low-code/no-code (LCNC) platforms enable so-called “citizen developers”—business-line users with no programming skills—to design their own applications according to IT department-defined standards. They represent one answer to the problem of “shadow IT”. So how do they differ? In a no-code environment, users develop the entire application from scratch but are constrained by the options offered by the platform. Low-code environments, meanwhile, let users add their own code so they can design a handful of specific features.
The idea behind the LCNC approach is to empower users to develop applications for highly specialized use cases. Examples typically include productivity applications like meeting room booking systems, simple workflows (such as for approving leave requests), and self-service portals that customers and partners can use to track their orders or access account information. In most cases, these applications use existing data from emails, Excel spreadsheets and similar sources.
LCNC environments are also useful proof-of-concept tools, providing a platform for testing and approving a new application idea prior to conventional development and at-scale deployment. But regardless of context, these platforms are fully in keeping with the drive for faster digital transformation: the process is agile (fast-track design, functional testing without unit tests), requires no deployment (Cloud hosting), can be adjusted and redeployed at speed, and involves no TPAM budget.
The unique role of the IT department in LCNC application governance
Despite the stated objective of LCNC platforms—to empower users to design their own applications—the need for at least some governance cannot be overlooked. Here, the IT department plays an important role in keeping track of the application portfolio, both to avoid duplicates and to purge unnecessary and obsolete inclusions.
Likewise, by managing the LCNC development life cycle, the IT department is able to identify popular applications that have reached their limits or need improving with new code, specific features, or user-experience enhancements. Some might even require redevelopment via the conventional route—because it’s important to bear in mind that LCNC platforms operate often costly licensing models and offer limited interface and feature customization options.
As a general rule, IT departments are strongly advised to set up a “center of excellence” (or similarly named unit) staffed by a team tasked with helping citizen developers identify eligible use cases, providing design method support, and more generally overseeing the process organization-wide (including sharing lessons learned, and providing or sharing templates).
Choosing the right LCNC platform
Once the LCNC model is approved, all that remains is to decide on the platform. The options are legion—especially from specialized vendors, many of which have their roots in the Business Process Management sector.
But now, some of the biggest players in the market are workplace vendors like Microsoft, which has built Power Apps into Microsoft Office 365, and Google with AppSheet. Other, more recent entrants include public cloud operators such as Amazon Web Services, which launched Honeycode in spring 2020. These platforms have one major advantage: they’re designed for native compatibility with an established, end-to-end environment, which means they support identity management, are easy to deploy, work with existing connectors (SSO, hosting, BI, etc.), use existing cloud servers, and more. In other words, the platform handles the entire process, from initial idea to operational deployment.
But behind this apparent simplicity lie some major drawbacks, first among which is a serious risk of vendor dependency—because it’s impossible to migrate Power Apps applications to AppSheet, and vice versa. So if an organization switches platforms, it has to begin the development process from scratch! And with customers “locked in” in this way, there’s every incentive for vendors to slowly push up their prices.
Even organizations that go with a specialized vendor face similar risks: before signing on the dotted line, they need to be absolutely certain they’re making the right choice—and that the vendor won’t go out of business—otherwise it’s back to the drawing board.
In any event, the LCNC model should be avoided for business-critical applications, which should follow the conventional development path. These platforms are best suited to targeted, operationally focused, low-complexity applications. If doubts persist, the estimated development time frame is a good rule of thumb: if an application will likely require more than 30 person-days to develop, it’s best to follow the traditional route. Remember: the idea is that LCNC platforms should accelerate digital transformation, not force an organization back to square one at the slightest problem.