If you can accept the idea of a Software Architect the idea of a maintenance architect makes sense. However, in the circles I travel in there is actually some resistance to the idea of a software architect at all.
This resistance is usually driven by a misrepresentation of what the role should be. An architect role should be a mentor and guiding hand in the business' technology related initiatives. The architect should not be about the business of "bossing around" developers.
The Maintenance Architect role makes perfect sense if you look at what the job would be involved in doing. Even in the absence of a Software Architect a Maintenance Architect could still make sense. The Maintenance Architect would basically herd all the "cats" (developers) in a direction. The M.A. would steer a Perl shop (for example) toward exposing their CGI as distinct REST services that could then be fronted with Flex for example. In time you could whittle away at the CGI with Grails applications or another technology that fit your new technical stack. Eventually after a great number of iterations you would be transitioned to the new technology. You would "cook the lobster" if you will... slowly transitioning the shop to one of the 21st century software stacks.
It would be a long sighted goal and it would take a long sighted person to pull that off. The guy you'd look for would be someone with patience, endurance, and commitment. They would have to be a stern guiding hand yet be flexible enough to wait out the many development cycles to see their plan fulfilled. Not an easy order to fill and not a common person to find.
