Published on the 16/02/2023 | Written by Heather Wright

No, low code and app portfolio governance are not the same… 

Adrian Leow is spending a lot of time talking low-code governance. 

As Gartner’s Sydney-based vice president within the applications group, he’s been fielding plenty of calls from businesses about low-code in recent years, and says right now, governance is ‘the really hot topic’. 

“Inevitably, clients first come to us looking for these tools and wanting a list, then six months or a year later they’re producing all these apps and now they’re really trying to sort out their governance because they didn’t necessarily think about it in the beginning,” Leow told iStart. 

“There’s a lot of hype around low-code but it is very powerful – if you really look into the best tools for the users in your company.” 

Instead, he says, many companies assume low-code governance will fall in line with the application portfolio governance they already have in place. 

He’s got bad news: It doesn’t. 

“Low code governance is not like application portfolio governance, because the whole software development lifecycle (SDLC) is thrown out the door,” he says. 

“If you were to have a typical application not created from low code but following SDLC you would have phases – the requirements gathering phase, then design and testing phases and 18 months later you release it and have a bunch of CRs (continuous responses). 

“That whole thing doesn’t exist in low code, where you are probably going to have a couple of weeks training for a user, then they get licensed and certified to use the product and within a few days they’re producing apps.” 

Within a few weeks they may have produced five or six apps and in six months there might have been 15-20 apps tried, tested and produced – with 50 percent of them abandoned. 

That abandonment leads to orphan apps – and potential attack vectors which need to be handled. 

But low code also leads to another situation Leow is warning companies about: Low-code sprawl, with one person trained and licensed to use the tool, creating an app and sharing it with a couple of people in their workgroup, who then share it with a couple more, who each share it with a couple more… 

“Before you know it you’ve got 20-30 people using one low-code created app, which is great from usage perspective but not great necessarily from licensing perspective for procurement or the division managing expenses,” Leow says. 

Most vendors have a tier pricing structure, Leow notes, adding that in a number of instances, clients have found themselves bumped into higher tiers which they hadn’t budgeted for. 

“Going from tier to tier, depending on which vendor you are with, can be very expensive.” 

Low-code vendor tools all have different extents of governance tools for different tasks, within them, he notes – and that needs to be a consideration in choosing vendors. 

“Assess what low-code governance tooling exists in which ever vendor you are assessing, and make sure it addresses your particular need, because every company will have different priorities, be it orphan apps or other things like that.” 

A third issue he sees frequently is a proliferation of different low-code tools in use within an organisation as different business units embrace different tools from vendors who they already use, such as Saleforce, ServiceNow or Microsoft. Many vendors offer low-code options – Salesforce’s Lightning, ServiceNow with AppEngine and Microsoft with PowerApps, which can be particularly alluring given it comes free in a basic version if you’re already using Microsoft Office 365 or apps such as Dynamics. 

“When you use different vendors in the low code space you will be subject to a degree of vendor lock in. It’s important if you are planning to have that technology roadmap of having everyone using the same tool, to think about it right up front because further down the track it will potentially be very expensive from a resource and investment point of view, and it’s not necessarily straightforward.” 

A lack of visual modelling standards, graphical layout standards, ecosystem interoperability, API standards and business logic interchange, can make porting apps problematic. 

An adaptive governance framework 

Leow says companies need an adaptive governance framework, with the governance stepping up as app complexity and business criticality increases. 

The framework starts with a self-governing ‘safe zone’ for simple apps, only used by a few people. 

“You want self-governing low-code created apps to exist, because you want innovation and that innovation will come from enabling those users,” Leow says. 

If, for example, you find a lot of apps you didn’t expect being created, Leow says you might need to bring in some structured services such as performance and security testing. It’s what he calls a ‘gate’ taking a company into the supported zone, where apps are ‘co-created’ with pro developers and adaptive governance. 

Beyond that lies a ‘danger’ zone where apps require IT oversight and governance before release. Leow cites the case of a large insurance company which ran hackathons, open to its business teams.  

“After one hackathon, managers saw what had been created was pretty useful and decided to roll it out to the external agents. But when you roll it beyond the external firewall that brings in a whole other extent of checks and balances and you need IT oversight and governance to do that. It’s still a low-code created app, so it doesn’t necessarily need to be refactored, but now IT does the checks so it can be working outside the firewall for external agents.” 

The final steps is a newer area, where software engineering teams are embracing low-code tools, particularly for the likes of modernisation programs. With excellent UX a key factor in app adoption and use, software engineers are increasingly looking to low-code tools rather than using virtualisation or screen scraping which produce ‘terrible UX’. 

“We’re seeing tools becoming more sophisticated and vendors coming to market to address demand from software engineers for low-code,” Leow says. Retool is one of a handful of such offerings.  

“It will never replace traditional application development, but it can make their work life a lot more efficient in the long run as every business becomes a digital business.” 

Which leads nicely to another factor Leow says companies need to consider when looking at low-code: The user persona. 

“You need to really understand who your actual user of the tool will be. Historically it’s been citizen developers, but now we’re getting software engineers. 

Being very clear on your use case too, is critical. Low code isn’t a technology on its own. Instead, Leow says it’s an approach made up of multiple different technologies. There’s low code approaches for app development, or automation, and low code approaches for business process management areas, among others.  

“We always advise clients to make a very clear use case on what it is you are trying to use the low-code tool for.  

“It might be the use case of something like workflow automation, which can break down to process workflow and so on. So you might scan the BPM market to see who can do low code, because not everyone can. Or it might be that automation is your priority, in which case you look to the RPA market and vendors who can do that in a low code manner. 

“That’s how you begin narrowing down on who is the most appropriate vendor for you, because it is not just one overall technology market, it’s just an approach to getting whatever task it is in that particular technology market done,” he says. 

“There’s a lot of hype around low-code but it is a very powerful way to enable your business and digital transformation to occur and can be a source of innovation if you really look into the best tools for the users in your company.”