As an architect you’re often get placed in uncomfortable situations. One of such scenarios is facing the architect of a working system that you’re tasked with replacing.
In this scenario your organization has an existing legacy system that still does a decent job of supporting the current needs of the business. The executives funded your project, because the legacy system cannot support the evolving business needs. You’re up to a real challenge. By definition your project will bring change into organization and any change will cause friction. On top of that you’re working against a benchmark – legacy system provided many years of reliable support. On top of that there may be people who have a high stake in maintaining the legacy system no matter what executives think.
Even if you’re an expert in your business domain it’s inevitable (and logical) that you’ll interact with an architect of the legacy system – who happens to have 20 years of experience with organization. Based on what the legacy system architect knows he doesn’t see the need for a paradigm shift that your solution will bring. What to do?
One approach is to involve the legacy architect with your project. The involvement can be kept at a high level; acknowledge the success of the retiring system and ask the legacy system architect to contribute to system requirements of the new system. A good question to ask: “What are the items on your [legacy system] wish list that could not be achieved due to hardware (e.g. mainframe) or software (e.g. COBOL) limitations?” Work with the legacy system architect to show how technology used for the new system will retain the essence of the retiring solution and allow for suggested improvements.
The key to your success is winning over the key stakeholders of the retiring system through diplomacy. Remember that “Diplomacy is the art of letting someone else have your way.”