Ah, good old Application Portfolio Management. Application Portfolio Management, or APM, is one of the classic activities in enterprise architecture. Most consultancies even have their own marketing material for APM initiatives. The story that these materials tell is generally the same – find the applications that are duplicates and consolidate them, find the applications that you don’t need and get rid of them, saving ongoing cost in both cases. Which is true as far as it goes, except that what happens if there aren’t as many opportunities for rationalization as hoped? Or what if the costs of rationalization are significantly higher than expected?
If you have, say, a bank or a pharma company that has grown by acquisition then yes, you’ll likely have plenty of duplication between different units to address. And yes, plenty of organizations may have different departments that have separately implemented similar or the same applications. But going in, you won’t know (which, let’s face it, is usually the point – if they had their portfolio identified and under management then they wouldn’t need the APM initiative). So what happens if the potential savings are disappointing either due to lack of opportunity or high lock-in costs?
Fortunately, there are more benefits to establishing an application portfolio than just rationalization opportunities, and knowing about them means that we can set the expectations up front about a range of the possible benefits that we expect – and ensure that we work to accomplish these benefits during the exercise.
First of all is consistent reporting. Establishing the identified set of applications, with consistent naming, opens the doors to integrated statistics. For example, if the finance department knows a given application by one name and the trouble ticketing knows it by another, how can you produce integrated statistics? Even worse is when different groups within the organization know the application by different names – and record tickets or implement projects under these names. So having an established portfolio of applications is an essential step to ongoing analysis of the applications the organization has.
A second benefit of an application portfolio exercise is that it can often expose unnoticed areas of risk – for example, through use of inappropriate technologies or working practices that may even have been safe at one time but have become unsafe due to othr changes in the IT estate. As an example, in one recent project I found that while all applications using sensitive data had been migrated away from access databases several years before, the access databases in question had been left dotted around their respective file shares, still containing the sensitive data with only 40-bit encryption to protect them.
A final benefit is that, where the application portfolio exercise is allowed to go and talk to the application owners (I've encountered places where this has not been the case), they can validate the problems and needs that the normal IT demand management channels are reporting. In my experience, it's highly unlikely that the application portfolio team would they'll hear anything different to what's already being reported... yet it's basic human psychology that having another voice confirm something lends a surprising amount of weight to the original voice that reports it. So the APM exercise becomes an opportunity to build trust in this respect.
It's human nature to focus on the obvious business case, which for APM is the idea of identifying redundant applications and rationalizing them. But it turns out that there are a number of other benefits as well. It's important to draw out these benefits, both so that opportunities to profit from them are not missed, and to guard against the occasional case where the primary business case turns out not to be as powerful as was thought going in to the exercise.