How to create a "dependency graph" for IT assets
One of my customers is trying to create an interactive "matrix" of interdependencies for the various applications used in their company (it's a travel&leisure company with around 2500 employees).
The idea (still at the prototype stage) is to create a sort of Map, based on Visio or similar tool, which traces the communication and interdependencies between all the IT assets in the company, so that when someone asks for a change they can get an overview of the impacts.
This was mentioned in a casual setting and it will not be my responsability to directly work on this, but I did contribute the little I know already in terms of vaguely related methodologies (Zachman Framework).
I'd like to hear from the people in here if they know of methodologies, or tools, that may help this kind of effort, and if they have any specific experience to contribute. I'll digest the answers and send the result back to my customer, hoping this may be of some help with their task (which I consider a bit visionary and prone to all the pitfalls of any documentation project, but still well worth pursuing).
N.B.: The question is not "I have all this data I collected about the IT assets and I am unable to afford Visio or Google for Graphviz or convert it to a MindMapping tool or create a custom navigator using Jgraph etc.etc.". The problem is "how do I collect the relevant/useful information, and how should I organize these, considering I may have to update the data regularly, due to interface, version, and package changes?"
This is not much of a Visualization problem, or not yet. We have to get to a good start with data collection and organization first. If you want to suggest a tool, it must also include the data collection and management part (e.g.: Rational System Architect). But in that case, please suggest it if you have some actual experience, or if you are pretty sure it's quite niche and not very well know (I can Google, thank you). If you want to suggest some books/methodologies this is helpful too (I know only of the Zachman Framework, and not sure it's really a good fit).
"Just create an Excel file" or "You could use SmartDraw, man!!!" don't help much, I am afraid.
Found Iteraplan which looks a very good fit!
Answer
Correct me if I'm wrong... You're looking to use a diagram as a tool to trace the dependencies of a system.
If that's the case the what you'd use to graphically map the layout would probably be a Deployment Diagram in UML.
You map out the systems/servers/physical assets as box objects, then inside of those you map out the various applications, databases, components, and their inter-relationships with one-another.
The problem with using UML is, programmers focus mainly on class diagrams (because of their direct relationship to data modelling within the software), so it's difficult to find 'good' resources and examples on the non-class UML diagrams.
I have used this once in the past to map a relatively complex cross-system cross-application implementation and get my ideas down in a manner that could be shared with other developers while designing the system. In short, it was simple and it did its job well.
To create the diagram I used dia. If I had to do it all over again I would definitely use Visio because it's a lot easier to find pre-made stencil/template packages to diagram with online, and if those don't have what you need it's very easy to roll your own stencils in Visio.
Note: I have a lot (hundreds of hours) of experience in Visio doing electrical designs so I would consider myself familiar enough with the tools to give an objective comparison.
The downside to adapting a well-specified format is:
- they're usually overly-complex
- they usually have a strict format or set of rules
- it's easy to find yourself trying to mould the system to the diagram, it should be the other way around
- diagrams can easily grow to be too complex to comprehend/understand by anyone other than the person who created them
My suggestions are:
- make the diagrams as simple as possible
- don't be afraid to break the rules
- make the diagrams as simple as possible
- do everything in your ability to keep the diagrams as straight-forward and simple as possible
- ... you get the point.
If a developer who has never seen the diagram can't start to decipher the layout and meanings within the first few minutes of looking at it, it will probably do more harm than good.
I would consider the Zachman Framework to be an bad option because:
- it's difficult to understand the 'point' the diagrams are trying to get across
- the diagram formats are too complex
- the rules are in an inflexible format that limit, not complement the system's design
While you're researching options ask yourself this. Do you understand the point of the diagram?
The problem with diagramming a design is, if done wrong it will create more headaches then its worth and nobody will use it. No design document is usually better than a bad design document.
I hope that helps.