Low-Code - A Compromise of IT and Non-IT Developers?
The Culture of Low-Code
I suspect there is a bit of “maker” in all of us. I, for one, do like to tinker and recently wrapped up construction of a radio-controlled, semi-submersible boat with a life-size foam Great White shark fin attached to its top. While there is no intent to frighten anyone out of the water, the appearance of a moving shark fin in a Minnesota lake should evoke a laugh or two. It will need to wait until spring for sea trials since I did not include icebreaking features.
Given the maker mentality and continuing efforts in the education community to ramp up digital competence, many in the professional workforce are eager to, as social commentator and musician Joseph Barjack said, “Question authority... Then ignore it!” Those professionals now write code, develop applications, and create automation without the advice, help, or, in many cases, the oversight of trained technology professionals.
Whether called for or not, working professionals often see their corporate technology resources as getting in the way of making the business better. Project ideas disappear into an endless backlog. Major deployment and upgrade efforts blow through budgets and miss deadlines. Projects miss requirements. Systems experience downtime and the list goes on and on. One might wonder why anyone would choose the profession we share.
So why not solve a problem yourself?
The automation software vendors certainly would like you to. Low-code and no-code (is anything really “no” code?) citizen development is all the rage—just download some extension or charge any one of a hundred assorted products to your corporate credit card. Install it, watch a 20-minute instructional video and you are on your way to solving all the problems that the darn IT department cannot, or will not.
Is it really that simple?
But as working technology professionals, we understand it may not be that simple—at least not in some cases. How does automation affect other systems? Is it propagating errors? Was it tested with unexpected inputs? What is the business impact when it does not run? Who gets notified in case of an exception? Who understands the code base enough to support and extend it? Again, the list goes on and on.
Yet there are substantial business benefits from citizen development. The efforts solve real problems in near real-time. Simple automation needs do not disappear into the IT backlog. Management is happy.
So, how does an enterprise reap the benefits of citizen development without endangering the organization while making certain that smart professionals will stay (since leaving is a real possibility in today’s labor market)? The answer lies in a compromise between IT and that non-IT developer community.
Finding common ground to foster innovation
Such compromise must find a common ground where projects get cataloged, some form of quality assurance exists, some form of business risk evaluation occurs, and so on. One must balance control and autonomy in a way that fosters innovation—something not simple to do.
An often-overlooked aspect of automation efforts, citizen developed or not, is measurement.
- How is this effort affecting the business? Is the operational return on the development effort 20 years?
- Did a labor savings projection of two FTEs ever come true?
- Did the automation simply drive business staff to do the same thing, at the same cost, only differently.
Citizen developers often approach projects with grand claims. Optimism is a great and necessary attribute in business, but there must be a recognized means of ensuring the claims come to reality.
A Center of Excellence could be the answer
The idea of an automation center of excellence (COE) is a common approach to management for many companies. COE staff can advise on standards, mandatory requirements, tooling, and measurement without turning efforts into full-blown IT projects. They can advocate for the citizen development community and still ensure good and proper things happen. There are other ways to balance control and autonomy in a way that fosters innovation, but COE is often a proper choice.
Citizen development is here to stay. New tools and techniques appear every day. The API economy simplifies connecting systems in ways any technically savvy business professional understands. Those citizens will never replace traditional IT, but they augment it and help to expand an enterprise’s technology strategy. Embrace it, but ensure you manage it.
And if you see some clickbait link about a Great White loose in a Minnesota lake, you will know the sea trials were a success.