There is a huge opportunity for local authorities to share common digital service patterns for highly defined, commoditised services that are repeated across multiple organisations. For services like reporting missed bins, FOI requests and complaints for example, how fundamentally different should the user journeys for these services be between individual authorities? Or, put another way, at a time of such pressure on public finances, can we continue to justify the level of local variation in the design and delivery of these services that we continue to see across the country?
The low code debate seems to have really kicked off.
The low code platforms we’ve tried place a big emphasis on making the lives of developers simpler (or redundant). Unfortunately, we notice this is at the expense of user experience. Low code makes it harder to take a user-centred, design-led approach.
When creating, you have to follow the platforms’ chosen UI components and design out of a prescribed box. Once completed, you can then tweak to meet your users needs. As the platform uses its own functionality, you are also restricted by what’s been created so far. It’s a world of functionality first and user needs later, which never ever ends well.
After careful consideration, we went for what I think was a good, pragmatic compromise. Our chosen open standards platform (this is a must), providing a “low code” development environment, has a fixed enterprise licence fee that means we can not only build unlimited apps for ourselves, but can build apps for any public sector body operating in our geography at no additional cost. Development time is much faster than it would otherwise be, and the skills required are significant, but lower than other development environments.
Worth reading both in full to help you decide if low code fits into your strategy.
As a co-founder of Blogger and Twitter and, more recently, as the chief executive of the digital publishing platform Medium, Mr. Williams transformed the way millions of people publish and consume information online.
But as his empire grew, he started to get a gnawing feeling that something wasn’t right. High-quality publishers were losing out to sketchy clickbait factories. Users were spending tons of time on social media, but they weren’t necessarily happier or better informed. Platforms built to empower the masses were rewarding extremists and attention seekers instead.
Is it modernize or die? Or modernize and die? For banks updating their computer systems with secure mobile features it can be both. Many run mainframes on legacy code that’s gone dark — no one understands it anymore.
In a fairly complex world, everyone yearns for a simple solution. The one thing they should do to make things better. The single solution to all their problems. Digital transformation is no different, and many of the marketers working in this space know it – that’s why they usually claim that their ‘platforms’ will deliver everything an organisation needs to change itself for the digital age.
Sometime people read a single solution into things when it isn’t there. A good example would be my post the other day talking about the uses of low code platforms. Several people got in touch questioning my assertion that it was the answer to all of local government’s problems. I replied pointing out that it wasn’t my assertion, and low code won’t fix everything. It might help for quite a few things though.
Overall, I am always very nervous of transformation programmes that have a single view of the operating model of an organisation, particularly when we are talking local government, which delivers such a bewildering array of services that it would surely be impossible to have just one way of changing and organising them all. Are there really that many similarities between running a theatre and processing benefits? Or picking up waste and community development?
Instead, part of laying the foundations of an approach to digital transformation should be developing an openness to trying new tools, techniques and technology, and an awareness of all the possibilities that are out there.
On the tools and techniques side, this means having a really good knowledge of ways of doing human centred design, innovation and delivery. Check out IDEO’s resources on this, along with the 100% Open toolkit, and of course the GDS service manual.
For technology, really consider the capabilities needed to deliver the outcome your users and your organisation want to achieve. See if you can match those to what you already have, but don’t shoe-horn them in. Think about the maturity of the capability you need: if it is really cutting edge, you may need to build it yourself (whether in-house or outsourced); for everything else there ought to be something on the market to suit. Whatever you do, don’t get bogged down trying to build silver bullets – a universal case management system for everything, or some kind of middleware utopia that makes everything talk to everything else. You’ll end up tying yourself into knots and running a huge IT programme, which is nobody’s idea of fun.
As I said, by all means re-use capabilities wherever you can. It might be that you do end up using one case management system for everything, because it works. Great! But find your way there by iteratively re-designing your way through services, matching capabilities to outcomes, and not through the implementation of a grand technology project.
So is there an operating model that can be applied to everything an organisation does? Probably not.
Is there a change process that can be applied to every service you deliver? Probably not.
Is there a technology platform that will enable you to replace every other system currently in use? Probably not.
Should you try things out, find some alignment between the outcome you want to achieve and the stuff you use to get there? Probably, yes.
Systems analysis at the ‘front end’ of service design can help us to better understand complex social problems and identify opportunities to respond more effectively and profoundly. Equally, systems thinking provides tools and mindsets to understand the power structures and ‘system immune responses’ which so often kill new solutions before they get off the ground.
At Adur & Worthing, our use of low code is core to our service design programme and the main tool used by our central digital team in change projects. We don’t go this way every time — we’re not purists — but time and again, we prove to ourselves it’s the better way.
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.
We create almost everything on the internet, but we control almost none of it.
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.