Here in California, most legacy modernization state government projects follow this pattern:
A state team is tasked with constructing an RFP. The RFP will include all known requirements, is set as a “fixed price” contract with a price tag that can range from $200M to $1B.
OK, so we are 2-3 yrs into the process. No working software has been built.
So what’s changing in legacy modernization that might improve this?
Small teams can be hired to build working software that both the state and vendor teams can learn from. Following an “encapsulate and retire” pattern, teams can identify small chunks of relatively self-contained functionality from a legacy system, duplicate an improved version of it on a modern platform, and migrate users off of that piece of the legacy.
(As a side note, I’m calling this pattern “encapsulate and retire”. Its really the strangler pattern, but when you are working with the folks who have lived with the legacy software for years, talking about strangling the system they have cared for is macabre, borderline insensitive.)
The agile process is a big help here. The normal benefits of helping analysts and developers learn more about the domain occurs via the agile “working software” feedback loop. But a secondary, more subtle benefit is that it helps legacy users and managers move along the OCM curve quickly. When they see working software, the fears of change are balanced with the opportunities to control the new direction. Adoption occurs with less difficulty.
In Part 2 (coming soon), I’ll discuss the impacts of cloud, devops, and open source as new opportunities to revolutionize the legacy modernization process.