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.
|
TIME |
Tolerate |
Monitor |
MURDeR |
|
Invest |
Rewrite or Replace |
||
|
Maintain |
Update |
||
|
Eliminate |
Delete |
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
Mapping options to the
value/cost grid
The need to look beyond the
cost/value matrix
The need to look at MURDeR
options over the long term
“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:
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 |
Maintain |
Invest |
|
Low Value |
Tolerate |
Eliminate |
|
|
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 |
Monitor |
Delete |
|
|
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.
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:
“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:
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.
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.
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.
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 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:
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.
References
Ref. 1: “The Trouble with
Ref. 2: “Agree EA funding model or ROI metrics in Avancier Methods at http://avancier.co.uk
Ref. 3: “Architectural Myths” at http://avancier.co.uk
Ref. 4: “Can we measure architecture” at http://avancier.co.uk
Ref. 5: “Buy Package or Enhance Legacy?” at http://avancier.co.uk
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: http://avancier.co.uk”
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 http://creativecommons.org