I recently wrote about the Digital Transformation gap – a reckoning that we have been under-investing in our legacy systems, and that we need to stop “kicking the can down the road” putting more focus into adequately dealing with our legacy estate. In this article, I wanted to share further thoughts on some of the main blockers that I see, and how we can overcome them
Answer: All we need is some “TIME”.
This Gartner acronym and model goes back years, and stands for Tolerate, Invest, Migrate and Eliminate. The premise being a typical quadrant model, measuring business value on one axis and technical condition on the other. The more critical the application is and the better the condition, the more justification you have to invest in it. The weaker the condition and less critical the importance, then you should eliminate it. For everything else, you should either tolerate it (it’s not broken, don’t fix it), or migrate it – it’s flakey, but you need it.
I have mixed feelings about the use of quadrants. They tend to over-simplify the situation at hand, and every legacy system has a specific history and context. However, if you are assessing a large legacy estate, these can be useful to help organise your plans and teams, and communicate to management. As an alternative, I would recommend using a technology-driven categorisation approach. Assuming business-critical systems are already distinct and in plan, you can then spend time with business users to assess what opportunities you have for retiring systems. You then have the middle ground leftover to assess for infrastructure and software risks. Your go-to solution can be to re-platform to address some of these, and then you’re left with a potential long-tail of investment decisions.
Answer: Get tooled up.
A good place to begin is with a list of your assets. Whether you work top-down from business service down to infrastructure, or bottom-up, from a datacentre floor walk audit, up to business service, this is a big undertaking. However mature your Configuration Management Database (CMDB) and change management function is, you can be sure investing some time in understanding your estate will help you later on. Comprehensive audits are not an easy exercise and can be prone to error. Prepare yourself to engage with all IT and business teams, and figure out how best to store the data so you can handle change and ambiguity.
If you don’t have a mature CMDB, I would recommend using some tooling to help you build your audit and effectively, a lightweight CMDB. I’m not a fan of agent-based discovery tools (think unmanaged blind-spots), so thankfully there are several IT Ops or Security vendors out there trying to help enterprises solve this. For example, in the past, I’ve had presentations from vendors such as Tanium (https://www.tanium.com), whose agents cascade into the corners of the network to try and discover unmanaged devices. Also, on a more recent trip to Israel, I recently visited a start-up called Armis (https://armis.com). They have a passive network scanning solution designed to discover all devices, including the ‘unagentable’!
Answer: Get real. You need to eliminate what you possibly can.
Have you ever had a proper conversation with the business users about the low hanging fruit? Putting a monetary value on the overheads of maintaining these systems, against the business function they support can be an illuminating experience – both ways. Have you analysed in detail the use of the system, as you may find the business users don’t know the alternatives and can employ a workaround, or that another system can do something similar with a small amount of change? We recently achieved a massive percentage reduction in the legacy estate by properly engaging with the business – this should be your first port of call and will help you build some momentum.
Answer: Start starting.
Whether you have the deadline of an impending Datacentre exit, or if you’re creating a multi-year business case for investment, you’re going to need to analyse the data you’ve collected to get a full plan and costs. If the retirement of the low hanging fruit wasn’t enough to get your CFO excited, then you need to find a way of costing the overall programme which allows you to start execution as fast as possible. Agile doesn’t just apply to software development. If you spend six months figuring out your full plans before starting to execute, the goalposts will have moved.
How about building two core teams for your programme? A command and control function, managing the overall plan, management engagement, audit and data responsibilities – performing the initial system analysis and categorisation, and a “full-stack” or multi-disciplined engineering team, receiving a backlog of system change and migrations. As the analysis matures and the backlog builds, you can merge the teams, or ramp one down to grow the other. Your business case needs to be sufficient to get the initial execution underway, and then you will be able to provide a fuller picture once the team has some execution under it’s belt and the systems analysis becomes more mature.
And one last thing – what about Cloud compute?
Wha…? While I expect there will be fewer legacy systems lurking in someone else’s datacentre, there’s going to be potential shadow IT, or redundant unmaintained systems sat out in the Cloud. Have you got control of these? Do you know where they are and who commissioned them!
This is not an exhaustive set of blockers as I’m sure you’ll agree. Hopefully, you have a new Cloud-first, evergreen Target Operating Model for new systems so that we won’t be back here again next year!