Just like your car, just like your home, just like everything physical you own – IT Infrastructure will wear out, and it will break. I can’t tell you the number of times I’ve stepped into the head of IT Infrastructure role to find hardware upwards of 10 plus years old installed and supporting mission-critical applications with the business suffering under far too frequent Sev 1 outages.  Nothing erodes confidence in IT more than critical service outages. No one is interested in talking strategy or innovation with the CIO when core IT Services are not on solid footing.

Before you say, “That does not happen these days, everyone hosts their servers at AWS, Azure, Google, etc. “, please read the February 26 Tending the Plumbing article. According to a 2019 Spiceworks State of IT Budgets  article, 20 percent of IT budgets are spent on IT infrastructure. The 2019 Spiceworks research also shows the current reality is that 98 percent of businesses are running server hardware on-premise. (That is not to say 98 percent of servers are on-premise. It does not matter if you have one or two servers, or hundreds, if you are an organization of any size, you will have network equipment.)

What is IT Infrastructure again? 

IT infrastructure is the shared technology resources that provide the platform for the firm’s specific information system applications. IT infrastructure includes hardware, software, and services that are shared across the entire firm as well as access to external services such as web-hosted applications and services. Major IT infrastructure components include computer hardware platforms, operating system platforms, enterprise software platforms, networking and telecommunications platforms, database management software, Internet platforms, and consulting services and systems integrators, including desktop and mobile devices and software. Virtually, everything digital requires direct support or access supported by IT infrastructure. It is often the largest area of spending by an IT department.
There are four significant steps to an infrastructure roadmap approach:
  1. Established IT infrastructure lifecycle refresh strategy
  2. Identify current IT Infrastructure inventory
  3. Risk assessment
  4. Prioritizing IT Infrastructure Roadmap

IT Infrastructure Lifecycle Refresh Strategy

IT Infrastructure is comprised of hardware, software, and services shared across all platforms.
The hardware and software lifecycle is dependent on the supplier’s support plans and the company’s needs and wants to adopt the functionality and capability of more current versions.
Hardware is typically refreshed based on acquisition strategies (capital versus expense) against risk tolerance, resource capacity, and expense management requirements and will vary based on hardware categories. I’ve always used a general rule of thumb for budget planning:
  • PC’s: 36 months
  • Servers: 60 months
  • Routers/Switches 72 months
Like all rules of thumb, rules will be broken based on business growth and variables not always under IT controls.   A  sophisticated perspective of hardware refresh cycles can be found at https://www.computereconomics.com/article.cfm?id=2580

IT Infrastructure Inventory

First and foremost, your IT strategy and roadmap should include Infrastructure.   A good plan starts with understanding the current state, including an inventory of all things managed.  We want to hope that everyone has a robust configuration management database in place, but we know all too well that is often not the case.  At minimal, an asset inventory is required. If you don’t have one, you will need to create one utilizing a series of tools such as Microsoft’s SCCM, Solarwinds, and other asset management tools.


Fortunately, asset management tools such as Snow, Flexera, and ServiceNow are being challenged by many newcomers to the asset management space    https://www.gartner.com/reviews/market/software-asset-management-tools


Unfortunately, in some environments, there may be mission-critical IT equipment not attached to the network requiring a physical inventory exercise.  I’ve found this to be the norm in a manufacturing environment.  At a minimum, it is essential to research.

While gathering the physical attributes of the hardware will require identifying the services hosted, the install date and installed OS, utilities, and application software versions.  The service support lifecycle of both the hardware and OS should also be noted.  (Heads Up: Most of the time, this level of inventory rigor reveals configuration items underutilized, no longer relevant or never fully implemented.  That in itself is an excellent reason to build the inventory)
Once you have a substantial inventory, the next step will be to assess the risks associated with the individual pieces of hardware and software.

Risk Assessment 

Prioritization for executing refresh will be based on the risk associated with each inventory item.  Assessing the risk is a bit of art combine with science. Your assessment should take into consideration the business risk and technology risks of the current state. From a business risk perspective, you will want to weigh and assess the capacity and  maintenance cost.  Regulator compliance, and any health and safety risks the age and state of the hardware may imply.

From a technical perspective, vendor support quality, availability, service reliability. The complexity of support, including skill sets required, security, performance, standards conformations, and overall vendor security and performance characteristics, weigh into your overall assessment.

To add to this already multi-dimensional assessment, application projects in process as well as planned layered onto critical business calendar events must be identified as they will influence the timing and order of refresh activities.


Prioritization and Refresh Roadmap

This big picture holistic approach of identifying the landscape and assessing risk will prepare you for defining your technology refresh roadmap.  The roadmap will be a series of projects laid out across multiple years.  I have found managing the refresh projects grouped by technology as a program to be the best practice as the interdependencies can become unwieldy.  If the organization does not have an infrastructure project management life cycle, one can typically be developed using the existing waterfall systems development lifecycle.  The point here is the necessity of establishing the rigor of requirements, phase gates, resources management, change management, timelines, and success factors.

In Closing

It is simple, at the same time hard. Hard because it is not fun, often results in unplanned work and expense, and most importantly does not offer an apparent return to the business – until something critical breaks.  My advice to you is: Don’t be that CIO or IT Infrastructure leader left to account for allowing the company to be put at risk.  Call me if you want to discuss more or are looking for hands-on help in addressing your refresh requirements. That is not me, but I am sure I can recommend qualified resources.

Until March 25, have a great two weeks!