Halloween is coming up, but thanks to the rise in popularity of low-code tools, IT teams will have one less scary thing to worry about this time of year: shadow IT.
If you haven’t heard the term before, shadow IT is what happens when there are applications running in an organization that the IT department has no knowledge of. For example, an HR team was sick of waiting for IT to provide them with a solution for a problem they have, so they went out and found their own solution. In fact, a survey from low-code provider Mendix found that 77% of IT leaders have a pipeline of requests for new solutions that aren’t being built, so the problem is fairly widespread.
According to a blog post from Kintone, some of the issues that could arise from these shadow IT applications are an increased attack surface for malicious actors, an increased number of the potential points of failure, wasted time from multiple teams coming up with the same application, and reduced collaboration since conversation is spread across platforms.
With low-code or no-code, business users can become developers, and can create tools in a governed way to solve their common problems or improve their workflows. It can be more easily managed by IT this way because they provide the tools to create these applications. In the example situation above, the HR team could work together with IT to develop the application they need, and IT has full visibility over the process.
“As is often the case with a new tool, citizen development or low code to me unlocks a lot of value within the organization,” said Derek Holt, GM of Agile and DevOps at Digital.ai. “It really does start to, by definition, bridge some of the gaps that have existed between the business teams and in the development teams and of course there have been obviously downstream impacts.”
A lot of the best practices that are used in custom development are starting to come into play in citizen development. For example, low code and no code in many organizations are moving from a niche, bottom-up initiative to something at a larger scale. This covers requirements around planning, testing, security, and DevOps on the development side; and change risk, monitoring, and management on the production side, Holt explained.
These are all elements that likely don’t exist in shadow IT applications because business groups don’t have communication with the development or IT teams who could educate them on those best practices.
“[It’s important to be] able to enable your business users and enable the people in those businesses to use a tool … But also making sure that you have the checks and balances and change management processes in place, so you scale the right way,” added Carter Busse, CIO of Workato.
Holt doesn’t think the security and governance requirements change much with low code, but it does require more continuous communication, collaboration, and transparency between teams. In other words, he recommends building bridges, not silos.
“Generally the most effective organizations we see have really great connective tissue between what is often viewed as different functional areas,” said Holt.
Another piece of advice Holt had is to remember that just because you’re creating more technology doesn’t mean you’re adding value. “In fact, we may have just made it easier to make our customer experience worse, right?”
Since you can’t manage what you can’t measure, he recommends tracking the outcomes of low-code outputs in order to determine if changes made drove the business in the right direction.
“I’m not saying everyone needs to move you in the right direction, but you better know whether it did and be able to adjust accordingly because eventually you’ll triangulate your way to the right answer.”
In terms of reducing shadow IT, low code enables IT to be more involved in the process, so Holt recommends operations teams stay engaged in the process as early and often as possible.
“They can be part of the solutioning as opposed to being reactive or receiving it. So I would just encourage folks to play the game on their toes as opposed to on their heels as they’re thinking about what the implications are and how to build bridges within the organization, not moats,” Holt said.