Monday, November 10, 2008

Application Portfolio Management Resource Site

posted by Peter Mollins at
This new site exclusively is dedicated to best-practices for Application Portfolio Management is now online. The site explores what kinds of metrics that you should collect, how they should be combined into measures that have business utility, and what are the key attributes of an APM tool.

Application Portfolio Management is a methodology for identifying and prioritizing development activities. The aim is to locate misalignments between the application portfolio and business requirements, and then allowing managers and other IT professionals to adjust their resources accordingly.

APM is fundamentally about collecting business and technical metrics, combining them into useful KPIs in the right business context, and presenting them to decision-makers. On the site you'll find a wealth of relevant resources.

Labels: ,

2 Comments:

Blogger Unknown said...

Hi Peter,
Could you clarify if there is any difference between APM and APR. Is it valid if I assume that within APM we have APR followed by Application Modernization as different stages?
I found these terms (APM, APR) used interchangeably

November 21, 2008 at 2:40 AM  
Blogger Peter Mollins said...

Hi Rex

Thank you very much for your comment. Yes, I would say that there is a difference between APR (rationalization) and APM (management). APM is the process of providing intelligence about the application portfolio to the right user in order to facilitate a decision about what to do with an application. This could be (at the high end) a CIO deciding which application portfolios to outsource, or it could be more focused, say a development manager allocating priorities to her team.

Application rationalization is to decommission applications (and associated infrastructure) because of a lack of business need, change in technical direction, etc. The selection of which applications are targeted for rationalization would be the outcome of the usage of APM data. So, my APM process determined that a low business-value, duplicate application is consuming a disproportionate amount of resources. I decide to starve it of investment / rationalize it as a result.

Regarding your other point about ongoing process, I would also agree. That is, APM is not a static activity, it is ongoing – as your business changes and new information ‘feeds’ provide updated intelligence about cost, value, and risk. As new opportunities for rationalization are identified, you may execute on them and continue to monitor for emergent priorities.

As to whether rationalization is a separate category from modernization, I have no complaint against that view. Personally, I prefer to think of rationalization as a variant on modernization because I define modernization as being any significant change to the application portfolio (i.e. not maintenance and enhancement). Other kinds of modernization would include incremental replacement with COTS, outsourcing, re-architecting, redevelopment, and many others. The sister site on application modernization has more detail.

I would agree that there are stages: first, understand what you have in your inventory (this is often lost over time -- basically bringing yourself up to speed). Second, make initial decisions about what to modernize (including what to rationalize). Third, execute on the modernization activities. Fourth, continue to maintain the applications. APM then becomes an 'always on' process that continually monitors for opportunities to modernize.

If you had any pointers to where you felt like there could be confusion, please feel free to post. I’d like to make sure that the content is as clear as possible.

Thank you again,
Peter

November 21, 2008 at 8:48 AM  

Post a Comment

Subscribe to Post Comments [Atom]

<< Home