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.
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.