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 retailer did a few years ago.  The servers than ran the 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 the vendor.  Not only did the vendor 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 shelf life that must be actively managed, with plans to introduce and retire them just like the applications they support.

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

1.  Create an inventory of the technology portfolio

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)
• Sourcing – internal, hosted, cloud, etc.

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.  There is no single, hard-and-fast classification scheme but the technology lifecycle typically is segmented into five or six phases, such as the following:

1. In the Labs
2. Emerging from the Labs (early adopters)
3. Leading Edge
4. State of the Market
5. Last Generation
6. End of Life

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 PwC’s Diamond Advisory Services, we have developed our own database, blending market data with our own observations and experience.

3.  Analyze the portfolio 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. It might be useful to map your 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 technology 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?

Photo shared by crabchick