Thursday
Jun172010
Application Dependency Mapping & IT Demand / Supply Paradigm
Thursday, June 17, 2010 at 3:11AM
Over the last several years, firms have been attempting to embrace new ways of looking at the systems deployed on their IT platforms and relate those systems to the business functions that they support. That is to say, to answer the question that business leaders constantly ask; What systems in the data center are used to provide the applications that we use and how can you, IT department, reduce the cost I am paying for those systems while increasing performance and agility.
Traditional IT departments have not typically related systems in such a way. In most cases they use traditional IT asset management tools to attempt to do this, but without not much success. In cases where this relationship mapping has been attempted, it is usually done manually based on several individuals' interpretation of how the systems are related to one another. The problem with this approach is that it is typically wrong, or minimally does not include all of the relationships that truly exist between the systems.
Just the other day, I someone tell me "Oh, we have application dependency data already". Upon further review, the data really wasn't application dependency data. It was a handful of attributes about a host that captured basic information such as host name, IP address, and some of the running software packages on the host and a risk rating for the host. There was some application dependency information but it was manually collected and input into the system. It still did not tie the particular host back to a business application and ultimately represent the collection of hosts in a supply and demand paradigm that can be understood by the business.
This scenario struck a cord with me so hence the blog posting. At a macro level, this is the problem with the current implementations of asset management and application discovery and dependency mapping technologies. The deployments are based on looking at the IT platform through a specific lens at a very micro level. That is to say the requirements for the deployment are usually developed in a vacuum, without truly understanding what the needs of the business are from an IT perspective, usually by the monitoring or service management organization in a firm. They are not at enough of a macro level to be useful for discussions with business leaders.
We in IT need to rethink how we go about articulating the complex makeup of IT platforms that we support and provide to our business partners. Furthermore, we need to deploy IT management technologies in ways that drive value for the business whether that means the reduction or mitigation of risk, increasing the business's agility from a product development or service deployment perspective.
I challenge those of us in IT to think about the platforms we support as the supply side of a demand and supply paradigm. The business units we support in our firms have various demands of the IT platform (sometimes we think those demands are unrealistic, but that issue is better left for another blog post). We in IT now need to deploy systems in support of the business demand model and balance the supply of those systems and services against critical business drivers such as capital required to support the demand requirements, mitigation of risk, criticality of business agility (sometimes agility is not a major driver).
The deployment of application discovery and dependency mapping technologies enables the IT department to have meaningful conversations with business leaders on how the IT platform is setup and how the various applications are deployed to support the demand requirements of the business. A mature ADDM deployment allows IT leaders to have this conversation with factual and objective data that has been programmatically gathered. Most importantly, it logically depicts the systems based on their business functions, in a way that business leaders can understand.
If you or your firm is deploying these dependency mapping technologies, keep in mind this supply and demand paradigm. Ensure that you engage with your counterparts that support the line of business and ensure that your dependency mapping implementation will support their needs.
If your firm has this dependency mapping technology in place and there are data center relocation or optimization efforts going on, reach out to those teams as well. Datacenter relocation programs can benefit greatly from this dependency mapping technology. You will be considered a hero if you reach out to these teams and work with them to ensure your dependency mapping deployment will meet their needs and provide them extremely valuable data for planning and mitigating the risks associated with moving equipment in data centers.
Traditional IT departments have not typically related systems in such a way. In most cases they use traditional IT asset management tools to attempt to do this, but without not much success. In cases where this relationship mapping has been attempted, it is usually done manually based on several individuals' interpretation of how the systems are related to one another. The problem with this approach is that it is typically wrong, or minimally does not include all of the relationships that truly exist between the systems.
Just the other day, I someone tell me "Oh, we have application dependency data already". Upon further review, the data really wasn't application dependency data. It was a handful of attributes about a host that captured basic information such as host name, IP address, and some of the running software packages on the host and a risk rating for the host. There was some application dependency information but it was manually collected and input into the system. It still did not tie the particular host back to a business application and ultimately represent the collection of hosts in a supply and demand paradigm that can be understood by the business.
This scenario struck a cord with me so hence the blog posting. At a macro level, this is the problem with the current implementations of asset management and application discovery and dependency mapping technologies. The deployments are based on looking at the IT platform through a specific lens at a very micro level. That is to say the requirements for the deployment are usually developed in a vacuum, without truly understanding what the needs of the business are from an IT perspective, usually by the monitoring or service management organization in a firm. They are not at enough of a macro level to be useful for discussions with business leaders.
We in IT need to rethink how we go about articulating the complex makeup of IT platforms that we support and provide to our business partners. Furthermore, we need to deploy IT management technologies in ways that drive value for the business whether that means the reduction or mitigation of risk, increasing the business's agility from a product development or service deployment perspective.
I challenge those of us in IT to think about the platforms we support as the supply side of a demand and supply paradigm. The business units we support in our firms have various demands of the IT platform (sometimes we think those demands are unrealistic, but that issue is better left for another blog post). We in IT now need to deploy systems in support of the business demand model and balance the supply of those systems and services against critical business drivers such as capital required to support the demand requirements, mitigation of risk, criticality of business agility (sometimes agility is not a major driver).
The deployment of application discovery and dependency mapping technologies enables the IT department to have meaningful conversations with business leaders on how the IT platform is setup and how the various applications are deployed to support the demand requirements of the business. A mature ADDM deployment allows IT leaders to have this conversation with factual and objective data that has been programmatically gathered. Most importantly, it logically depicts the systems based on their business functions, in a way that business leaders can understand.
If you or your firm is deploying these dependency mapping technologies, keep in mind this supply and demand paradigm. Ensure that you engage with your counterparts that support the line of business and ensure that your dependency mapping implementation will support their needs.
If your firm has this dependency mapping technology in place and there are data center relocation or optimization efforts going on, reach out to those teams as well. Datacenter relocation programs can benefit greatly from this dependency mapping technology. You will be considered a hero if you reach out to these teams and work with them to ensure your dependency mapping deployment will meet their needs and provide them extremely valuable data for planning and mitigating the risks associated with moving equipment in data centers.
Reader Comments