Application Portfolio Management is MURDeR

This page is published under the terms of the licence summarized in footnote 1.


Applications in a portfolio are often classified using the acronym TIME.

This paper extends the classification with an additional entry and presents it as MURDeR.







Rewrite or Replace






The first thoughts of an application portfolio manager are often to cut back application maintenance/update budgets and replace old systems with new packaged solutions.


“I agree that most IT organisations look to cut back IT budgets and replace old with new.” Nisheed Rama


Sometimes these are wise decisions.

However, these decisions can so easily turn out to be unwise.

This paper introduces the application portfolio manager’s decision options, and leads to a companion paper which explores the business case for buying a package.

The challenge of application management 1

Mapping options to the value/cost grid. 2

The need to look beyond the cost/value matrix. 3

The need to look at MURDeR options over the long term.. 4

Conclusions. 6


The challenge of application management

“Technology is supposed to simplify business …

But did the large software applications that were supposed to streamline large companies instead irrevocably slow them down?

There’s a compelling argument to be made that they have [slowed them down].”

Ben Worthen - the Wall Street Journal Business Technology Blog – as quoted in ref. 1.


Surely there is no surprise here? Of course an enterprise’s computer systems are not as flexible as the human activity systems they replaced.

Computers are certainly faster, are more accurate in the application of given rules, and may be cheaper, but they will never be as flexible as human beings.


And of course bigger systems are more complex and harder to change.

Ref. 4 suggests that the potential complexity of a system’s configuration rises disproportionately with the size of the configuration.

So the bigger the application, the more application management is needed.


Application portfolio managers are employed to minimise the cost and maximise the value of enterprises' information systems.

This is a very difficult task.

A first step is usually to analyse the enterprise’s application estate, estimating the financial attributes of each application:

  • Spend on the application – running and maintaining.
  • Value of the application in terms of its contribution to profit or turnover.
  • Cost of removing the application.

Mapping options to the value/cost grid

A traditional way to simplify management decision-making is by placing the items under consideration in a “Boston grid” (aka Magic Quadrant).

The basis of a Boston  Grid is two dimensional matrix.

For example a usefulness/usability matrix.


High usefulness

Apps A, E

Apps B, F

Low usefulness

Apps C, F

Apps D, G


Low usability

High usability


Trouble is, there are usually six, seven or more dimensions to consider.

Of the many possible grids that can be drawn, managers want to see a value/cost matrix.


High Value

Apps A, E

Apps B, F

Low Value

Apps C, F

Apps D, G


Low Cost

High Cost


Some say the application portfolio manager has four options for each system (Tolerate, Invest, Maintain and Eliminate) and place these options in the cells of the value/cost matrix.


High Value



Low Value




Low Cost

High Cost


The labels of the options are somewhat misleading, since they all require investment, and any option that precludes any maintenance leads to system extinction.

In this paper, the options are called: Monitor, Update, Rewrite, Delete and Replace (MURDeR).

Again, the options for each system can be placed in the cells of the value/cost matrix. Perhaps in this way.


High Value

Monitor, Update

Rewrite, Replace

Low Value




Low Cost

High Cost


The main theme of the next paper is that the Update option should be considered more seriously in the top right quadrant.


Before we get to that - Is the cost/value matrix enough? No.

This paper points out that the value/cost matrix is naïve.

It is naïve to classify application this way, and it is naïve to view the MURDeR options as mutually exclusive.

One option inevitably leads to another.

Over the long term, every valuable application must be maintained or replaced, and probably both.

The need to look beyond the cost/value matrix


There is of course more to it than naïve cost and value estimation.

First, you have to bear in mind the current business performance and the trading conditions.

If you are in a recession or the company has a limited lifetime ahead then (obviously) this will limit the amount you can spend and constrain your use of the cost/value matrix.


Value? Most value numbers are challengeable. Many are guesses.

The paper at ref. 2 explains how difficult it is to measure the value of any typical enterprise application.


Cost? Of course your big systems cost a lot to define and run.

Absolute cost may not be an issue.

The manager has to ask about relative cost – that is, the cost compared to an alternative system.

And there may be many answers to that question – one for each alternative.

So you have to consider:

  • The current and future market of alternative applications.
  • Cost and value of each alternative solution.


“This is a really good point.

Sometimes, cost alone can play a differentiating role.

Most large multinationals (e.g. Telcos) have many applications that provide similar functions.

After you have narrowed down your options to maybe a handful, cost is the last differentiating factor used to rationalise your portfolio.


More generally, applications or IT portfolio management is akin to financial portfolio management.

IT applications should be managed like a well balanced financial portfolio.

In the latter, the performance of equities and other assets are measured against set objectives and competing investment alternatives.

Only if the alternative provides better return is the current equity replaced by the alternative.

Cost is considered in the wider context, so a higher-cost investment in equity could return a larger net cash flow - higher NPV returns.”  Nisheed Rama


And then, the application portfolio manager must look beyond the simple cost and value numbers to what might be called ‘technical qualities’ including:

  • User satisfaction
  • User familiarity and potential retraining costs
  • Qualities of data maintained by the application (confidentiality, integrity and availability).
  • Whether the technology platform is deprecated or to become obsolete

The need to look at MURDeR options over the long term

The MURDeR options listed below are not mutually exclusive; one eventually leads to another.

In the medium-to-long term, you have to consider the update option for every system.

And in planning for the long term, you should amortise the costs of the replacement system that will eventually be needed.


If a system is low cost and low value (or high value with no outstanding change requests) then you may choose to ignore it for now.

But note that if you don't invest now in update resources, it may well become extinct.

Update (ongoing application management)

If a system is low cost and high value, then you should plan for its survival.

You have to invest in application management resources - usually called a maintenance team.

(Even though working software does not need maintenance in the same way that hardware needs maintenance, because software does not wear out.)


Here, the owner must employ a persistent maintenance team with the skill to refactor the system design when needed.

Whether this team is directly employed by the owner, or by an IT services provider or a package vendor, is not the concern here.

The point is that to be successful, the update option implies continual nurturing of the system.

The most effective and efficient systems grow in this way - rather like biological evolution (see ref. 3).

The maintenance team must do useful work on the system every so often, to exercise their knowledge of the system.


The owner must not allow change requests to build up – unprocessed – because the maintenance team will be employed to work on other things and lose contact with the system.

Grudging or occasional maintenance leads to an increase in entropy.

What if sponsors will not pay for more than the minimum effort, or if designers don't understand the whole configuration?

Then, as a series of change requests are processed, the entropy (disorder) of the system increases, change becomes harder.

Either, designers must now and then refactor the system to remove waste and optimise the design.

Or else, grudging maintenance will inexorably lead to the extinction of the system.

Rewrite (bespoke)

Sometimes a high value system becomes high cost because it is reaching the end of its life.

This may arise because a system has not been continually refactored with a view to keeping it maintainable, or because the platform on which the system depends is no longer maintained.

In this case, you have the option of writing a new bespoke system.

Despite the common rubric “buy before build”, bespoke redevelopment can prove better than buying a COTS package, for reasons to be explained.


Note that the “rewrite option” in this paper should be much cheaper than new bespoke development.

Provided, that is, it is limited to rewriting a current application of known functionality to work on a new (and hopefully more flexible) infrastructure platform.

Beware making ‘judicious enhancements’ on the way.


If a system is low value and high cost, or if users to do unwanted things with it, then the portfolio manager may plan for its extinction.

Deletion is not trivial. You have to invest in effort to remove a system. And you have to consider whether some kind of rewrite or replacement is needed.

Replace (package)

The manager may look to replace a system with a pre-packaged solution for various reasons.

Not necessarily because the package is a better system, which gives its users new functions or better usability.

Often (perhaps more often) because:

  • the current system is high cost.
  • the current system cannot be upgraded to work in a changed environment.
  • there is a need to standardise on one of several similar systems already in use.
  • managers don't want to manage the current system; they want to outsource the necessary thinking.


The last is common; the owner is simply unwilling or unable to pay for enhancement of the old system, and hopes that a replacement package will be simpler and cheaper.


However, replacement can prove a false economy.

When planning to invest in a replacement system, you must consider the short-term migration costs (effort to remove the old system - effort to migrate data from old systems to replacement systems - loss of functions, etc.).

But also consider the long term costs.


A reader writes of his experience:

“Once your CEO takes a decision to buy big ERP package (if for no other reason that he has heard of it) then the 2-3 years of hard work and angst are inevitable.

But in the end it can be worthwhile.”


We’ll expand on this experience in the next paper.


There is much more to say. You should go to read the next paper (ref. 5), which addresses:

  • Experiences of implementing big ERP packages
  • The need to cost packages properly
  • The need for a maintenance strategy


The radical conclusion of the companion paper is that there may be 'break-even' package cost.

Below this, one should tend to favour regular replacement and minimal maintenance.

Above it, one should tend to favour strong maintenance and deferring replacement as long as possible.

But I don’t know how to calculate it.



Ref. 1: “The Trouble with Enterprise Software” Cynthia Rettig, MIT SLOAN MANAGEMENT REVIEW, FALL 2007

Ref. 2: “Agree EA funding model or ROI metrics  in Avancier Methods at

Ref. 3: “Architectural Myths” at

Ref. 4: “Can we measure architecture” at

Ref. 5: “Buy Package or Enhance Legacy?” at



Footnote 1: Creative Commons Attribution-No Derivative Works Licence 2.0               26/05/2014 15:00

Attribution: You may copy, distribute and display this copyrighted work only if you clearly credit “Avancier Limited:” before the start and include this footnote at the end.

No Derivative Works: You may copy, distribute, display only complete and verbatim copies of this page, not derivative works based upon it. For more information about the licence, see