I saw this article the other day, in which the author warns of the risk in allowing low-code solutions to develop in (large) organisations. The argument made was that it encourages "data silos" that don't connect to the rest of the corporate structure, resulting in inefficiency, fragmentation and loss of control.
While there's some truth in this, an important point is being missed:
Innovation doesn't always come from the center
In top-down, hierarchical organisations, innovation doesn't just happen at the center; in fact, it often doesn't happen there at all. The focus there is more on holding onto a rigid structure at all costs to prevent it from fragmenting. Central IT departments don't in general value input from non-professionals elsewhere in the enterprise; they certainly don't go out actively looking for it.
A low-code solution will spring up in some random corner of an organization, where a problem needs to be solved quickly and for which no solution is forthcoming from the center. The people on the ground who identify the problem are not professional programmers and they don't have connections to the IT department, so they reach for whatever solutions work for them.
In some ways, these local initiatives work in the same way as a skunk-works. The difference is that the latter is set up as deliberate corporate policy, given an often quite vague brief then left to get on with it unchallenged. Low-code is an enabling technology that allows much the same to happen, but in an unoffical way. Provided the extra effort doesn't impact on normal performance it can do little harm.
The people who embark on such projects are usually highly motivated but are frustrated by their inability to get anyone to listen to their complaints or suggestions. Low-code allows them to create local solutions using their existing skills, without the need to learn new ones. This is nothing new. In the early days of the microcomputer revolution (mid-1970s), IT departments were manned by professionals using minicomputers such as PDP-11 (remember them, anyone?). If we proposed the use of microprocessors (8080, 6800, etc) we were laughed out of the room. So we went away and did the job in our spare time using these new devices and without telling anyone until it was all finished. Tell me, who was right?
The answer is not to decry such attempts from a position of lofty superiority, but to actively seek them out, encourage them and work with them. Yes, they will sometimes be disruptive, but the ideas they reveal will often be ones that can be of massive benefit to the organization.
Oldest comments (0)