Category: Systems
A working definition of Government as a Platform
Government as a Platform is a phrase coined by Tim O’Reilly in 2011 and defined and redefined by all sorts of people, organisations and governments ever since. This post offers a whistle stop tour of about 20 definitions and descriptions before condensing them all into one:
Reorganizing the work of government around a network of shared APIs and components, open-standards and canonical datasets, so that civil servants, businesses and others can deliver radically better services to the public, more safely, efficiently and accountably.
There’s a lot of concise power in that and if the intention is to focus primarily on the platform, it works pretty well. But if the intention is to focus more on the government, it has two pretty serious drawbacks. One is that it makes the surprisingly common assumption that government is about service delivery, overlooking all the things which governments do which are not that and underplaying the place of government in a wider political system. The other is that ‘accountably’ is having to carry a very heavy weight: it is presented as ‘the equal’ of safety and efficiency, but only in relation to the provision of better services. That really matters, of course, but it is a long way from being the only thing that matters for the governments of 21st century democracies. But all that also illustrates, of course, the strength of this approach – by setting out assumptions and approaches so clearly, it becomes possible to have the debate in the right place.
Lets talk about plugs
The value and importance of data standards are explained by analogy with the value and importance of electrical standards. It’s a good choice – the analogy works well even at its simplest level, but is also a good way in to some of the complexities which lie not far below the surface. And the post asks by subtle implication – though understandably without answering – how standards are set for the setting of standards.
What’s wrong with best practice?
Best practice used to be best practice, but increasingly the argument is made that best practice isn’t necessarily best practice at all. This post does a through job of explaining why that might be.
It’s pretty clear that in complex real world systems, attempting to specify the steps towards an outcome with complete precision is unlikely to be helpful. It’s also pretty clear though, that many tasks and processes do have a substantial technical element for which there are best (or at least better) ways of doing things. The value of checklists – of structured compliance with a predetermined sequence of actions – has been clearly demonstrated for pilots and surgeons despite (or perhaps even because of) the fact that there is substantial variation in the context in which tasks are performed.
There are also more subtle – but no less real – forms of best practice. The shift in many areas of activity from basic competence to real expertise comes from the acquisition of tacit knowledge. Best practice is thus what best practitioners do – which doesn’t mean that what they do can be readily codified and copied, both because distillation of that kind is hard, and because the subtlety of judgement which experts bring is almost certain to be lost in the attempt. So perhaps the problem with best practice is not that people try to find it and apply it, but that they conflate adaptivity to complex systems with process compliance.
The argument of this post is that it’s worse than that, that best practice is an intrinsically unhelpful concept. In the specific context of organisational change – which is the starting point for the post – that may be so (though even there it is not meaningless to talk of best practitioners). But perhaps a better conclusion would be that for all its risks and limitations the idea of best practice shouldn’t be wholly abandoned. There is best practice on best practice which is worth understanding and developing.
#NextStageRadicals
This post is a double winner. The post itself, by Andy Brogran, has some important insights, but it is prompted by a presentation by Mark Smith which is a compelling account of what happens when you think differently about the delivery of public services and is well worth watching in its own right.
Brogan’s post includes a particularly clear and succinct account of why a process standardisation model borrowed from manufacturing is particularly unhelpful when thinking about the design of services – manufacturing works to deliver standard outputs from standard inputs through a standard process. But public services do not start with standard inputs and so cannot create value by applying standard processes to deliver standard outputs – and indeed the attempt to do so risks making thing worse, not better.
That serves to frame an account by Mark Smith of the work he has led at Gateshead, breaking into established processes to work out needs and root causes. An overdue debt can be a trigger for enforcement action, at risk of triggering a further downward spiral, or it can be a signal of an underlying need which, if recognised can be addressed. This is a combination of powerful, human examples and pragmatic approaches to understanding and meeting needs:
‘How much of what we do can we do to you?’ That’s not a great question. ‘What does a good life for you look like, how might we help you with that?’ That’s a better question.
Where system change meets agile practice; the multidisciplinary primordial soup
It’s been clear for a good while that the boundary zone between an agile project and a less than agile host organisation is often rife with friction, incomprehension and frustration. The value of reducing the friction is obvious; the nature of the best lubricant rather less so.
There are various more or less mechanical ways of approaching this – treating it essentially as the alignment of two models of governance. This post comes at it at a rather different angle, with a strong emphasis on finding approaches which deliver psychological safety for those involved and which recognise the different (and ideally complementary) value of different perspectives. Agile projects should carry on being agile, but the right way of thinking about systems is systems thinking. That sounds ludicrously trite, but is both less obvious and much harder than it sounds. As ever, Catherine Howe provides thoughtful guidance through the complexity.
Government as a Platform, the hard problems: part 3 – shared components and APIs
The third part of Richard Pope’s strategic musings is as thought provoking a reflection as the earlier two, though this post is perhaps making a rather different point from the one the headline suggests.
It opens with the idea of small pieces loosely joined, which remains one best descriptions of the web and of quite a few other things besides and leads smoothly into the idea of shared components and services across different governmental organisations. On the face of it, that makes a lot of sense in terms both of system efficiency and of delivering coherent services. Institutional and power dynamics within governments don’t make that easy. The level of trust within governments can be surprisingly low to those who look from the outside and see something monolithic. There’s a whole host of reasons for that, but one of them is the lack of recourse if things do go wrong, with an understandable reluctance to place reputation and service quality on a foundation which is not itself robust. And so the post arrives at the fundamental question, which is not to do with components or APIs at all, other than as the visible symptom of a much deeper issue:
The question governments therefore need to answer is this: what are the appropriate characteristics of institutions capable of operating shared infrastructure for the greater good rather than the priorities of a thematic agency, while remaining accountable?
One answer is to create new institutions whose job is to do that – GDS in the UK is an example. But if, as this post suggests, that model is under threat, that may be a sign it might not be the optimal approach either. So the problem remains very real, the search for solutions continues. Networked government – of small pieces, loosely joined – remains elusive.
Beyond human-centred design, to?
A year ago, Cassie Robinson wrote a great post on why the mantra of starting with user needs was too narrow an approach to understanding the wider context of service design. This post builds on that one to explore eight types of design, or rather eight approaches to design thinking.
They don’t flow from one to the next in a completely sequential way, but they do broadly represent a gradual zooming out from the simple base case of individual user needs, starting with relational design (thinking about those directly affected by a service, not just the individual service user) and going all the way to life-centred design, the recognition that design takes place in an ecological context, at every scale from local to global.
It’s pretty clear that these eight approaches aren’t discrete or sequential, and indeed that they blur into each other. So the response of the designer should not be to pick the one or two which seem most immediately relevant, but to reflect on how the presenting problem is best understood in the wider context. This post is a great starting point for framing that thought process.
Machine Learning Meets Public Policy: What to Expect and How to Cope
This is the video of a conference talk by Ed Felten, which is fascinating for a number of reason. He has been thinking hard about technology and the policy consequences of technology for a very long time, and doing so with deep technical expertise (on the explicability of algorithms, to take just one example).
But he also has been at the heart of the intersection of technology and public policy – a one man One Team Government – including a couple of years in the Obama White House. This talk is primarily about how machine learning lands in a public policy context and is immediately addressed to an audience at a big AI conference, whose perspective can be assumed to be technical.
Given that, the starting point is to underline a critical difference in perspective. At least in principle, science and engineering are about a search for truth. Democracy is not just not a search for truth, it is not really a search for anything. And that difference is simultaneously obvious, a strength and a source of deep confusion and misunderstanding
Democracy is not a search for truth; it is an algorithm for resolving disagreements
But this talk is interesting not just to an audience of technologist having the world of public policy explained by one of their own who has ventured into a strange and distant land. Given the importance of AI and machine learning – and indeed technology change more generally – to almost every aspect of policy, it is jut as important for policy makers and players in the democratic process to understand how their world is perceived. And from that perspective, this is a fascinating account of a strange world by a participant-observer who has retained his distance and brings a distinct professional perspective.
Attempting to teach parliamentary procedure to machines
There’s no getting away from the fact that parliamentary procedure is pretty arcane and that modelling that procedure adds a still more arcane overlay. But this is a beautifully reflective post which wears deep expertise very lightly to share thinking which is relevant well beyond the immediate parliamentary context.
Two points which should resonate far beyond the Palace of Westminster are worth pulling out. One is that parliamentary processes may have some extreme characteristics, but they also have some characteristics which people involved with other kinds of information flows will instantly recognise. It may or may not be possible to express definitively how the system should work; for different reasons it may or may not be possible to capture in detail how it does work, particularly if that is in some circumstances indeterminate. But taking an almost anthropological approach to understanding systems is both an art form and an investment which needs to be made.
The second is that for all the power of starting with user needs, that is necessarily limited if some kinds of needs come into being only as a result of building a system which satisfies them. In a nice nod to George Box, the post ends with a bold claim for the art of system modelling:
The models are only ever maps, but if they’re good enough to be useful they can be useful in ways the map designers never considered. No amount of requirements gathering or user research will ever compensate for omitting the work on modelling, because user needs are emergent from use and emergent from materials.
Payday loans and the missed opportunity?
Don’t be misled by the title, this isn’t really a post about payday loans. Instead, it explores the fascinating contrast between the approaches HMRC (for tax) and DWP (for benefits) have taken to opening their services to third parties. The basic story is pretty simple: HMRC has a long pre-internet history of working with third party intermediaries which it carried forward into its thinking abuot online services (at one stage their ambition was not directly to offer an online tax return service at all); DWP’s history is much more about direct delivery, and that tradition similarly has been carried forward into the online world. The post makes no pretence to neutrality on the central question of which was the better choice, HMRC is clearly seen to have won that argument hands down.
The post is good on the advantages of the open method and the opportunities that could create (including the ethical payday loans of the title). But it doesn’t address the fairly central question of whether there is a reason for the difference. After all, HMRC’s administration of tax credits, which are a benefit in everything but name, didn’t get the same open treatment as their revenue-raising lines of business. The question of whether a version of HMRC’s trust model for taxpayers and their agents could be translated to the benefits system is one well worth further reflection.
All change is system change
An odd thing about many large organisations is that change is seen as different from something called business as usual. That might make a kind of sense if change were an anomalous state, quickly reverting to the normality of stasis, but since it isn’t, it doesn’t.
If change is recognised as an essential element of business as usual, then lots of other ideas drop easily into place. One of the more important ones is that it allows and encourages better metaphors. The idea of change as something discrete which starts and stops, which has beginnings and ends, encourages mechanical parallels: like a machine, it can be turned on and off; like a machine, controlling the inputs will control the outputs. But if change permeates, if organisations and their environments are continually flexing, then metaphors naturally become more organic: the pace of change ebbs and flows; organisations adapt as a function of their place in a wider ecosystem; change is just part of what happens, not some special extra thing.
From that perspective, it’s a small step to recognising that there is real power in thinking about organisational change in terms of systems. But it’s a small step with big consequences, and those consequences are what this post is all about.
The world of system change provides a different framing of organisational change and a way of seeing it as part of an organic process and not something that is bolted onto an organisation. The simple but powerful shift from process to purpose is something that can make a profound difference to how you go about engaging the networks that already exist within your organisation. Once we acknowledge and bring to fore the networks that make up our organisations and the system they create can we ever really deny that all change is system change?
The purpose of organisations
This is a short, perhaps even slightly cryptic, note on the purpose of organisations. Having had the unfair advantage of being part of the conversation which prompted it, my sense is that it captures two related, but distinct, issues.
The first is that not everything has a purpose at all, in any terribly useful or meaningful sense. We can observe and describe what elements of a system do, but that does not mean that each such element has a purpose, still less that any purpose it might have relates to the behaviour of the wider system of which it is part. Not being careful here can lead to spectacular errors of reverse causation – the purpose of noses is not, as Pangloss argued, to support the wearing of spectacles.
The second is that it is easy to look at human-made systems and assume that they have a purpose, and that that purpose can be both discerned and – should we wish it – amended. That’s an understandable hope, but not necessarily a realistic one. Organisations of any size are both complex systems in their own right and components of larger and yet more complex systems. What they do and how they do it cannot be reduced to a single simple proposition. That’s not, I take it, a nihilistic argument against trying to understand or influence; it is a recognition that we need to recognise and respect complexity, not wish it away.
Better Rules: a policy advisor’s perspective
Abbe Marks – NZ Digital government
The idea that it should be possible to capture legislative rules as code and that good things might result from doing so is not a new one. It sounds as though it should be simple: the re-expression of what has already been captured in one structured language in another. It turns out though not to be at all simple, partly because of what John Sheridan calls the intertwingling of law: the idea that law often takes effect through reference and amendment and that the precise effect of its doing so can be hard to discern.
There is interesting work going on in New Zealand experimenting with the idea of law and code in some limited domains, and this post is prompted by that work. What makes it distinctive is that it is written from a policy perspective, asking questions such as whether the discipline of producing machine consumable rules is a route to better policy development. It’s still unclear how far this approach might take us – but the developments in New Zealand are definitely worth keeping an eye on.
Technical Intuition
One of the unavoidable problems in curating a site like Strategic Reading is that lots of the posts and articles end up slightly blurring into one another. That’s a good thing in many ways: ideas build on each other, views of the world coalesce, but it can sometimes feel as though there isn’t much really new thinking.
This post is different. It is deliberately disruptive and challenging and provides some useful insights into a problem which has existed for a long time, but has been largely overlooked. What counts as the right kind of knowledge to understand and use technology effectively? It isn’t in itself technical knowledge – telling everybody to learn to code is no more effective than addressing transport management problems through the medium of car maintenance classes. And it isn’t stepping away, leaving such issues to the priesthood of the initiated. The limitations of that model are increasingly obvious in a world where big companies refuse to acknowledge or understand the sociology of technology.
The answer suggested here is something called ‘technical intuition’ (which is a slightly odd label, since it’s about being knowledgeable rather than intuitive), which allows people who are not technically expert to imagine, to inquire, to decide and to demand. That’s then brought to life in an example about an individual deciding whether to sign up for a supermarket loyalty card. That’s fair enough in its own terms. Personal understanding of the implications of technology related decisions is really important (and closely related to what Rachel Coldicutt calls digital understanding).
But that leaves us with two essential questions, which are left implied but not addressed. The first is where this intuition is to come from. If it is a body of knowledge, how is it to be assembled, conveyed and absorbed – all of which are preconditions to its being acted on. The second is how it then scales and aggregates – both in terms of where the social (as opposed to individual) acceptability of loyalty cards comes from, and, very differently, how that leads to confidence in other kinds of decision making. What is the technical intuition we should expect supermarket executives to display in designing loyalty cards in the first place? And in some ways, that is the most important question of all.
Mithering about the unmodellable
It is not every post you will read which links the choice of web domain name to the results of the civil war, but it is characteristic of this one that that’s exactly what it does. If you are interested in the arcane minutiae of parliamentary structure, this post is for you. But behind the specific points, there is something much more generally significant which should interest everybody, including those who, inexplicably, are not fascinated by parliamentary minutiae.
Computers crystallise systems. That’s fine for as long as the crystallised form remains valuable – and sometimes that can be quite a long time. But it’s not at all fine for systems which need to retain flexibility and adapt to changing circumstances – and that’s quite a lot of systems.
The lack of a fixed, exhaustive ruleset means Parliament is open to exaptation and adaptation. It is evolutionary by design. It is not brittle. It can sway in winds. Computers on the other hand are really not like this. They tend to prefer defined rulesets. They are deterministic. They are dumb. They are brittle.
So the question becomes whether we can get brittle computers to support systems which are not brittle. And that’s a question which matters much more widely than just for parliament.
Digital Government and Public Service Transformation
This simple and powerful set of slides does an extraordinarily good job of summarising the key issues in digital transformation, not least in being really clear about the extent to which all of this is a technology issue (not as much as it looks) as opposed to an everything else issue (much more than it first appears). The section on ‘deciding how you want to work’ gets twice as many slides as ‘thinking about your technology needs’, which is a pretty strong indicator of the approach being taken.
It’s certainly possible to challenge some of the details. The arresting assertion that ‘we can broadly take for granted that technology can do whatever we want it to do’ perhaps has more power than precision – though the slightly lesser claim the technology needed to support government processes already exists is indeed a useful reminder that appeals for technological exceptionalism are very likely to be misguided. The insistence that agile projects can’t succeed in organisations which retain traditional approaches to funding and governance is both wrong and unhelpful: wrong because there are plenty of example of where it has succeeded, and unhelpful because every organisation has to start somewhere, and if agile can’t work at all unless everything is agile, there is effectively no way of making that start.
Overall, though, the strengths far outweigh the weaknesses – and this is a beautiful example of doing the hard work to make things simple. As a further bonus, the slides are open for comments, and have already sprouted a rich set of observations from Matthew Cain.
Contradictions of government and its impossible standards
Martin Stewart-Weeks – The Mandarin
If it is hard to think and act systemically about the long term, it’s also worth reflecting on patterns of behaviour which get in the way even of the attempt. The rhetoric of innovation, of openness, of fearless honesty runs into a reality which seems designed to punish and constrain precisely those behaviours. And of course ‘design’ is precisely the wrong word here: these characteristics are emergent rather than intended (which does not, of course, mean that it would be impossible to design them to be different). There are many reasons why that is an unfortunate state of affairs, one which is rightly given some emphasis is that it risks crowding out the strategic and the systemic:
The real dilemma is that we’re so busy honing the efficiency of the pieces that we’ve failed to work out how to put the puzzle together or work out what the puzzle is or should be.
Exploring change and how to scale it
This is a characteristically excellent post, examining in some detail both what it takes for change to succeed and, perhaps even more importantly, how to scale it.
The short answer is that if you want to change the system, you have to change the system. And to do that on the fifty plus year scale which is the level of ambition behind this post, requires rigour and discipline. Five questions are set out, including the two which are the most critical: what future do you want? And what are you going to do today?
Scaling from an idea of the future to systematic government and national level change can’t be done by exhortation – and simple observation suggests can only with the greatest difficulty be done at all. The recommendations here are an intriguing mixture of the very slow burn (supporting long term varied career development, to reduce aversion to new thinking) to the much more immediate (mandating the use of user research in funding bids).
All that still leaves the question of how best to start this whole process, but this is a manifesto of what should be done, or rather how it should be done; it doesn’t purport to be a set of instructions for making it happen.
Can government stop losing its mind?
Gavin Starks – NESTA
This is an interesting report which asks almost the right question. Government is at little risk of losing its mind, or its short term memory. The two better questions – which in practice are the ones this report starts to address – are whether government can stop losing its longer term memory, and how the power of the government’s mind can be enhanced by better ways of connecting and amplifying its component parts.
Those are important questions. It’s already all too easy to forget how long we have been worrying about the ease of forgetting things. Aspects of the problem have been recognised, and solutions attempted, since the earliest days of what we no longer call electronic government. None has been more than partially successful.
The two questions are also closely related. People are reluctant to incur even the smallest overhead in storing things for the benefit of posterity, so the benefit needs to come from improving the effectiveness of current work. Conversely, tools which facilitate collaboration, sharing and serendipity will often (though with some very important exceptions) also be tools which facilitate the storage and discovery of what has been created. That was one of the key themes of a series of blog posts I wrote a couple of years ago, which covered some (though by no means all) of the same ground – including the observation, echoed in this report, that the web was invented to be an intranet and knowledge management tool; the world wide bit came rather later.
Where this report adds to the debate is in its more explicit recognition not just that we need to be thinking about texts rather than documents, but that a lot of what we need to be thinking about isn’t conventional text in the first place, making the paginated document an even less useful starting point for thinking about all this.
And there is a delicious irony that this blog – and my blogging generally – exists in large part to serve as my outboard memory, now with well over a decade of material created in part as protection against the weaknesses of institutional knowledge preservation.
Deeply intertwingled laws
Beyond even the bonus points for talking about laws being ‘intertwingled’, this is an important and interesting post at the intersection of law, policy and automation. It neatly illustrates why the goal of machine-interpretable legislation,such as the recent work by the New Zealand government, is a much harder challenge than it first appears – law can have tacit external interpretation rules, which means that the highly structured interpretation which is normal, and indeed necessary, for software just doesn’t work. Which is why legal systems have judges and programming languages generally don’t – and why the New Zealand project is so interesting.