I’m going to attempt the impossible. I’m going to give a defense of bureaucracy.* One of the workstreams for the Migration engagement is Operations Model. An Operations Model describes an organization with formal rules and responsibilities, both for its members and for everyone who interacts with the organization. In other words, a bureaucracy. Many of the qualities of a bureaucracy are both essential and despised.
A bureaucracy should be impersonal. A personal touch would lead to decisions based on how attractive someone is, or what favors they might do in return, or on a supply of legal tender.
A bureaucracy should be faceless. Imagine if it were not. Every time you needed a service you would have to find a staff member who could fulfill your request. You would have to negotiate with them on the details of the request. If more than one person’s skills were needed, it would be your responsibility to find all the associated people needed to fulfill your request. And if your contact took a vacation, you would need to start all over again to find someone else to complete your request.
A bureaucracy should have rules, and it should follow them always. To paraphrase Albert Einstein, “Insanity is doing the same thing over and over and getting different results.” Suppose you made three requests for email accounts. The first time you are asked for the mail user’s university identity and a budget code. The second time you’re asked for the mail user’s first and last name, their university phone number, and their location, but no budget code. The third time you’re asked to create an email identity for the user and to provide the user’s supervisor’s email address, as well as a budget code. After all that, how you would long for the monotony of being asked for the same damned things every time you request a mail account for someone.
I’m not going to provide arguments against bureaucracy. There’s an internet for that. I will say we’re doing something that is difficult for a bureaucracy to do. We are creating rules to replace processes that have been established for years—in some cases, established for decades.
This is not so much a change in what we do, but how we do it. This migration is not about re-inventing Wharton Computing, or about transforming its staff.**
There are hundreds of these decisions to be made. One example. Now, we configure restrictions on network access with a firewall. In the cloud, these functions are handled by security groups. Security Groups have names. In our infrastructure we can expect to have hundreds of security groups. It behooves us, then, to have a consistent naming policy that says something about a given security group.
So, we need a naming scheme. Who decides what the scheme is? Another decision. Where do we announce it? Another decision. How do we make sure the scheme is followed? Another decision. What do we do with non-conforming names? Another decision.
What’s the payoff? Five years from now, no one will have to remember that Gandalf-003 is the security group for the cat-video-curation application server, while X43/MisTerMiTTens-v7.3\c is the most recent version of the security group protecting the human resources database servers.
* I went through the first ninety quotes in Goodreads tagged for Bureaucracy with nary a positive quote—at least in English.
** Although, it will empower you to become your own change agent, Embarking on Your Journey 2 2morrow 2day. (The 3 2s™, as I call it.)