Application Portfolio Management is one of those classic 'quick wins' for architecture... it ticks a number of boxes in terms of convincing senior management to back the initiative. The concept is easy to understand: identify what the organization has installed, rationalize it and save some money. It offers the lure of saving money without removing organizational capability: if applications are unneeded or duplicated, then surely it's safe to retire or rationalize them. It's a well-established idea, not some bleeding edge initiative dreamed up by a single consultancy: stakeholders can feel comfortable that they aren't going out on a limb to back an unproven concept.
However, this classic telling of the case for application portfolio management can be simplistic and makes a number of assumptions. For example, it assumes that different departments can have overlapping software – but this is not always the case, especially if there's no overlap of business function between departments. It also ignores the fact that even where the functions overlap, they may need to be executed in different ways because of different constraints imposed by external factors.
So, the traditional story of rationalization is true to a greater or lesser extent depending on the nature of the organization. However, APM can still deliver much value even when this is the case. Organizations are different, and if the application landscape is to reflect the organization, this means that different organizations will have very different application environments - including different ways that they can benefit from actively managing their portfolio of applications.
To explore this idea, I'm going to use the taxonomy of organizations identified in the well-known book “Enterprise Architecture as Strategy”, by Jeanne W. Ross, Peter Weill, and David C. Robertson. In this book, which was based on insights gained from more than 400 organizations, the authors classify organizations based on two axes; the level to which different departments within an organization share the same processes, and the level to which different departments within an organization share the same customers. This approach identifies four basic types of organization, as listed below:
-
Coordination: business units have the same customers but do different things (e.g. Financial Services)
-
Diversification: business units have different customers and do different things (e.g. Starwood Hotels)
-
Unification: business units have the same customers and do the same things (e.g. Dow Chemicals)
-
Replication: business units have different customers but do the same things (e.g. McDonald’s)
It seems obvious that a unification organization (same customers and do the same things) will have more opportunities for rationalization than a diversification organization (different customers and do different things). But, to reiterate, both organizations can receive value from engaging in application portfolio management – it is simply that the emphasis will be different.
Over the next 4 articles, I'll be drawing on the insights that the authors of this seminal book provide and examining what implications they have for application portfolio management initiatives in each type of organization.