How low (code) can you go?

There’s an increasing amount of talk in digital circles about low code. These are systems for building systems: ways of using simple drag and drop interfaces to build out workflows and databases to deliver business processes. Some low code platforms of note include Matssoft, Mendix and Outsystems amongst many. There are also a number of more traditional forms and workflow packages that market themselves as low code – whether they are or not I’m never entirely sure. Perhaps it doesn’t matter.

At Adur & Worthing, Paul introduced Matssoft. The team there has built a range of apps, including ones handling HR processes, waste services, asset management, FOI and complaints handling, and a range of housing services. There’s details on Paul’s blog, and it is a great example of how a corporate commitment to a new way of building software to deliver services can see real improvements and innovation.

One of the marketing messages many low code vendors like to trot out is that around the idea of being able to do away with developers. Having managed a rollout of low code and attempted various projects myself, I am not convinced of that. I’m reasonably tech savvy, and yet have never personally been able to build a functioning bit of software with a low  code platform. My brain just isn’t wired in the right way. Largely this is because, at a fundamental level, most low code is a front end to a database, and designing databases well is a skill, if not an art.

So I don’t think low code is a way for organisations to dispense with developers. Instead, it can change what developers do, and speed up the process of getting ideas made into working software. They are especially useful, I think, at the beginning of a transformation programme, perhaps when one is looking for some pilot projects to prototype approaches and methods. Buying handful of licences for a low code platform and churning out a few apps saves a lot of bother compared to procuring some heavy IT designed for some future model that may or may not ever happen.

Low code, in my view, is best suited as a way of quickly building out bespoke workflows that don’t fit easily into an existing line of business system or platform.

For example, most organisations are chock full of spreadsheets and databases (whether made in Access, or a Visual Basic/SQL server concoction) doing small but vital pieces of work. These are often stored in network drives and digital or IT teams may not even be aware of their existence. They also don’t have the advantage of being cloud native apps, with reduced capability when it comes to mobility, usability on a range of devices and can have a high maintenance overhead.

So overall I am a supporter of low code and encourage organisations to explore how it can help consolidate that morass of unknown Excel and Access based workflows into a more modern, usable and less risky platform. But don’t expect necessarily to be replacing big line of business systems overnight, nor saving money by reducing your developer headcount.

Photo by Helloquence on Unsplash

LINK: “Making public policy in the digital age”

When the policy is broken, the service fails. And when the service fails, trust in the institution providing the service diminishes. More often that not, high-profile breakdowns are seized upon as a failures of technology or implementation. The truth is that policy is often the culprit.

Original: https://medium.com/digitalhks/making-public-policy-in-the-digital-age-1900a248578c

LINK: “Bezos: A CEO Who Can Write”

Bezos’ letters make splendid material for a Business School course on Strategy and Communication. A caveat applies, however. Most of the strategies and practices advocated by Amazon’s founder have broad applicability, but a central mystery remains: Bezos himself, his combination of early life experience, intellect, emotional abilities and communication skills. Being Bezos isn’t teachable.

Original: https://mondaynote.com/bezos-a-ceo-who-can-write-2f368ee36599

LINK: “Service design at NHS Digital”

user’s point of view – from the very beginning of how users become aware the service exists, to the very end of them leaving it. But what makes service design different from just thinking about the user journey, is also the need to design the service from front to back.

Original: http://transformation.blog.nhs.uk/Servicedesign