You got to know when to hold ‘em
Know when to fold ‘em
Know when to walk away
Know when to run
- Kenny Rogers
Today I am going to write something simply useful. And I might get in trouble for this, when the execs realize that I’m telling you how to do most of an SMR, a service that we charge for. Anyway here we go – let me set the scene.
At the Crossroads of Modernization
There comes a time in the life of every CIO and IT Manager when they realize that they have a bunch of legacy software applications, and they have a nagging suspicion that they need to do something about it. Often in this moment of truth, after a few rough nights dreaming of exploding mainframes and those horrible “bombshell” meeting when your outsource partner tells you it’s going to be much more expensive than they thought to add a trivial but time-critical enhancement, the CIO will hire an outside consultancy firm to conduct a big study that explains all the various options for modernization, the pros and cons of each, and to create a multi-year modernization roadmap in all its gory complexity.
So I think I can save you some big bucks here, because it’s not rocket science folks! Spend ten minutes running your legacy application portfolio through the following decision tree, and you will be most of the way to a roadmap.
When To Do Nothing
Ah, everyone’s favorite solution! You can do nothing if you still have time to react if something goes wrong. Keep in mind that doing something can be a multi-year process, so the decision to do nothing requires some considerable foresight. The litmus test for this one is simple: are you sleeping well?
When To Kill It
“Retire” is the euphemism here, but your system will not be heading off to the beach to read paperbacks, it will be gone. And good riddance, because if it fits into this category, it was just sucking up your money and giving nothing back. Freeloader.
When To Rehost It
Do this if the mainframe is the real problem, and you just need the same system, in the same language, running on a cheaper box. And even if the system itself is a nightmare, at least you’re not making it any worse. So you can solve your short-term mainframe problem, and deal with the more difficult software issue later.
When To Wrap It
Wrap or “SOA-Enable” your system if the biggest problem is integration. This can extend the life of your system by allowing other things to talk to it. Of course, you’re not getting rid of the system itself, so if the legacy system is a problem, it’s a problem you still have. And it’s also pretty clear that you have increased the complexity of the overall system, and introduced dependencies between the legacy system and the rest of your infrastructure. So it’s not a good way to address issues of complexity, maintenance cost, etc.
When To Port It
You port a system to a new language if the language is the issue. I think of porting like a meat-grinder – you take your old source code, run it through the meat-grinder, and you get the same system in a new language out the other end. Warts and all. You can’t make any material changes to the structure or design of the application, but at least you can get rid of your aging, expensive COBOL or PL/1 programmers and replace them with fresh college recruits.
Except they will all hate you afterwards. The guys you fired will hate you for firing them, and the new Java programmers will hate you for making them work on a Java system that looks like COBOL. Most of them would rather push bamboo under their fingernails. Pay them well, ’cause they won’t be sticking around because of the sexy tech.
When To Rearchitect It
This is what you do when the legacy system is in a sorry state, but still runs your business and has a lot of value buried deep inside. You want the baby, but no bathwater, thank you very much. This may be the most ambitious of the alternatives, but in many cases it’s the only one that gets you what you want out the other end – a nice looking system that doesn’t reflect the pathology of the legacy system it’s replacing.
With a proper rearchitecture, you can get a brand-new, relational data model, a modern tiered architecture, you can decompose the system into SOA-enabled components, you can revise the screens and the use cases to meet new business requirements, you can convert from batch-orientation to a real-time paradigm, you can choose a great new platform and a new architecture that can even include one or more off-the-shelf components, and you can do all that more cheaply and with far less risk if you leverage the legacy system rather than starting from scratch.
As you can see, for many organizations, rearchitecture is the Holy Grail of modernization. And it really hasn’t been possible until very recently, so you can forgive yourself for not knowing.
Conclusion
So now you are equipped to write a roadmap! We’ve written lots of them, and it’s mostly common sense. But let us know if you need any help.
- Tom Metzger
