Original URL: https://www.theregister.com/2006/05/04/legacy_bullet/
Biting the legacy bullet
Sometimes you have to call time
Posted in Channel, 4th May 2006 06:43 GMT
Developments in the areas of XML-based web services standards, middleware technology and portal frameworks have provided lots of possibilities for extending the life of legacy systems such as old mainframe, AS/400 and first generation UNIX applications. We can now wrap these up in a standard access layer, re-label them “heritage” solutions, and look forward to squeezing another decade of service out of them.
This approach can work well, potentially addressing some of the common problems associated with legacy systems that were confirmed during a recent Freeform Dynamics poll of 100 UK-based IT Managers (Figure 1).
However, while wrapping older applications in web services-based interfaces might ease some pain in the areas of systems integration and the user experience, it doesn’t particularly help with the growing challenge of maintaining legacy skills or the availability of ongoing support from suppliers, both of which are highlighted as problems anticipated over the coming three years. Perhaps more significantly, tactical measures to extend the life of legacy systems can in many cases perpetuate the problem of inflexibility that is hampering responsiveness to business change. You can wrapper an old monolithic COBOL program that has been modified repeatedly over a quarter of a century as much as you like, but it isn’t going to change the rigidity of what’s under the covers.
Deciding what to do with legacy applications is clearly something upon which it is impossible to generalise. Some applications may be archaic, but if they perform a relatively static function that is unlikely to change in the foreseeable future and they still work well, there is a good case for leaving them alone rather than incurring the disruption, risk and cost of replacing them. But accumulate enough of these, as many organisations have done over the years, and the combined impact in terms of cost and business drag can be considerable. Of course the worst case scenario is continued reliance on an inflexible legacy application for a core business function that is dynamic in nature.
As organisations work through these considerations, they each come up with different strategies (Figure 2).
As we can see, some elect to clean up peripheral applications, the motive typically being to get them onto more cost effective platforms. Others elect to focus on core business systems; the rationale for replacement here usually being a combination of reducing risk and cost while simultaneously boosting flexibility. We then have those who say their aim is to replace all legacy systems over time, which is actually the largest group.
When looking at this picture, the most significant conclusion we can draw is that many organisations are calling time on legacy systems and are looking to be proactive rather than reactive in replacing them. That’s not to say, of course, that replacement will happen overnight, but it is nevertheless an indicator that modern businesses increasingly see the need for modern solutions to enable them to operate and compete effectively in today’s dynamic markets.
We recently came across an interesting example of this principle in action, which encapsulates many of the considerations we have been discussing. De-regulation and other changes in the utilities marketplace have forced players that were previously able to plod along happily doing the same things for years to become a lot more dynamic. In this kind of environment, the inflexibility of legacy systems comes into sharp focus, which is exactly what happened with Yorkshire Water, one of the utility companies operating in the North of England.
In Yorkshire Water’s case, specific challenges existed with its billing system – a 3270 COBOL/QSAM-based application originally written 25 years ago and running on an ICL NOVA 450-11 mainframe. This had a strong batch bias and while it worked fine for the traditional rates based and meter based annual billing approach, it was struggling to keep up with changing demands as the industry was moving towards more flexible electronic payment mechanisms and the provision of customer self-service across a variety of channels – the Web and IVR today, with mobile devices and digital TV looking to the future. Although not explicitly mentioned by the company, we can also guess that keeping options open in terms of expanding the service portfolio beyond the delivery of just water was also a consideration.
Yorkshire Water ultimately opted to move its billing system from the mainframe to a Microsoft .NET-based platform running on HP/Compaq kit – specifically a couple of dual processor DL380’s for the front-end and two 4 way DL760’s for the SQL Server 2000 database back-end. Even with the storage area network, the cost and spec of the equipment was relatively modest compared to the old mainframe world. More importantly, though, the move represented the freeing up of a previously legacy locked function which was holding back the evolution of the business.
This kind of move underlines something that’s quite important from a technology market evolution perspective. Organisations have been moving applications off mainframes for a long time, but conventional wisdom has been that the target for these should be other systems that are perceived as being “high end”, which has typically translated to proprietary UNIX boxes running Oracle. The thought of moving a mainframe application to a Microsoft platform would just not occur to many people.
The reality is that advances in both hardware and software capability are now making phrases such as “mainframe class” less meaningful, whether used in the context of a requirement (i.e. the nature of an application) or a capability (e.g. the attributes of a platform). This is another factor, in addition to flexibility and skills related drivers, which has shifted the cost/benefit equation towards replacement or migration for many more legacy applications in recent years.
Again, we need to be realistic, and we do not anticipate huge Telco’s shifting their billing systems off the mainframe in a hurry, for example. But the Yorkshire Water billing system is typical of many mid-range applications that sit there in legacy environments with decades old business processes and IT practices baked into them, that people erroneously assume need to stay that way. Apart from the coming of age of Microsoft platforms, the IBM mainframe has evolved to the modern zSeries and the AS/400 to the equally up to date iSeries. We then have the emergence of Linux blade platforms and the commoditisation of much of the technology in the storage arena.
Not surprising then that so many more organisations are now getting proactive about legacy replacement in parallel with their web services wrapping initiatives. It’s still not a trivial activity, but it’s nowhere near as big a deal as it used to be. ®