Imagine you’re Sara, the CIO of your retail company with 10,000 employees. You have 500 employees within IT reporting to you. Your manager, Fred, the CFO, calls you into your office and asks: “Sara, how many applications does IT support?” My first thoughts (as Sara) are: “why is he asking? Is there a problem?”. My next thought is: “Does Fred want me to change the way I run my end of the business?”
Regardless of your initial thoughts, if you’re a typical CIO, the simplest and most straightforward answer is “I don’t know”. The truth could be anywhere from hundreds to thousands for a medium/large size organization that Sara supports. A more nuanced answer would be something like:
“Well Fred, we have 8 mission critical applications supporting the store systems side of the business, another 3 supporting merchandising, 5 supporting our supply chain, 3 for customer service, and of course, our e-commerce site. They all have SLAs that we defined and track on behalf of the various business stakeholders. There are approximately 250 other applications throughout IT that support the organization, but we don’t track them very closely. Finally, there are as many as 500 applications that we host in our datacenter but we provide no support for them.”
Sound familiar? It should. This is a classic problem of limited application portfolio visibility. Most IT shops support a vast array of applications, but only the ones that are either considered mission critical or directly support the business are managed closely by datacenter operations. This typical scenario presents the following challenges for you:
- “Rogue” applications deployed into the datacenter could cause quality of service issues for the mission critical and/or tier 2 applications
- Changes to any application in the environment could cause sudden, unpredictable resource spikes (network, data access, server CPU/memory) affecting any of the mission critical applications (and impacting the SLA)
- Lack of visibility into which datacenter resources are associated with what application, such that, if a server goes down, IT operations may not know how many applications would be affected by the components on those servers becoming unavailable
- Higher costs of deploying 3rd party applications on dedicated hardware
- Higher costs of duplicate functionality from similar applications
- Lower agility and higher costs due to not being able to optimize the server and storage resources for the application portfolio
Do you care? Absolutely! But, what can you do? Neither application development teams nor their IT support staff typically don’t define a production IT topology specifying where various components of the app will reside.
I’d like to hear from you about your experience with this dilemma. Does it ring true for you? Are there other pitfalls you see with this lack of visibility.
In my next post, I’ll discuss the “costs” of the problem in money, time, lack of agility, poor service quality, and risk.
All the best,
Erik Svenson, Strategist, War on Cost