Derek Britton’s last blog looked at the appetite for change in IT. This time, he looks at real-world tactics for implementing large-scale change, and assesses the risks involved.
In my recent blog I drew upon overwhelming market evidence to conclude that today’s IT leadership faces unprecedented demand for change in an age of bewildering complexity. That “change”, however, can arrive in many shapes and forms, and the choice of strategy may differ according to a whole range of criteria – technical investments to date, available skills, organizational strategy, customer preference, marketing strategy, cost of implementation, and many more besides. This blog explores and contrasts a couple of the options IT leaders have.
Ever felt like just starting over? The difficulty of changing complex back-end IT systems, when staffing is so tight, where the pressure to change is so high, with an ever-growing backlog – there is point at which the temptation to swap out the hulking, seething old system with something new, functional and modern, will arrive.
Sizing Up the Task
We’re sometimes asked by senior managers in enterprise development shops, how they should assess whether to rewrite or replace a system versus keeping it going and modernizing it. They sense there is danger in replacing the current system, but can’t quantify to other stakeholders why what is.
Of course, it is impossible to give a simple answer for every case, but there are some very common pitfalls in embarking on a major system overhaul. These can include:
- High Risk and High Cost involved
- Lost business opportunity while embarking on this project
- Little ‘new’ value in what is fundamentally a replacement activity
This sounds a rather unpleasant list. Not only is it unpleasant, but the ramifications in the industry are all too stark. These are just a few randomly-selected examples of high profile “project failures” where major organizations have attempted a major IT overhaul project.
- State of Washington pulled the plug on their $40M LAMP project. It was six times more expensive than original system
- HCA ended their MARS project, taking a $110M-$130M charge as a result
- State of California abandoned a $2 billion court management system (a five-year, $27 million plan to develop a system for keeping track of the state’s 31 million drivers’ licenses and 38 million vehicle registrations)
- The U.S. Navy spent $1 Billion on a failed ERP project
OK, so there have been some high-profile mistakes. But might they be merely the exception rather than the rule? Another source of truth are those who spend their time following and reporting on the IT industry. And two such organizations, Gartner and Standish, have reported more than one about the frequency of failed overhaul projects. A variety of studies over the years keeps coming back to the risks involved. Anything up to a 70% failure is cited in analyst studies when talking about rewriting core systems.
Building a case for a rewrite
Either way, many IT leaders will want specific projections for their own business, not abstract or vague examples from elsewhere.
Using as an example a rewrite project – where in this case a new system is built from scratch, by hand (as opposed to automatically generated) in another language such as Java. Let’s allow some improvement in performance because we’re using a new, modern tool to build the new system (by the way, COBOL works in this modern environment too, but let’s just ignore that for now).
Let’s calculate the cost – conceptually
Rewrite Cost = (application size) x (80% efficiency from modern frameworks) x (developer cost per day) / speed of writing
The constants being used in this case were as follows –
- The size of the application, a very modest system, was roughly 2 Million lines of code, written in COBOL
- The per-day developer cost was $410/day
- The assumed throughput of building new applications was estimated at 100 lines of code per day, which is a very generous daily rate.
Calculated, this is a cost of $6.5M. Or, in days’ effort, about 16,000.
Considerations worth stating:
- This is purely to build the new application. Not to test it in any way. You would need, of course, rigorous QA and end-user acceptance testing.
- This is purely to pay for this rewrite. In 10 years when this system gets outmoded, or the appetite for another technology is high, or if there are concerns over IT skills, do you earmark similar budget?
- This assumes a lot about whether the new application could replicate the very unique business rules captured in the COBOL code – but which are unlikely to be well understood or documented today.
A well-trodden path to modernization
Another client, one of the world’s largest retailers, looked at a variety of options for change, among them modernizing, and rewriting. They concluded the rewrite would be at least 4 times more expensive to build, and would take 7 or 8 times longer to deliver, than modernizing what they had. They opted to modernize.
Elsewhere, other clients have drawn the same conclusions.
“Because of the flexibility and choice within [Micro Focus] COBOL, we were able to realize an eight month ROI on this project – which allowed us to go to market much faster than planned.”
— Mauro Cancellieri, Manager. Ramao Calcados
“Some of our competitors have written their applications in Java, and they’ve proven not to be as stable, fast or scalable as our systems. Our COBOL-based [banking solution] however, has proved very robust under high workloads and deliver a speed that can’t be matched by Java applications.”
— Dean Mathieson, Product Development Manager, FNS / TCS
Core business systems define the organization; they – in many cases – are the organization. The applications that provide mortgage decisions, make insurance calculations, confirm holiday bookings, manage the production lines at car manufacturers, process and track parcel deliveries, they offer priceless value. Protecting their value and embracing the future needs a pragmatic, low-risk approach that leverages the valued IT assets that already work, delivers innovation and an ROI faster than other approaches, and is considerably less expensive.
If you are looking at IT strategic change, talk to us, and we’d love to discuss our approach.
 We can’t speculate on the costs involved with package replacement projects – it wouldn’t be fair for us to estimate the price of an ERP or CRM package, for example.