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:
Business services (Business e-mail, business calendar, business documents, help desk, software development, etc.)
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!
( 3 months ago )
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.
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