Cheesegraters

In 1791, George Washington tasked Major Pierre Charles L’Enfant to collaborate with Thomas Jefferson and three commissioners on a plan for the seat of the new government.

^{An early design for Washington, D.C., from Wikipedia. Library of Congress Geography and Map Division, Washington, DC: https://www.loc.gov/item/87694269/}

 

The result was a city with a clear grid, structured around the major buildings needed to run a nation. Lettered streets ran East-West, and numbered streets ran North-South.

Contrast this with the city of London, which grew from several small cities as a series of concentric rings from the seat of power. The winding roadways, sinewy flyovers, and narrow alleys testify to a city that was not designed, but rather, emerged from footpaths and battlements and canals. Its structure reflects its history.

^{Wikipedia’s map of greater London by User:MRSC - self-made (Transferred from en.wikipedia to Commons by Koryakov Yuri.), CC BY-SA 3.0}

 

Much like London, governments that follow the Westminster Model did not emerge, whole and complete, as they are today. The Ministry of Finance was once the King’s Master Treasurer; the Department of Defense was the Captain of the Guard. As we moved away from dictators and monarchs, we added social programs such as welfare, and taxation to pay for it all, giving birth to Economic and Social Development and the Department of Inland Revenue.

If you wonder why the group that is in charge of accountability, IT systems, and administrative management in Canada is called the Treasury Board Secretariat or why the Privvy Council has its name (it was originally a committee of the monarch’s closest advisors), well, it’s because of history.

 

A government of silos

In the Westminster model from which many democracies’ structure is descended, each department in the  was at one time its own entity, fully independent and self-contained. Each had its own budget, and sometimes its own security service. Very few of the services on which it operated were shared with others.

^{An overly simple model of early government departments as entirely self-contained, separate silos.}

 

In a physical world, this worked fairly well, because of how resources are shared. Imagine, for example, two departments: Health and Taxation. Each has someone who handles support calls, and can tackle a hundred calls a day. The Health support person is well versed in health, having tremendous domain expertise, but knows nothing about taxes. And vice-versa.

Now imagine that it’s tax time, and the Tax support person is overwhelmed. The Health support person can’t help out, even if they have free cycles, because they don’t know much about taxes. Similarly, if there’s a pandemic, the Tax support person can’t help the Health support person, because they’re not a health expert. The silos can’t help one another.

This was tolerated, because the benefits of domain knowledge outweighed the inefficiency of not being able to move resources around. It was more expensive to retrain a tax person in health than it was to just hire excess capacity. What’s more, the leaders of each department didn’t really want to share supporters, because their staff and their budgets were their power.

 

Economics demands that the silos co-operate

Governments have always relied on the private sector for some of what they do, whether hiring mercenaries in the middle ages, buying electrical power, or hiring private contractors. Utilities like power or telecommunication are able to provide elastic services by selling a commodity service to a large market, which means their costs are lower.

^{Siloed departments still buy generic things from the private sector because the economies of scale are much better than doing it themselves.}

 

As governments became more formalized and institutionalized, the value of outsourcing became more clear. Governments used private companies for things that weren’t core to their missions, or that could be done more efficiently in a competitive market.

There are three fundamental concepts I want to clarify, because they’ll be important for the rest of this discussion:

• Elasticity. For some resources, you pay only for what you use. If you use twice as much, your final bill is double. You can increase or decrease your electricity usage, for example, because it is a pay-as-you-go utility. When we can increase and decrease the amount of something easily (like electricity) it is highly elastic.
  On the other hand, you can’t increase or decrease your fridge. If you run out of space in your fridge, you need to buy a new one, even if it’s just to store a single item. Your fridge is inelastic. If you double your electricity use, the cost per kilowatt-hour doesn’t change; but if you add just one box of milk to a full fridge, your cost to store that milk goes up by one fridge. Economists would say that a resource is elastic when a change in what you consume doesn’t change the unit cost of that thing.
• Economies of scale. For many things, the more we make, the less each additional item costs. Imagine you want to build a car. The materials to build a car are $10,000. But the cost of building a car factory is $10,000,000.

• • The cost of a single car is (1 * $10,000) + $10,000,000, or $10,010,000. For a single car. A pretty expensive car.
  • Now imagine you build a thousand cars instead. That’s (1000 * $10,000) + $10,000,000, or $20,000,000. For 1,000 cars. Or $20,000 per car, which is much more reasonable.

^{Unit cost decreases from $10,010,000 per car for one car to $20,000 per car for 1,000 cars because of the economies of scale from re-using a factory to build cars.}

 

The cost of that thousandth car is $20,000. We call this the marginal cost (the cost to make one more.) The cost per car went down because the cost of the factory doesn’t change when we make more cars. It is a fixed cost. We can spread this fixed cost across the number of cars we make, so the more cars we make, the more the cost drops. Economists would say that economies of scale happen when the marginal cost decreases as a result of sharing fixed costs among many units.

• Domain expertise. Some functions can’t easily be repurposed. An expert in public health has knowledge that isn’t applicable to, say, fisheries. This knowledge is tied to a particular department, and can’t easily move. We might also call this economies of skill.

In some cases, this led to privatization of services that were previously operated by the government. Often, money flowed the other way: Private military contractors built armaments; private computer companies built mainframes to run the census; and so on. This, of course, was not without risks:

• If the private sector had unbeatable economies of scale, it could become a monopoly, charge unreasonable profits, and become a tax on society. This has happened before: In the US, AT&T was granted a monopoly to roll out telephony to the nation; later, when it grew too powerful, it was broken up by the government.
• Some private companies may also lock their customers into a particular standard or process, a problem that’s become particularly perplexing when choosing software providers.
• Some companies can corner the market on a resource, and then mark up those costs. If the only way to hire technically skilled workers is through a recruiter, then the recruiter is effectively extracting a tax on the government.

 

Digital changes the economics of service delivery

The switch from physical government, staffed by humans, to digital government, run by algorithms, is once again changing the structure of the public sector.

Returning to our example of a Health support and a Tax support person, today much of their role is completed by machines: A website, a chatbot, a database, an automated responder, a website, a form, or an app. Digital government isn’t just changing the economics of delivering services to citizens and residents—it’s changing the structure of government itself.

In a digital world, there is much more that can be shared among departments. For example, every department needs a web form by which people can contact it. That form has to comply with accessibility laws (for blind people, for example) and be available in multiple languages. But those rules are government-wide; there’s no reason for each department to do these things themselves. This is a component that can be shared.

^{Shared components that are useful to several departments, but not domain-specific, reduce digital costs through economies of scale; make new tools and bug fixes available to all those departments; and increase standardization and compliance for digitally-delivered services.}

 

There are many advantages to sharing components in this way:

• It’s easier to build a digital service from existing components than to create them from scratch.
• Each time a component is improved, everyone who builds atop it benefits.
• A component can be thoroughly tested to ensure accessibility, privacy, and compliance—and then anyone who builds atop it will also be compliant.
• It’s possible to instrument a component with analytics and collect usage data.

The entire Internet runs atop shared components. Very few software developers build things from scratch in the modern world; instead, they use pre-built functions (sometimes referred to as libraries or modules.) Government is starting to do the same, replacing redundant, department-specific systems with shared components.

The challenge, of course, isn’t the technology. It’s a willingness to change. Every department is convinced that it can’t use the shared component because it doesn’t quite do exactly what’s needed. This “Not Invented Here” attitude costs taxpayers millions, thwarts a nation’s ability to deliver good tools quickly, and leads to tremendous frustration by public sector IT teams who are stuck maintaining antiquated platforms.

 

Cheesegraters to the rescue

A cheesegrater grinds away relentlessly, peeling off layers. Government needs metaphorical cheesegraters to modernize service delivery.

In the following diagram, there are three cheesegraters:

^{Digital Services makes shared components; Shared Services operates shared infrastructure; the Private Sector delivers commodity utilities.}

 

In this diagram:

Cheesegrater	Seeks out	Example	Turns it into	Guiding principle
Digital Services	Any component that exists in multiple departments, but does the same thing for all of them, and isn’t unique to the services of that department.	A form, a notification engine, or a web framework. There’s no reason these should be different between departments, so re-using a shared component makes everything better.	A re-usable, well-documented, actively supported software component from which new services can quickly be built.	Effective re-use: Can others use this easily and well to build their services?
Shared Services (AKA Enterprise Model)	Any service that’s an undifferentiated commodity, but is still run by individual departments.	Rather than running physical machines, use a private cloud, because containers are identical and government privacy /workload governance can still be managed.	Shared infrastructure that’s government-specific, but can achieve economies of scale.	Efficient operation: Will we achieve lower management costs and better SLAs by consolidating this?
Private Sector	Undifferentiated services that can be provided more cost-effectively by the private sector.	Virtual machines in a public cloud; broadband networks; off-site backups.	The same functionality for a savings that outweighs the risks of lock-in or unreasonable profit extraction.	Economic commodity: Will our costs go down by sharing with other sectors without a risk of lock-in?

 

The cheesegrater metaphor is a useful way to think about the transformation from the vertically siloed model of physical government to the horizontally connected model of digital government.

 

Sharpness, movement and pressure

A cheesegrater is a sharp edge moving constantly across a surface with consistent, even pressure. Any successful government modernization initiative also needs these three things if it is to work:

• Sharp edge: In the right hands, tech is a powerful tool. It can automate tasks, generate analytical data, and update systems instantly when changes are needed. The technology team—often a Digital Service department—needs to be using the latest tools and approaches, and have strong digital skills, particularly around design thinking, modular code and microservices, documentation, evangelism, and agile/iterative development.
• Constant movement: The Digital and Shared Service layers must constantly hunt for the next thing that can be shaved off the bottom of the silo, and into a shared service where it can benefit all. They need to get out of the office, look through the financials, and unearth those components and services that are being jealously guarded by departmental fiefdoms.
• Consistent pressure: Digital transformation requires top-down pressure, in the form of raw political will, to literally force any undifferentiated components out of the department and into more efficient, shared platforms. Some countries have achieved this by giving veto rights to their digital teams, allowing them to force departments to co-operate. Without this pressure, a cheesegrater will not function properly—and neither will a modernization initiative.

Structure and incentives matter, too.

• Digital services teams must be incentivized to find and liberate redundant components, and departments must be incentivized to build on shared systems.
• Shared services teams must be rewarded for improving the efficiency with which shared, commodity components are adopted (i.e. lower computing costs and higher uptime.)
• The private sector should be compensated with (reasonable) profits for delivering economies of scale without locking in its customers.

Without movement, pressure, sharpness, and the right incentives, the silos will persist and government will never achieve the elasticity and economies of scale needed. Not only will costs continue to rise, but departments won’t be able to focus on the domain expertise that makes them vital to a modern society.