(To be published in Architecture and Governance - reprinted by permission)
The foundation of IT governance is the simple dependency: application depends on database, database depends on server, server depends on switch, application depends on application, and so forth. IT organizations deal with this critical data on a daily basis and treat it shamefully: essentially as a disposable commodity. Dependency information is expensive. It is typically gathered by assembling two or more highly compensated individuals to (again and again) go over what is installed where, what it talks to, and what it needs to run. Dependencies are captured in transient Visio diagrams, Excel spreadsheets, and Powerpoint graphics, rarely if ever updated in synch with any enterprise process, nor made available for the variety of purposes that need them.
Consider the producers and consumers of dependencies in your IT organization:
- Enterprise architecture/portfolio management
- Software development (especially when enhancing existing systems)
- Information management, business intelligence and data warehousing
- Service support (production turnover, change management, business service mapping, impact analysis, break/fix support)
- Capacity planning
- Compliance initiatives
- Continuity planning
- Security management
and more. I have seen all of these areas diligently re-drawing and re-capturing various views on much the same core essential data set, with complete disregard for the work of others, and I have seen (especially) application support teams suffer for it, as they tend to be the ones continually called in for interview after interview. What servers is your application on? What databases does it use? What programming language was it written in? Does it handle sensitive customer data? What interfaces does it have with other applications? Data feeds? Direct network dependencies (e.g. load balancers, firewall punchthroughs)? Again and again.
Let's do a small thought experiment. Assume you have a portfolio of 300 applications (a medium sized shop in this day and age!) Let's say that your unmanaged dependency data requires 40 staff hours (on average) per application in re-discovery each year (this is probably conservative).That's the equivalent of 6 full time staff, fully burdened at $125,000 a head, that's $750,000 each year, going down the drain of poor dependency management.
This does not include the costs of outages due to incidents caused by changes where the IT dependencies were not understood, or prolonged because the system wasn't understood well enough to quickly restore service. I have seen an expensive customer-facing system outage prolonged for eight preventable, painful hours simply because a key individual and his dependency knowledge couldn't be reached.
Dependencies are the most precious information an IT shop deals in, and yet we treat them like junk, or worse, people's private kingdoms. Some individuals see their expertise in a given system's dependencies as job security. Contractors love to get ahold of them, and in my experience are loath to surrender control over key dependency information once they have it.
Note that I'm skeptical towards the tools that claim to provide automatic mapping of dependencies; they have challenges in the higher, more subjective levels of the IT world with concepts like application, process, and IT service and their tricky interrelationships. These higher level dependencies will require primarily manual documentation for the forseeable future I believe.
Automated or manual, without a central repository and maintenance process your captured dependencies are going up in smoke every week. So, the next time you encounter yet another project gearing up a bunch of contractors to go out and survey your IT environment into throwaway spreadsheets for some compliance initiative, ask yourself, "Isn't there a better way?"
