EMA Blog Community

This parrot is no more. It has ceased to be. It’s expired and gone to meet its maker. This is a late parrot. It’s a stiff. Bereft of life, it rests in peace. If you hadn’t nailed it to the perch, it would be pushing up the daisies. It’s rung down the curtain and joined the choir invisible. This…is…an…ex-parrot!

John Cleese, Monty Python’s Flying Circus

Death.

We don’t like to talk about it. In daily living, and in IT. Fortunately this post isn’t about actual physical dying, but its analog in the IT lifecycles. Regular readers will know that I propose four:

• Application service lifecycle
• Infrastructure service lifecycle
• Asset lifecycle
• Technology product lifecycle

In enterprise IT, each goes through birth, life, and death.

• The application service is born through the need of the business partner, built or acquired, maintained and operated until the business need passes, or the service architecture becomes so unsuited that all agree a “new” service in the same space is called for.
• The infrastructure service is born through the need of IT service providers to maximize value through sharing common platforms and capabilities, such as hosting, network, and storage, but also including higher order services such as backup, middleware, and monitoring. Again, it is operated until the technical need passes, or the service is so obsolete that a new service is agreed upon.
• The asset (typically hardware or software) is forecasted, acquired through well understood supply chain mechanisms, delivered, installed, operated, and then retired.
• The technology product (in well managed organizations) is identified first as a possible enabler, vetted for suitability, approved for deployment, maintained at a product level (e.g. patching all instances of some software), and then declared moribund and eventually retired.

These are three different kinds of death, prompting very different issues:

• Services (both application and infrastructure) first require attention to “what depends on this? What is it related to?” The departure of a service affects downstream (supported) services, who may depend on its services. It also affects upstream (supporting) services, that may have been engineered on the assumption of the deceased service’s demand. Your CMDB may be critical here. Second, has the service managed data of any sensitivity? Is litigation possible against the data, even after the service is done? Perhaps the data must be maintained in some accessible form even after the service is considered gone – this may not be a welcome message to the service’s sponsors, who must absorb the associated costs. Products such as IBM’s Optim are used here.
• Assets cost money to acquire, and also to retire. Physical IT assets contain nasty physical toxins, that must be properly disposed of. Memory devices (disks, and increasingly solid state devices) must be wiped of enterprise data, and in some cases regulators and enterprise risk management insist on them being shredded. Some devices may have resale value, but others not, and sorting that out for maximum benefit is non-trivial. These issues are becoming so significant that a major proportion of sponsors for IT asset management conferences are the asset recovery and disposal vendors, such as U.S. Micro.
• Retiring technology products is in some ways the most challenging. It’s neither a service nor an asset, but a type of building block. When a product (such as Oracle Version X) goes off support, it places the enterprise at risk, yet thoroughly removing it can be very hard. The need for investing in upgrades can be unwelcome news. Vendors such as BDNA are starting to provide market data services here, so that you can purchase reliable information on what products in your portfolio are retiring when.

The old must give way for the new to emerge, and so it is in IT as in the rest of existence. Being in denial about the end of IT lifecycles is costly and ineffective. They all need explicit processes and some level of resources.

Going to sign off before I start waxing too philosophical….

Charlie