Monday, November 5, 2012

How much has been "modernized?"

This was a question posted on a linked in forum recently.

"

How much has been "modernized?"

There's been a lot of talk for at least the past 20 years that systems would be "modernized." "We're going client-server & unplugging the mainframe." Still hasn't happened. Now c/s is legacy."

My assessment would be that very, very little has been modernized. We have the world leading analysis tool for the as/400 and of our thousands of users world-wide, less than 10% have done any real modernization. Most as/400 (and this is true of mainframe applications too) are large, complex beasts that are implemented for the most part using legacy languages and legacy architecture. Converting the language is not that big a problem, and automation tools have been around for decades to do this. but largely what they do is create legacy applications in modern languages. there are some real justifications for doing that on occasion, but not to reap the benefits of a modern application architecture, and development agility. 

To get a real modern application and the modern development benefits, you have to rewrite the legacy application. The problem with this (certainly on the as/400) is that the majority of legacy developers don't have the will, time, opportunity or capability to transition their own skills let alone a 10 million line mission critical application. Some have but not enough to create a pool of resource that would make any difference. 

Modern developers and often managers don't have the knowledge or experience of the business, and even if they did, the cost of rewriting manually is prohibitive and could take many, many years, and hugely risky. 

So the result is kicking the can down the road being the most prevalent attitude i see worldwide. Not that some management aren't interested in doing something, they just haven't had the means or method. 

To change this, automation is the only answer. Not automation by code conversion or even intelligent code conversion to produce neater legacy code in a modern language. Automation of reusable design recovery, complete transformation of the architecture and rewrite of the code. The drivers must be developers with a modern perspective, not legacy developers with modern skills, but a legacy perspective. so it should be a "harvest what we can from the legacy " rather than carefully preserving legacy in a modern language. The three aspects of automation that are required to effect this radical change are:

- Automation of complete system design recovery reusable designs/rules/models 
- Automated Transformation of architecture 
- Automated Generation of code 


The most productive part of automation is design recovery. It is also the part that has achieved the highest degree of automation(with our tools anyway). If functionally delivered in the correct way (graphical, interactive, drill down, models, flows, exports to UML/XML/DDL) it also solves another big inhibitor to modernization: putting the power of knowledge in the hands of new developers and management, and often legacy developers too (finally they can articulate what they have been doing for the last 25 years). 

Subsequent automation of transformation and code generation provides varying degrees of automation and cost benefits. But even modest levels of 50% can save 10’s of millions of dollars and years of risky effort. Projects done with our tooling have already delivered 80-95% automation of a manual rewrite. 

Most significantly we are seeing a release of pent-up frustration by companies who know the problem, know how it could be solved but couldn't find a technology that could deliver the solution with any real automation. 

I don’t believe that this will change the mentality of the many can kickers, who just want to see out their retirement in peace. It does mean that new and future developers/managers can harvest the value in their legacy systems, once the old guard has stepped down.