I'm looking to give our company an overview of the business services that IT offers and their various dependencies.
The purpose of this graph would be to show the dependencies of technology on business applications with the goal of assisting configuration management. For example, if the server hosting 3 of our VMs goes down, which business applications are impacted while we work on a fix? Or, if a change is being made to a network subnet or a reboot of a router is required, who do we need to notify?
These technologies would be shown from top down (roughly from "front end" to "back end") along the lines of the following layers:
Front end:
- Business services (Business e-mail, business calendar, business documents, help desk, software development, etc.)
- External Applications (cloud apps, non-internal apps -- apps we don't manage)
- Internal Applications (internal software packages, intranet apps, etc.)
- Virtual Machines
- Machines (Servers, Desktops, laptops, phones, VM Hosts)
- Network layers / technology (DMZ, IDS, various subnets & VLANs)
- Network equipment (routers, switches, hubs)
I'm open to any thoughts, recommendations, etc. on how various folks have visualized this. Thanks in advance for any help you can give!
A whiteboard to start (get the business and technology folks in a meeting. Draw the business stuff first, then have the techs fill in the systems that support it, plus any systems not directly connected).
Armed with the whiteboard diagram (take a photo!) you can draw this up in Visio/Graffle/Tool-Of-Choice.
There are several ways to break it up (all-on-one-page, by network/subnet, by hosting machine, by business group, etc.) -- You may need one (or more) of these breakdowns to provide information to all the groups that need it, but from an IT standpoint you want at least the machine-level and network-level information displayed somehow to satisfy the notification scenarios you described above.
Two notes:
This assumes your IT staff knows the network, systems and purposes fairly well.
If they don't expect this to take MANY meetings, and expect the substantial time investment to be worth it when some business-critical system blows up and the IT guys know exactly where to look to fix the problem.
The end result of all the drawing will probably give you a good idea of how to monitor your systems from a business standpoint, and may suggest logical ways to reorganize (or create, if you don't have) the monitoring systems you use.
Take advantage of this now, while you have resources paying attention to it. Again, it will serve you well in the long run when stuff breaks and you know about it before any of your business users can even pick up the phone to complain.
This is one of the goals of a CMDB, showing the dependencies between CIs (configuration items.) Any enterprise change-management package should have a CMDB. A related issue is, who's going to keep it up to date? When someone adds a new Apache server to a farm, will it get added with the proper relationships into the CMDB? Things like that are tough to automate, although there are companies that sell expensive stuff to try to do that.
/edit - CFEngine has a commercial product called Knowledge Map that has a different approach. http://cfengine.com/files/knowledge.pdf . It looks like their free product uses it, the commercial product lets you do more with it. I have no idea about their costs, but I'm sure it's less than the big CMDB boys like HP ServiceManager. I think you'd have to be using CFengine for config managament for this to be worth much. Alternatively, if you're not scared of doing a little bit of coding, you could knock up an inventory list with a dependency mapping and then make a graph from that.
However IME, whatever approach you take, trying to do this only with a static graphical tool will be doomed to irrelevance after a few months. You start adding servers and don't bother to update the Visio because it's a PITA. ON the other hand, if you make "update the documentation" either :
As easy as "add the server and it's dependency numbers to this text file" so the sysadmins are more likely to do it ...and/or....
Make it someone else's job (would require strong change-control processes)
.. then you might have more luck.