“Oh no! We can’t let those business folks write code and build mini applications.” Sound familiar when bringing this topic up with seasoned IT professionals? I’ve certainly heard it multiple times over the last 3 years.
This fear comes from a simple common pattern. Business hires an intern that can code or a small consulting company to build them a simple application. As they start using it they add more and more features to it. Then the intern or the consultant leaves and nobody understands how this great app really works. So they call the IT department and ask them to support and maintain this monster they have built. Or users call the IT help desk because something isn’t working and they want IT to fix it. Oh and please support and maintain this beast for free.
If that is your environment then yes you have some expectation setting to do before you let folks go at it with Low-Code/No-Code development tools.
To set the rules though take a more positive outlook. Low-code/no-code potentially turns all your somewhat tech savvy business folks into programmers. Aren’t programmers a scarce commodity right now? So great! Additionally these business folks do it on their own time. So they are somewhat free programmers. Awesome! Finally, this can turn your non-programming IT professionals into programmers. Hallelujah!!
Now that we are all excited about the value we can unlock here, let's start setting some reasonable rules.
No harm scenarios:
Stand alone applications that don’t integrate with any of your standard business applications ✔︎
Applications that only read data your user has access to from your standard business applications ✔︎
identity and access management to the application is naturally supported by the low-code/no-code’s technical environment
Department that develops the app will support the app. No calling the help desk. If you call IT get your checkbook out.
I could think of lots of cool applications any user could build with the constraints of the no harm scenarios. To be fair to IT though senior leadership has to be very clear about the last bullet point above.
Your architects can come up with more precise rules of the road for this and further scenarios. I would recommend fitting them into three:
No governance or IT support required (no harm scenario)
Requires professional IT department partnership. Gartner calls them fusion teams (can do harm scenarios)
Requires a ‘certified’ architect for high level design and IT partnership for execution (complex can do harm scenario)
Once you’ve got the rules in place then focus on creating an environment that makes scenarios 1 and 2 more efficient to execute. Technical example would be to have an easy to understand and use API catalog. People example would be to build a community that exchanges tips and tricks and helps each other. Add a COE that can educate and support the community. You’ll see an avalanche of productivity apps being developed by the business and IT.