Some of you may be asking "why is APM relevant?". What has application portfolio management got to do with COBOL? And how does it relate to everything else I've read on this blog?
Let me connect the dots. (forgive me if I wander a bit *smile*)
To many folks, COBOL is "old code" that has got to go. The reasons many provide usually have something to do with the user interface or the data, but not the core functionality these applications provide. Those using the applications on a daily basis hate the old character interfaces. This is thanks to the fact that everything else they use has a slick web interface and they can generate their own adhoc reports without waiting for weeks or months for IT to get around to it.
To quote a CIO I spoke with recently "Users hate using the character screens but we couldn't do business without the functionality the systems provide". He also had issues with the data. Since everything was "locked" into the applications, they had to create a data warehouse which replicated the various information and made it more accessible to the business users.
He really really really would like to do something with the applications, but he didn't buy into the "let's rewrite it in (your language here)" pitch. This is due to the fact that he realizes those applications are very complex and rewriting them introduces unacceptable risk. If he understood how these applications worked, he might be able to do something with them.
I saw another example of this today while visiting one of the largest insurance companies in America. One team within the company was tasked with trimming $100 Million out of the company's operation budget. To do so, they started asking questions about their mainframe-based COBOL applications. What they found was that no one understood everything these applications did. Nor did they know how interwoven the various applications were with the rest of their infrastructure. Sure they knew pieces and parts, but no one had the big picture.
Just to make sure you didn't miss my point, no one in this multi-billion dollar company understands how their systems work or what they consist of.
And we are talking a company with literally hundreds of architects, project managers, application developers, etc. Even those who have been with the company 30 years only knew what parts of the various application elements did or were comprised of. And these folks are making multi-million dollar decisions based on what they know about their systems every day!
Yikes!
I've digressed a bit, but hang in there, I can draw it all together. I think... *wink*
How would both of my examples solve their problems? APM.
With an APM-type solution, that old code becomes a reusable building block for the new applications your company needs. By using an APM solution to gain an understanding of the application and its composition, you could then take that "old COBOL code" and re-purpose it with a new user interface or by opening up the data layer.
With an APM solution, companies can see how to reduce their IT expenses by identifying dead application elements, unnecessary application complexity, duplicate functionality and data. APM-based solutions can provide management a real-time picture of these systems. Who knows, they might even realize how risky a complete rewrite to (your language here) really is.
Recall the earlier posts on Visual COBOL? (see how I wove that in there? slick huh?)
Once you have identified those pieces which are key to the business, you could use a tool like Micro Focus Visual COBOL to create a COBOL-based web service. Then those who are building the new user interfaces could use whatever language they want to build that slick new user interface. And by doing so, COBOL continues to have a place in the environment.
Or what about the post on migration? (yes that was another post I made) With an APM solution, you can identify what pieces of an application can be moved off the mainframe to a Windows or UNIX or Linux server.
So, back to my point. I believe that APM-based technologies are critical to the future of COBOL.
They can give new life to those COBOL systems...
That's my thinking anyways. What's yours?
-
Posts
One interesting effect of this is that it reduces the attractiveness of re-writing. One of the reasons people go for re-writes is that they are scared of the current system because they do not understand it. Also, they don't realise how complex the current system in (because they don't understand it) and so under-estimate the cost of re-write.
ReplyDeleteWith good analysis via approaches like APM, the current system will become less scary but more importantly - its value in IP will become clearer and the cost of re-write will become starkly obvious.
Surely, it is better to analyse what you have really well before you try to re-write it? It goes to one key phrase by which I lead my technical life:
"You think architecture is expensive? Try chaos."
This applies to APM
"You think APM is expensive? Try ignorance."
By now, almost every major corporations running their code on legacy systems must have understood that over all rewrite is out of question. Options that are more sensisble are
ReplyDeletea) rewrite small subsystems. But the problem is the sub system may not seamlessly integrate with the rest of the system. Also there are not many susbsystems that are small but critical enough to consider for such phased approach to make sense.
b) Re-architect the existing code into well defined data layer and user interface, in the process demystifying (documenting) the functionality of the large chunks of code and also optimising (removing duplicate functionalities and physical and logical dead code) the code that has evolved over decades of changes.