OK, so I know I’m a bit slow getting a blog out about Localgovcamp, and it isn’t really the beginning either – for that you have to look way back over the years to the time when I first found myself part of a national and international debate about open standards in the public sector. (More about that in another post) But it is a new beginning, and has spurred me on to start blogging, so let’s use it as a handy springboard into the world of digital, agile, and open architectures.
It was fantastic to spend a day in Birmingham, with lots of people who care about local government, being able to share the things we’ve done in Bristol, and hearing from others – finding areas of common concern and ways we can support each other. At the moment most of these ways are about thinking, methods and some of the softer aspects of digital – user stories, user research and UX sketches.
But every time I find myself in these conversations I’m thinking – surely we can find ways to start sharing the more hard edged stuff – business rules, front end code, data structures and message formats, integration patterns and back-end code. This is significantly harder, because we all have such a variety of systems in our councils, based on different technologies, some open source or open standards based, but many proprietary and closed.
So quite often we step back away from this and just get on with our own work, solving the problems we face in our councils, for our citizens and businesses. Which after all is what we are paid to do, so it’s not wrong that we focus our energy on this. But ultimately, wouldn’t the value for our citizens be so much greater if we all built on pre-existing foundations, using pre-fabricated building blocks, rather than bespoke designing each time?
You could say this is the theory behind us all buying from the same small number of suppliers – they invest in the best practice and the business rules once for their hundreds of customers to benefit. But let’s be honest – very few of these suppliers really get user needs driven digital services. Very few of them do truly transformational service design, and if our local circumstances aren’t exactly the same as the other councils they’ve developed for, we have to pay for bespoke changes that never quite do what we need and lead to complex upgrade paths.
More importantly for the challenge we all face as councils, which you might describe as the fundamental transformation of local government from a service provider into a different kind of agent of democracy and shaper/influencer of the market of services (and catalyst for the design of services), these models of supplier controlled system development and delivery cannot unlock the “triple open” approach to architecture that we need to connect citizens, the council and service providers – open data, open standards, and open source software. (Big assertion I know… )
In Bristol, we’ve been hammering away at these issues for more years than I care to remember – sometimes for really quite tactical and pragmatic reasons to do with lack of money, at other times with a touch of post-rationalised principled planning, but only recently would I say that we’ve been genuinely strategic about our approach. For the past 5 years we’ve worked to define and articulate an architected approach to our whole enterprise, and openness is a central characteristic of it.
It’s not an easy path to go down. Frequently people look at me and ask why we haven’t just procured an off the shelf solution for something we’re constructing from a number of products and services, in a relatively loosely coupled way. There’s a seductive ease to “just buying it” – we don’t have to do as much difficult thinking, working out how to design and build a system that interoperates effectively, managing multiple supplier relationships, and operating/maintaining a more complicated infrastructure.
But replacing one set of siloed proprietary systems with a slightly shinier newer set of the isolated point solutions built by a new set of closed vendors just rolls the lock-in forwards another generation. It doesn’t lay a foundation for solving truly strategic problems, just improves the way we do things now.
There’s a lot more to say about this, and it links to the many discussions that have been going on about the pros and cons of a Local GDS recently. In particular, there’s one strand of the issues that I think has been missed by most people so far, whether they are for or against the idea: if we consolidate many systems and suppliers into one Local GDS, what impacts will that have on the market, and what forces will be brought to bear on the people leading and delivering such a consolidation as a result?
I’ve spent long enough crafting this without publishing it… I’ll get into that topic in another post 🙂