The Life and Death of IT

If you were looking for another “IT organization of the future” story, this is not it.  For that, I can recommend the book FruITion by Chris Potts - sort of a business novel on IT strategy and organizations in the same vein as Patrick Lencioni’s Five Dysfunctions of a Team.

And no, I am not jumping on the Nick Carr “IT Doesn’t Matter” bandwagon.

Instead, this post is about managing the life and death of technologies in an enterprise. Not projects or applications, but the portfolio of the underlying technologies - operating systems, DBMSs, development tools, middleware, etc. These must be managed too or you will find yourself in the same situation as a client CIO of a large grocery chain did a few years ago.  The servers than ran his in-store processors - the computers in the back office of each store that run the point-of-sale computers, cash management and inventory applications - were discontinued by IBM.  Not only did IBM tell him that they would no longer support the servers, they told him that his staff that managed them probably represented the largest pool of skills in the country for the devices!

So, the technologies that underlie our business applications have a shelflife that must be actively managed, with plans to introduce and retire them just like the applications they support.

To get a handle on your tech portfolio, there are 4 basic steps.

1.  Create a Technology Inventory

The first challenge is to get a list of all of the different technologies you have in use.  Some of the attributes you may want to capture include:

• Component Name and Vendor
• Version or Model
• Component Type - operating system, DBMS, development tool, etc
• Applications it Supports
• Number of Users Supported
• Amount Spent Per Year (labor + licensing + upgrades)

If you already have a decent inventory, consider yourself very prepared - most firms don’t in my experience.  Also, anything you can do to tie each component to value, users or processes, the better.  These attributes will help you with prioritization later.

Another dimension of the technology to consider is vendor stability.  While the technology itself may not be obsolete, the vendor may be so small that the component should be considered high risk and flagged for review.  For one of our financial services clients, a small vendor provided the foundation for one of its banking applications and the vendor went bankrupt.  The client ended up with a pile of code and no one who knew anything about its inner workings.  Not good.

2. Map Technologies into their Stages

The next step is to figure out where each technology sits in its lifecycle.  For some background on technology lifecycles, I highly recommend Geoffrey Moore’s Crossing the Chasm; its an oldie but a goodie.  Moore categorizes technologies into 5 stages:

1. Innovators
2. Early Adopters
3. Early Majority
4. Late Majority
5. Laggards

Use this, or another classification scheme to describe where you think each technology lies in its lifetime.  There is a bit of art to this as there is no single reference for this kind of thing.  At Diamond, we have developed our own database, blending market data with our own observations and experience.  Forrester and other analysts can help a lot too.

3.  Analyze and Act

Once you have all of the data pulled together, you need to take some time to digest it and mull over possible changes that you need to work into next year’s plan or maybe something sooner.  Several years ago, probably with Moore’s book fresh in mind, I started mapping this data onto a bell curve.  In this example, the size of the circle represents relative cost.

Pay special attention to the technologies at the front and rear of the curve.  For the older technologies in the portfolio:

• How many users are they supporting and how much does it cost?
• What is required to retire it and its related components?

For the bleeding edge technologies:

• Do you really need them or are they toys in someone’s toybox?
• How will you know if they should be used in more core, mission critical applications in the future?

After analyzing, collecting and refining the data and asking a lot of questions, you may be ready to make some changes, either in your annual plan or as a more immediate action.

4.  Create a Process to Review and Refresh the Portfolio

So that all of this effort is not a “one and done,” you should embed a periodic review into your core planning, architecture and governance processes.  One of my insurance clients gave responsibility for managing the technology portfolio to the Enterprise Architecture function. In fact, they considered this entire process part of their technology innovation process.

Like its applications siblings, managing introduction and retirement of underlying technologies cannot be done alone - it requires coordination across all IT disciplines, including planning, development, architecture and infrastructure.  But it is important to have a coordinator responsible for collecting and analyzing the information and bringing it to the proper leadership forums for discussion.

Some final questions to consider for your organization:

1. Does it even make sense to consider the technology portfolio separately from the applications they support?
2. How much responsibility do we assign to our vendors in helping us identify and manage technology introduction and retirement?
3. Can the old age (and lack of skills, etc.) of a DBMS or middleware component be enough to drive a major application change?

Related Posts

1. A CIO Can’t Do More with Less
2. Run IT Like a Business, Not As a Business
3. A Resurgence of Portfolio Management?
4. Is Agile an “All or Nothing” Proposition?
5. The 4 Types of CIO Dashboards

Did you enjoy this article? Please subscribe to CIO Dashboard to receive the latest posts!