Offshore Architects, Legacy maintenance and modernization
I was reflecting on the nature of engagements that some of our teams undertake, more because of the fact that the engagements mirror the portfolio owned by CIOs, essentially trends in typical IT shops and it is a no-brainer: a larger percentage of work involves maintenance and sustenance of IT systems. [ref: Software maintenance - who's interested?]
The challenge in such (application maintenance management) scenarios is not in the intricacy of work but the fact that it is not seen as sexy or cool by many developers, and software engineers, and even less so by most software architects. The reason is obvious: the industry has glamorized new development as being ‘creative’ while labeling maintenance to an equivalent of ‘grunt work.’ Given this mindset, it wouldn’t make sense for me to even attempt making an argument for why architects should get more involved in ‘legacy’ work but here it goes anyways.
Industry analysts are always talking about volume of maintenance work in the IT industry, more specifically impact of such volumes on the growth to services companies. If there is a lot of work to be done and fewer experts to do it, the law of demand-and-supply will ensure career mobility.
There are several technology challenges across industry verticals and organizations waiting for inputs from good technologists. For instance, an engagement that an architect in my team is working on involves analyzing mainframe Batch job flows and recommending the (obvious) flaws, drawing on the best practices that we (Infosys) have seen elsewhere. In this instance, there is no motivation or appetite for ‘legacy modernization,’ which means the architect has an opportunity to explore optimization techniques (possibly using the same 'legacy' technology)
Another similar issue I see client leaders talk about is the high MIPS usage and opportunities to optimize it. The reasoning is simple: the knowhow to measure MIPS utilization on mainframes exists, and what can be measured can be improved. Here the reasoning is more geared towards optimization rather than legacy modernization (say, migrating MIPS consuming mainframe applications to other platforms: Java, LAMP or Microsoft).
In a sense, it boil down to examining the basics of the given architecture and platform, and examining opportunities to improve rather than re-architect. Which brings us to an interesting opportunity shaping up in the industry: if many in the industry are predicting a resurgence in demand for COBOL programmers [eg. COBOL Today and Tomorrow], surely there is a case to be made for the resurgence in demand for mainframe applications architects?
