> To a first, and second, and third approximation, bureaucracies are distributed computing systems; procedures, laws and bylaws are code, bureaucrats are the computing units.
Having spent a fair amount of time working in various bureaucracies, and studying law and government administration, that's very much not true. It's very much the idealized view that many people outside of bureaucracies have of them, especially people in computing, but it's very much not a good approximation of most real bureaucracies, or their governing law and regulation, because the latter usually is written in a way which deliberately relies heavily on discretion within (often deliberately fuzzy) constraints rather than seeking to provide deterministic rules for outcomes, and in many systems regulation is actually written by the bureaucrats enforcing it (who also tend to have disproportionate influence on shaping the actual law).
You'll see down in the subthread that I essentially agree with what you wrote here. However, I still maintain the analogy to a distributed computing system is good and revealing. It's particularly the observation of the flow of forms and documents in and out of bureaucracy, as well as within it, that makes me think of it.
As explained below, I don't agree that it's a good idea to replace bureaucracy with code. However, I think the lessons our industry has learned in architecting software systems could inform designing efficient data and request flow within a bureaucracy. At the very least, it gives us language to talk about bureaucracies as systems.
> However, I think the lessons our industry has learned in architecting software systems could inform designing efficient data and request flow within a bureaucracy.
This I definitely agree with; it's kind of disappointing the information systems engineering knowledge has tended to become siloed within organizations dedicated to information technology, because you get much bigger gains if you apply that knowledge to broader processes, not just within computing systems supporting the processes. OTOH, with people who have that knowledge generally getting paid more to apply it in IT (and getting listened to more there), it's kind of understandable if unfortunate that the knowledge gets stuck in IT.
Having spent a fair amount of time working in various bureaucracies, and studying law and government administration, that's very much not true. It's very much the idealized view that many people outside of bureaucracies have of them, especially people in computing, but it's very much not a good approximation of most real bureaucracies, or their governing law and regulation, because the latter usually is written in a way which deliberately relies heavily on discretion within (often deliberately fuzzy) constraints rather than seeking to provide deterministic rules for outcomes, and in many systems regulation is actually written by the bureaucrats enforcing it (who also tend to have disproportionate influence on shaping the actual law).