Computers started large and expensive so the business problems they were tasked with solving were similarly large and expensive.
But most business problems and processes are small and not “worth” investing large amounts of time and money in. These problems are also usually out of management’s sight because they affect workers who are spoken at not listened to.
But what if there was a way to bypass the gatekeeping of IT, the obsession of Finance with business cases, and the obliviousness of management?
Enter “low code”.
As ever in technology “low code” is not a new concept. Over 40 years ago the “End of programming” was on the front page of computer magazines.
“Low code” solutions exploded as the microcomputer grew. Why wait for the “priesthood” to implement that stock control system on the company mainframe when you could create it in dBase or FoxPro and run it yourself?
Soon people were using tools like Microsoft Access or Excel to build tools to support their jobs.
You are a government department which gives out grants? Well you could implement a Grant Management System but the time to get a business case through and then for your usually outsourced IT provider to implement meant it would not go live until after the grant scheme was launched.
So people would rationally implement a simple system in Access or Excel to record all the grants. It was intended to be only temporary but over time it becomes the single source of truth as the Grant Management System never quite does what people want and senior stakeholders want nice reports which you can turn around instantly rather than having to put in a Change Control Request to an overloaded help desk.
Then there is a scandal about a particular grant. Auditors, the police all get involved and now the single version of truth is discovered to lack controls, backups are undocumented and scant, the people who created it are long gone, and it only runs in a 16bit version of Excel in Windows 3.11 and NOBODY better turn the machine off.
So is low code bad? No, it can be really helpful but it is not magic. Technology is bedevilled by magic pixie solutions and they will always come back and bit you.
Think about the classic three tier architecture for business systems and how low code may be applicable in a non-exhaustive way:
|Tier||Issues||Low code potential?|
|Presentation||Accessibility – Is the service accessible? Does it meet legal requirements?|
User Experience – Is there a consistent, safe and supportable UX across the service? Are changes logged in a central repository? Can you deploy and rollback across the service?
User Interface – Does the UI work across mobile and browser? Can you update a component and redeploy?
|Business logic||Consistency – How is consistency maintained? Is there a single version of the truth?|
Auditability – How are changes captured? Who made the change? Is there a dual key change control system? Who is alerted when changes are made?
Maintenance – What happens when an underlying aspect of business logic changes, for example VAT rate? How does system A talk to system B?
Security – What stops someone from misusing the system? What picks up obvious boundary conditions, for example duplicate payments, new accounts etc?
|Data||Privacy – Do you hold personal data? Who did the Privacy Impact Assessment? |
Security – Is the data encrypted at rest, in motion? How much would a data breach cost you?
Ownership – Who is the named person or people who owns the data internally?
Integrity – What maintains the data structures and contents? What stops bit rot?
Audit Trail – How do you know who has access to the data? How do you alert people about problems?
And don’t forget the issues which encompass all three tiers, like name formats and access controls.
Sure, this is a temporary system which will never hold any sensitive information and it doesn’t matter of it goes down for ages or that there are no back ups and…
Look, low code has a very useful place in the toolset but ask the right questions up front.
Not when it is too late…