IT Infrastructure Modeling - The When and Where of Diagrams

Models and diagrams are key components of software systems. They're used both to design and to documents. Therefor, it's not surprising that so many software diagrams are out there - from use case diagrams through entity relation diagrams and class diagrams to sequence diagrams and state diagrams, they're everywhere, and they're there to dominate.

Well, they're almost everywhere. When we come to IT infrastructure, it seems that diagrams become a bit scarce. True enough, we're practically swimming in network topology diagrams, and there are many physical layout diagrams, both of racks and of whole data centers, but when you come to think about it, there is so much more; where are all the diagrams about the databases infrastructure? I'm not talking about ERD, which is far more useful for a programmer than for a DBA, I'm talking about a diagram to show the different NICs and addresses associated with the DB, which servers form a grid, where are the different services and instances able to run. Don't we need a diagram to know what Kerberos domains do we have, which trusts are there, who're the KDCs, who're the TGSs, which servers hold which tickets? Wouldn't the storage manager like to know where does his LUNs go to, and how does they get there, and how should they be backed-up? I can go on and on about things that should be designed and documented, but I'm quite sure that by now you have more ideas than I do.

So why don't we see more of these diagrams, and when we do, why doesn't there seems to be a formal notation to them? As my work involves writing both HLDs and LLDs, I've given this question some thought, and I'd like to share my angle. In my humble opinion, such diagrams, and more so such notations, doesn't exists, because in most cases they're not required.

Which brings us to the more interesting question of how do I know if I'm special, and I do need infra diagrams. To answer this question, I'd like to think about what diagrams are good for. Had I asked that in some circles, especially those of engineers from every kind, I'd probably get stoned, but I've asked it anyhow, and I came up with an answer I'm quite satisfied with, and forgive my quote marking a definition I gave

"Diagrams are tools for sharing complex ideas"

Therefor, when you sit down to diagram something, you should ask yourself

• Is it complex?

  If you only have one IDM system in your organization, than you don't need a diagram to tell you who manage the identities for a specific node in your network. If you have several, and there are trust relation between them, and maybe some of the trusts are only one way, and perhaps there's no immediate way to guess for a node who's his authentication authority.. well then, you might want a picture to clear up the mess

• Whom do you share with?

  If you need to share an idea with a team leader sitting in the next office, you probably better talk it over a cup of coffee. If you need to share an idea only with your future self (this ugly thing called documenting), do whatever it is that you'll understand later - draw a scribble, scramble some words, send yourself an email, go nuts. On the other hand, if you need a collaboration of several individuals or teams, formal diagrams are proven to reduce misunderstandings and misinterpretations. Of course, there is gap in the middle, this beautiful thing called informal diagrams. In my experience, those are mostly useful for ideas or information that you want to share only within your team, and the subject was not formally notated. In this case, don't bother with creating a new format, just do whatever it is that you'll all understand

• Is it an idea?

  This is an easy one to fall with. Don't get hysteric to draw just about anything. Take a look from above, don't get into every detail, don't overwhelm your reader, think about your complex idea and share it - and only it. A tip I find useful in this area is using clouds. If I want to know how my system connects to another one, the other system should be a cloud, which is intuitive, but my nodes shouldn't be in this diagrams either - they should be clouded, too. It's easy to say "I'll just put in those nodes who actually communicate with that system", but if the idea you want to share is the path, than only the path should be included.

• Diagrams are tools. Use them if, and only if, you need them. Formalize a notation if, and only, you used them often.

I've done this thinking for my field, but I'm pretty sure the same applies for any use in diagrams. I'll be more that happy to discuss the subject. You know how to get me.