I was reminded these last couple weeks of the importance of our reputation as technical experts. Since the beginning of my career there has always been the temptation to shade the truth a little. I’ve mentioned before, but the technologist has a great deal of political power in the organization because he or she is often the only one that understands the technology or the network. As network architects it behooves us to design networks that reduce this temptation to shade the truth. Integrating best practices.
Early in our careers technical experts are asked for advice. When we give that advice, the next question the receiver should and probably will ask is, “Why?” There are a lot of poor ways to answer this question. “Best Practices” is a simple way to answer this without giving a real explanation. “Security” is another generic answer that technical people use to answer a question. These seem like satisfying answers to the technician, because most non-technical people walk away without any further questions. I am a big proponent of best practices in modern network architecture but sometimes technical experts use best practices as an excuse to do what they want to do on the network.
For example: Microsoft has 1000′s of best practice recommendations for anyone building with their technology. A classic example most of us know focuses around network security groups. Users go into local groups, local groups are added to global groups and network resources are then assigned to global groups. This was the explanation for how to setup security groups. Later Universal groups were added to the mix adding a new complexity to this recommendation. Every MCSE was trained and tested to follow this best practice. Yet the reality is that most network administrators were so confused they just came up with their own system of managing security groups.
The reality is that these are best practice recommendations. The system architect was supposed to create their own technical best practices for their environments. Then share and enforce those best practices as rules for the network. I’ve left out a couple important parts though.
First the system architect is supposed to build technical best practices based on the business requirements of the management teams using the network.
Second the system architect needs to write these things down so that everyone can follow-through on them.
Many system architects break both these rules. First by using their own intuition about technical best practices. Second by keeping these best practices in their own head and expecting to maintain these rules through tribal knowledge within the organization. The result is that the system architect builds their own political importance within the organization.
When walking into a new network the first task I start with is documenting the present network. This is especially true when clarifying the details around the best practices being followed in the network architecture. This includes understanding the business requirement that supports the technical “best practice”. Unfortunately this makes a lot of people angry, especially technical people. Often the “Best Practices” are actually excuses that allow the technical experts to maintain political control. It’s an easy trap to fall into. It’s so easy to think that nobody else knows the technology well enough to catch you.
I’m curious if you’ve walked into a technical nightmare that was maintained by political rather than technical best practices?]]>