The Application Portfolio Manager
#1 of jobs that should exist but don’t in most IT departments
What should we do about all the legacy stuff?
This was a question that came up at the closing panel of the Agile Enterprise Rome conference I was at in May. The context was ‘we’ve spent a couple of days hearing about this great stuff with microservices and containers and serverless, but what should we do about our legacy?’.
I’ve heard this question, or some variant of it, many times over my career.
My answer in Rome was something like this:
The very reason that legacy exists is that it satisfies a business need at a price point that’s better than migrating to something new.
There are some important implications to that statement:
- You’ve actually figured out what the migration costs are
- Those costs are regularly re-evaluated to take account of industry changes
Those things imply a portfolio management approach where each application has a value and a cost to trade out of a given position, and where the portfolio is reappraised on a regular basis. This isn’t something I see being done in a particularly structured way in (m)any organisations[1].
Step functions and gravity wells
A big part of the problem here turns out to be non linearities in the (license) cost for many legacy systems.
How much do you need to reduce your mainframe MIPS to cut your mainframe spend by 50%?
It turns out that the answer to that isn’t anything like 50%, or even 75% or 90%. In most cases it’s essentially impossible to cut mainframe spend by reducing usage unless the mainframe is completely eliminated. The same is roughly true for many classes of legacy software driving an ‘all or nothing’ approach.
This picture is further complicated by bundling within Enterprise License Agreements (ELAs), where account managers will hold firm on well established revenue (their cash cows) but happily throw in some of their shinier new stuff[2]. There’s also the issue of ‘where software goes to die’ vendors that aquire and hoard legacy assets giving them multiple points of leverage when it comes to ELA (re)negotiation time – they’re good at playing the portfolio management game.
5 Rs
There are multiple options for what happens to an application when it’s moved off a legacy system. Gartner suggests the 5 Rs[3] in its ‘Five Ways to Migrate Applications to the Cloud‘:
- Rehost
- Refactor
- Revise
- Rebuild
- Replace
Broadly this has approximately nothing to do with ‘the Cloud’. Each path implies a different cost/value trade off that needs to be assessed.
For most applications it will be simple to eliminate most of the Rs as viable potential courses of action, leaving one or two to be properly considered and priced.
Who’s your head of application portfolio management?
Becomes the pertinent question. If this isn’t somebody’s job, then it’s probably nobodies’ job, and it won’t be getting done. If organisations aren’t active about this portfolio management approach then inertia will take charge of their direction.
Conclusion
Applications are an investment, and like any other investment they should be managed. A portfolio approach, and tools to evaluate trade offs and options naturally follows; and of course the process has to be iterative, because the world keeps changing. If organisations aren’t active about this, then their direction gets determined by inertia.
Notes
[1] I’ve seen IT Portfolio Management tools like Alfabet (now owned by Software AG) implemented in some organisations, but even then I’ve seen little evidence of the tools being used in a rigorous way (or having much impact on overall IT strategy).
[2] Aka the ‘drug dealer model‘
[3] With thanks to Johan Minnaar for bringing my attention to the model and my colleague Jim Miller for highlighting its ubiquity.
Filed under: technology | 6 Comments
Tags: 5 Rs, application, legacy, management, manager, portfolio
Subscribe
Recent Comments
Tim Coote on Ross Anderson RIP iain on Skiing in Espace Killy (Val… Chris Swan on Getting more from a British Ga… Murray Cowell on Getting more from a British Ga… JL on AI MacGuffin 
Pinboard.in bookmarks- Commission proposes youth mobility between EU and UK
- DEA fuels moral panic over ADHD meds to justify its failed drug war
- Meta.ai Oh My!
- Looking for AI use-cases — Benedict Evans
- the biggest threat facing your team
- Why has Hugh Grant settled his phone hacking claim against the Sun?
- Open Source Security (OpenSSF) and OpenJS Foundations Issue Alert for Social Engineering Takeovers of Open Source Projects
- AI isn't useless. But is it worth it?
- Pluralistic: The true post-cyberpunk hero is a noir forensic accountant
- Subaru battery drain due to missing 3G network
Chris Swan's Weblog 
You said, “The very reason that legacy exists is that it satisfies a business need at a price point that’s better than migrating to something new.”
You then highlight the assumption is they’ve figured this price point out, which in many cases they have not, which is why the above statement would be more accurate if written
“The very reason that legacy exists is that it satisfies a business need at a price point OR LOWER RISK that’s better than migrating to something new.”
My financial services background leads to me tending to use money and risk pretty interchangeably, so your refinement is no doubt correct for those who don’t approach the domain that way.
Most of the models I’ve seen for APM massively underestimate the missed opportunity costs and the risk costs for the legacy with organisations preferring to let the direct costs dominate.
Glad you are raising this as there is a long standing gap here. In my experience applications are too “sticky” to be traded like a portfolio of financial products even though it might seem like the underlying components are now commodities. I have been pushing ideas borrowed from product management as a better fit. More on this here: https://www.cioportfolio.co.uk/2012/05/turn-your-application-portfolio-into.html
I’d start by asking the business if they actually still need this legacy application. The clue is in the name, things will have moved on in their industry in the meantime, new applications the reflect the new ways of working will be available. It is always worth checking that our approach to supporting the business is not constraining the business.
A good example is the way that Xero and others have knocked Sage by providing agile cloud services that are more in line with the way B2C orgnisations work today.
The 5 Rs have a built in assumption that the business still needs what the application does, so there’s an implicit 6th R of Retire.
SaaS accounting like Xero replacing more traditional packaged software is a pretty clear example of Replace. The business still needs accounting, but modern software gives us a much better way of doing it (and we’ve seen the same with lots of other core functions like CRM with Salesforce, HR with Workday etc.).
Another observation that I’d make here is around customisation. Lots of legacy Accounting, CRM and HR systems tend to be highly customised, and the SaaS offerings provide some scope for customisation, but it’s usually much more limited (due to the need to support constant update of the core). It’s quite often the case that the customisation that made sense in the past is actively harmful in the present. Practices have evolved, and modern apps embody the best way of doing things learned across huge populations of users (and underpinned by a shared skills base across industry subsets). At that point being custom effectively means being wrong.
As an example one of the bravest moves I’ve ever seen in a company I worked for was to abandon all of our custom HR processes as we upgraded a legacy HR platform. Our customisations had trapped us on an implementation that eventually aged out of support, and the HR department decided that rather than (expensively) porting how they did things to the new software, we would instead change our HR processes to align with the software defaults (which embodied what was then considered to be industry best practice).