4 Steps to Manage Your Technology Portfolio

Share on LinkedIn4Tweet about this on TwitterShare on Google+1Share on Facebook0

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.

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

Share on LinkedIn4Tweet about this on TwitterShare on Google+1Share on Facebook0
  • 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.

  • 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 Ev

    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
    http://community.ca.com/blogs/theitgovernanceevangelist/

  • Steve Romero, IT Governance Evangelist, PMP

    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
    http://community.ca.com/blogs/theitgovernanceevangelist/

  • 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.

  • 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.

  • 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.

  • 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.

  • Pingback: Wearables: A 2013 Top Technology Trend for Business — CIO Dashboard()