Why your network diagrams suck (and they do, which is sad because it’s a fundamental IT need):
1. You don’t have any.
2. You pooped them out last week.
3. You tried to put everything on one drawing (VLANs, servers, network gear, port-specific connections, IP addresses, serials, virtualization…).
4. You didn’t include enough info to answer questions the diagrams are meant to answer.
5. You have too many diagrams and they conflict. (Also see next.)
6. You don’t update them as you make changes (if you update them at all).
7. You auto-generate them from some network scan tool or inventory tool, and they just look like ass no matter what you do (or don’t say enough to be meaningful).
8. They all look and feel completely different because 4 different people maintain their own diagrams for what they control.
9. You don’t make diagrams from the viewpoint of the intended audience. What works for you won’t work for your contractors, auditors, developers, security/comliance, customers.
One thought on “network diagrams: an underappreciated art”
I’d like to see more flat networks that do not require documentation. Ones without firewalls or VPN connectivity.
Stuff in the current DMZ should just go into a public cloud solution and speak SSL only. Azure, Force, and Amazon are cool.
Backoffice stuff should be replaced by Google Apps or similar. Oracle does a lot of SaaS now, too.
Anything sensitive (like databases, source code repos, and desktop apps) should go into a private cloud. I prefer BitLockered HVS with SCVMM. The network can still be totally flat, although some infostructures might utilize vNetworking. I am not partial to any particular VDI solution, but I do prefer that it integrate with HVS and SCVMM well.
I believe that IT Infrastructure is breaking up into two parts: metastructure (BGP, OSPF/ISIS/EIGRP/static-routes, DNS, AD, SSL) and infostructure.
The only people who care about metastructure should work for somebody like Sprint or Savvis.
Everyone else in IT (i.e. the rest of us) should care about infostructure only. We need documentation on infostructure, not metastructure. All of that network stuff can be outsourced. Sure, there will still be campus networks to connect thin clients to the private cloud but those can also be outsourced (and should be).
There is no reason why any outsourced provider cannot build a network that never goes down, so local storage and local compute is completely unnecessary. This will also keep local network down to a minimum.
It is especially true that security people should not care about the network at all. We need to be doing other, more important things that focus all of our attention on the infostructure. Instead of working with network engineers — we should be working with business analysts, developers, developer-testers, data quality analysts, and business intelligence analysts.
Our diagrams should be UML 2.0 class and sequence diagrams. No more layered architecture diagrams. High level diagrams might not have to be UML 2.0, but they should look like domain models that reflect software patterns (or Enterprise Application Integration, Web 2.0, or SOA patterns). The only “connections” in these domain models would be to data tiers, integration tiers, and presentation/client tiers but the focus would not be on the layers but instead the data and execution flows of those components.
Comments are closed.