Fund systems, not monoliths
Don’t replace the old legacy system with a new legacy system. Insist on loosely coupled systems that are built incrementally. That way, they’ll never need to be replaced wholesale — they’ll just replace individual components as the need arises.
Checklist
- Each contract will be written to deliver value to end users — they’re not for "maintaining servers" or "setting up a database," but for "adding a web-based permit application system" or "simplifying the intake process"
- There will be no single "enterprise architect," because the architecture will emerge iteratively throughout the agile process
- If the project is large enough that it will include multiple scrum teams working simultaneously, there is no expectation that all members of all teams will ever be in meetings together
- The RFP will specify the use of service-oriented architecture for each component
Key questions
- Is there a single point of failure that can bring the whole system down? (If so, that’s probably a monolith, not a system.)
- If one vendor’s contract needs to be terminated for non-performance, can the others continue to work without interruption?