Someone Shot Legacy IT But No One Died
We’re a very lucky bunch of people at 3wks. We get to break the traditional software development mould every day. Our team builds apps and large digital open source solutions, often integrated to or replacing legacy IT systems.
When we start a project we ask three questions:
- What’s the first problem we are going to fix?
- What’s the outcome we’ll deliver, in a few weeks?
- Where are the users we can work with — day-one and throughout?
Then we start writing software code.
Each of these questions in and of themselves seem pretty innocuous and simple, but you’d be surprised how often they put the fear of God into the minds of IT departments. Why is this?
We all have natural inclination to play it safe. Doing anything outside our comfort zone is challenging. If, like so many in IT, you’ve grown up in a world of legacy systems, old school development methods and a culture of risk aversion, simplifying a project brief to three simple questions doesn’t sit well.
Expecting the answers to these questions to be a dependable and safe outcome for delivering a successful project seems borderline insane.
Legacy IT compound cost
In her recent article in CIO magazine, The Keys to Modernizing Legacy IT Systems, Mary Pratt describes how legacy IT costs rise stifling innovation because of the complexity of changing and supporting old systems:
“Companies should anticipate compounding costs when it comes to legacy systems. Legacy systems hinder productivity and innovation; that’s the first cost. Then comes the continuing cost of maintaining them, which takes increasing amounts of the IT budget away from more worthwhile investments like those for differentiating and innovative technologies.”
Trying to innovate when this happens is near on impossible.
Adapt or Die
As Mary Pratt’s article goes on to quote “Time and time again you have organizations try to go through digital transformation exercises and they’re failing because they’re relying on outdated systems, models, and team compositions. They’re trying to get into the new world with the outdated model,”
Training and acquiring specialist skills are essential to give traditional IT people the confidence and competence to engage in the new digital innovation world. Adapting to a new paradigm might just be a matter of survival.
After 3wks had spent over a year delivering a dozen super-fast agile projects using our own unique method — Beyond Agile — we were asked the question: “ Why can’t we do what you do?” The simple fact was they not only needed to acquire new skills and competencies but they also needed a radical rethink of the IT departments operating model. Changing both was tricky to say the least, but they’re well down the track.
So making the decision to seek an alternative to legacy systems is a non-trivial task. But is it worth the effort?
In one case recently, we were asked to deliver a digital solution where previous attempts with an enterprise platform had failed twice, costing several $m. Why the successive failures?
Well the enterprise platform approach was to try and scope the end-to-end solution for every possible use case — up front. Big mistake. A) the likelihood that all use cases were necessary and valid was zero, and B) by the time they started coding up the solution users needs had changed. So by the time the enterprise platform team were ready to release a product to users, they no longer needed half the functionality originally captured upfront. Three years of effort for no return.
The digital solution we were asked to develop was iterative, working with users throughout and incrementally rolled out through the entire 20 months of the project. No waste. No redundant features. Just working software. One observer described it as: ‘As if we’d shot legacy IT but no one died’. In other words , a working solution which integrated to core legacy platforms — but didn’t replace them.
Digital technologies are getting a foothold in traditional IT but there will always be a place for aspects of legacy systems. The trick is to know which bits are worth keeping and which are not. Thinking in terms of total cost of ownership and whether you’re compounding cost and complexity are a great start point.