CIO Dashboard
The Life and Death of IT

The Life and Death of IT

by Chris Curran on May 27, 2009 [email] [twitter]

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!


Peter Kretzman May 28, 2009 at 11:48 am

Twitter: @PeterKretzman

Excellent article. However, your final question #1 is where the rubber hits the road. Many/most IT areas are completely inundated with user-driven projects (as it should be), taking up all available resources. The conundrum then becomes how to do things like necessary technology refreshes and “sell” these to a skeptical clientele who just wants their functionality and who collectively yawn at IT technobabble (to them) like “middleware” and “protocol.” Everything has to be business-driven in the end, I firmly believe, but it’s a catch-22: users tend to drive only what they understand and which benefits them directly. Education up and down the chain is an ongoing process to counteract all this.

Steve Romero, IT Governance Evangelist, PMP May 29, 2009 at 6:24 pm

Twitter: @itgevangelist

Application Portfolio Management is just as critical as the Technology Portfolio Management you aptly describe. You need both disciplines to have any chance of knowing asset value, criticality and risk - the information necessary to make related investment (project and program) and operational decisions.

And Peter Kretzman brings up a very critical point above. The primary reason to apply portfolio management discipline to technology and application assets is to enable business-related interpretations and characterizations. It is critical for IT to be able to make a direct correlation between the assets in these portfolios and the services they provide to the business. This correlation is then factored into the associated SLAs that provide the business context and information to make business decisions in regard to those portfolio assets.

Consider the grocery chain example in the post: The discontinuation of vendor support will have a direct affect on IT’s ability to continue meeting negotiated SLAs. In response to the vendor move, IT would use the information in these portfolios to determine the subsequent affect on the SLAs and present associated ramifications to the business. The conversation would look something like this:

“The vendor has discontinued server support. If we do not move to a new server infrastructure, here is the affect it will have on your SLA for the service supported by the antiquated infrastructure - service levels will degrade to this extent while service cost will increase to this extent. Here are the investment alternatives and their associated services levels and costs.”

It now becomes a fact-based business decision to stay on the existing infrastructure (and resulting SLA impact) or invest in new infrastructure and a newly negotiated SLA.

The reason we have “IT Projects” is because we don’t have these portfolios and the critical information they provide to enable us to make the essential correlation between our technology assets and the business services they provide.

Thanks for providing some great advice in regard to changing this intolerable situation.

Steve Romero, IT Governance Evangelist

Michael Keen May 29, 2009 at 10:42 pm

It all comes down to the understanding and the proper management of the IT life cycle and IT Portfolio Management. Without this critical component along with EA, IT Governance, this situation is doomed to be repeated time and time again.

Ralph Hofman, BlinkLane Consulting May 30, 2009 at 4:42 am

Technology Portfolio Management is a real challenge. I fully agree with the former comments, that managing the application portfolio and managing the technology portfolio are inseparable. From a business point of view, however, the part that adds business value is only the application portfolio. So having to deal with managing the technology portfolio is not one of the core activities for most businesses.
To me, this all the more reason to look for solutions were you get your applications as a service. By contracting software as a service, you are able to outsource the technology portfolio management part.

Comments on this entry are closed.

blog comments powered by Disqus

Previous post:

Next post: