Application Portfolio Management doesn’t have to be a huge cost…

I worry sometimes. People spend so much energy preparing to move to the cloud that they take their eye off the ball. Why move everything you have?

Cloud vendors and analysts say you can save 20% on average by moving to the cloud. It is in the end probably true but there are a lot of caveats to that 20%. In fact I can honestly say after years of visiting US Federal Agencies and US and International Commercial companies that I can save most companies 20% and not move to the cloud.

Simply by creating a rationalized managed portfolio. I built a process when I was at Microsoft for Lotus Domino customers. The goal was not only to figure out what Domino were deployed at the time but to build a portfolio.

People always say Application Portfolio Management is expensive to do. In the end it actually isn’t, it’s expensive not to do. The concept was simple take a look at the architectural view of the enterprise (perfect state what should be deployed) then let’s see what management tool is in place (LANDesk, SCCM etc.) and ask it to pull a listing of everything deployed on desktops and servers. Now we have a list of what is deployed. Map that to should be deployed and we immediately see that there is a lot more deployed than we thought.

You only need one tool + training for PDF creation. That can be said for a number of capabilities in your organization. The what of your portfolio in the end can be as telling as the how. So what capabilities really contribute to your business or mission overall?

In the end why not do these first two steps. Once you have them done and a good idea of the money you are wasting you can remove that cost from your business and deploy a APM solution. Doing this in a two-step fashion reduces the amount of money your organization has to lay out in the beginning of the project. In fact if you do it in this order you won’t increase your budget at all.

  1. Preform initial evaluation of what should be deployed. Based on what should be deployed (both architecturally and contractually) determine the what and how of your capabilities.
  2. Map that to the assessment of what you actually have deployed. The difference is what you can remove.
  3. Begin removing the extra and non-compliant software.
  4. Develop training and deploy training (at the same time as removing software) to reduce fear of change.

As I said that is for all intents and purposes what we developed back in 2005 and AAEP (the link is above). Simply put it actually isn’t expensive to build a portfolio of your applications.

In the end its pretty straight forward.


Scott Andersen

IASA Fellow.