Blogs
Highlights
Categories
Tags
AI Alignment Apple application management apps Archimate Atos Themes Big Data bionic computing Changing Customer Cloud cloud computing Collaboration Connected World Current Affairs data downturn Education enterprise architecture Facebook generation y Google ideas information security Innovation Java Knowledge and Craftmanship Linux media Microsoft mobile New ways of working open innovation open source Oracle Practical recession Research SaaS Security semantic web social media Social networking The Future! Transformation trust Twitter virtualisation web Working in IT
A sharp kick in the assets
August 17th, 2009 Atos Blog Tags: .Net, architecture, COBOL, legacy, Linux, REST, Visual Basic
Posted in Technology |
It’s coming to something now that even Visual Basic 6 is considered as a legacy – all those little VB Client:Server apps that have grown up in your organisation that are now business critical systems (of course) are now out of date. You can still compile your old VB6 apps under .Net using the -Deprecated compiler switch, but Dahlings, it’s just soooo last century!
So the conundrum – What to do with your Legacy systems now that money’s too tight to mention? There are various strategies for re-invigorating your legacy systems without resorting to a total rewrite. Here’s a selection:
Re-platforming
A useful strategy for addressing those old COBOL systems on unsupportable or niche hardware. The Lift & Shift solution offered by Microfocus and partners is a viable approach. Though one word of caution – it’s no accident that Microfocus have been busy buying most of the Unix/Windows COBOL compilers. There isn’t much competition these days, and it can get expensive with COBOL Application Servers and what have you. There are still alternatives however, most notably Fujitsu NetCOBOL. If you’re feeling that your COBOL will be around for a while yet, and you have a desire to be self-sufficient then it may be worth considering OpenCOBOL, an Open Source COBOL preprocessor that generates C code for native compilation. It’s available on Windows Server, Unix/Linux and Mac OS – though relational database support isn’t that easy.
Conversion
This really only makes sense if you use automated tools. There are many suppliers who can help you covering most (formerly) mainstream technologies such as RPG, VB6, Oracle Forms, LINC and Cobol. At the end of a conversion you would end up with a system on a Unix/Linux, or Windows platform, web based front-end and likely using a SQL database of some sort. Some tools and suppliers do a more future-proofed job at conversion than others and often it is unavoidable in order to have a working system, even if somewhat of an odd-ball from a support perspective.
You may be left with an application converted to C#/.Net or Java that feels familiar and comfy to the original support team – meaning old skool sequential style programming - but that would be pretty alien to an experienced Object Oriented developer. This could then form the basis for an ongoing Re-Factoring project, but you would no longer have a burning legacy platform issue. Whilst from a purist point of view some may think this is not a perfect solution, it does have the not inconsiderable benefit of bringing forward and developing current staff at the same time. The important thing to avoid is licenced migration software libraries – the gift that keeps on giving to the library vendor!
Install replacement windows
A good thing to do to keep your house warm and extend its life. Older Client:Server applications can generate a much longer useful life by replacing the desktop client end of things with a browser based front end. Vista and Windows 7 seem to be very good at breaking older 16bit client application elements, so stick with the back end systems and their embedded SQL business logic (for now), but address the client end of things. PHP and Ruby On Rails offer very productive tools, and come with a lot of pre-built features to connect back-end logic too – it is likely that with a smaller footprint on the desktop and over the network some performance benefits should be expected.
Give it a REST
As in re-purpose your legacy application for REST architecture – this will make integration significantly easier in the long term, and will also help unlock the benefits of your legacy application. For example re-purpose that complex, multi-phase, transaction that updates a large entity to allow CRUD (Create, Read, Update, Delete) stateless operations on a single entity. The benefits of this approach mean that you can easily offer these atomic operations as Tuxedo/CICS transactions, MQ/Tibco/JMS messages, web services, or whatever.
There’s many ways in which you can get more use and/or extend the life of existing systems, and in these cost conscious times you need to ask yourself as a conscientious CIO:
“Are my existing assets being sweated enough, or do I need to give them a swift kick?”
Totally agree that code Re-Factoring as part of an overall Applications Mining strategy (once burning platform legacy issues have been addressed).
Perhaps a further – and cheap option – is to look at the code and actually see what it is or isn’t doing (that is, if you have access to it!). Many legacy apps, probably written many years ago, may be performing inefficiently due to old coding techniques that could do with a good spring clean. Of course in many cases that might be a kind way of saying the apps were just coded badly. Compilers, database access, patterns, best practices, levels of usage, volumes, object libraries etc. have all moved on, yet the code may be gathering dust in the last decade. A good example of this is a recent tweak (20 lines) and re-compile of some vb6 code that improved the creation and formatting of a WORD report from up to 5 minutes to less than 10 seconds. Perhaps it’s time to get the duster out of the drawer and shine up all that old code?