GovOps: DevOps and Governance
This article was machine-translated from Japanese by AI (Claude). It may contain errors. Read the original Japanese article.
I think that, for the future of public governance and for governance in some domains, something that could be called GovOps, a counterpart to DevOps, is conceivable.
With the establishment of the Digital Agency, the DX of government bodies, the DX of companies, and so on, digital technology is finally about to be built into society in earnest. There are many different arguments: some stop at DX as the mere introduction of software, while others point to improvements in services and UX through DX, or to changes across entire industries brought about by DX.
Personally, though, I believe the real heart of DX is a shift in "mechanisms," and more specifically that "complementary innovations" (Brynjolfsson et al.), such as institutions and systems, are important. For that, please refer to my recent book, "Implementing the Future"; this time, I will talk about why GovOps.
Governance as Code
Today, digital technology is not only making Ops (Operations) more efficient; it is also beginning to change the Dev (Development) of laws and rules itself.
As pointed out in governance innovation and agile governance, digital technology can not only make the operation of rules more efficient but also change how rules are made.
For example, if the state were to manage a drone platform, it would become possible to change the areas where drones may fly in real time. As a result, it might no longer be necessary to lay down restricted zones and the like in minute detail in the law. Also, if inspections of factories, elevators, and so on, which have until now been carried out by people, could be replaced with real-time monitoring using sensors, the interval between periodic inspections by people could possibly be lengthened somewhat. Inspections that used to be every year might become something like once every three years. A recent example is eKYC, where digital technology has made identity verification possible in a way that differs from before. These are all examples in which digital technology changed how things are operated, and as a result, how rules are made also changed.
Operations are made more efficient through code, and the way things are built in the first place changes. This resembles the Infrastructure as Code / Operations as Code movement that happened in the IT world about ten years ago. The idea is that when infrastructure and operations are defined and run through code, infrastructure becomes programmable, and that in turn changes the way Dev is done.
If we apply this to the context of governance, can we not think that Governance as Code, or Governance by Code, is starting to happen?
GovOps
In the IT world, in parallel with and mutually influencing the Infrastructure as Code / Operations as Code movement, there was the reintegration of Dev and Ops. This is DevOps. Thinking of this in the context of governance, there may be such a thing as GovOps.
If the "law" is a kind of product of bureaucrats, then deploying it quickly while operating it stably is similar to the aims of DevOps.
In fact, the "regulatory sandbox," which is taken up in agile governance and elsewhere, can be seen as the phased rollout of DevOps. If we assume that the mechanisms for ensuring agility will probably turn out to be similar, then the DevOps approach may serve as one reference for thinking about the future of public governance and corporate governance.
That said, imitating DevOps by "deploying laws and ordinances ten times a day" would cause far too much confusion in society, and unlike IT systems, laws are generally hard to "roll back," so I think it is better to avoid copying it as is. However, if digital technology can be used to optimize the workflow from enactment of a bill through operation to service delivery, and thereby increase the number of bills that can be proposed in a year (and if the Diet can deliberate on them with high transparency and efficiency), governance with high agility in the face of social change may become possible.
At the same time, the positioning of each measure related to the DX of bureaucratic work becomes easier to understand, such as "introducing AI to check existing bills in order to raise the number of law deployments."
GRE
By the same token, drawing on SRE (site reliability engineer) thinking, an analogue such as GRE (governance reliability engineer) can also be imagined.
What can be used from SRE thinking is probably the error budget and toil. The error budget is a mechanism in which the acceptable range of errors is decided in advance, so that one can take risks within it and carefully try new things. Toil refers to manual work that occurs frequently and could be automated.
In SRE, the error budget is usually based on uptime. For government bodies, appropriate KPIs would have to be decided, and of course there are areas where errors cannot be tolerated, so it cannot be applied to everything. Still, as a way of thinking for creating room for new challenges, it could be applied in some places.
Setting an annual target for toil reduction may also be one approach. Toil is, so to speak, "hardship that humans do not need to go through." Administrative work seems to contain a lot of toil, so reducing it would let people spend their time on what is truly essential, such as services for residents and hearings. I imagine such efficiency improvements were already being pursued, but giving it the name toil might make it a little easier to do.
Toward GovOps
Thinking about GovOps in this way, I feel that the ideas cultivated so far in the DevOps community may be usable, to a certain extent, in governance as well.
For example, it is often repeated that DevOps is culture, practice, and tools, and the digitalization of governance should likewise not stop at being merely a matter of tools.
Also, when improving GovOps, we can think about it based on the following "Three Ways," as in DevOps.
- The Principle of Flow: make the workflow fast
- The Principle of Feedback: realize feedback flows
- The Principle of Continual Learning and Experimentation: create a corporate culture
Applying this to existing governance (public governance, for now), it would mean organizing workflows through value stream mapping and the like, and using digital technology to speed up the workflows of existing operations; realizing feedback flows by using sensors, Decidim, and so on; and carrying out continual learning and experimentation, among other things.
Summary
There are still parts I am not confident about myself, wondering "is this right?", but since the agile governance report had come out, and agile makes one think of DevOps, I wrote this along those lines. In fact, the agile governance report contains the following figure, which I think resembles the DevOps (GovOps) figure at the beginning.
I actually included GovOps in the slides I wrote some time ago, xOps, too.
I know a rough analogy will rarely work out that well, but even so, I think the DevOps way of thinking is a concept that can serve as a reference in future discussions of digital government and in the DX of individual companies.
xOps: The Day Engineers Become the Driving Force of Startup Growth from Takaaki Umada