Intent Evaluate the risk of migrating to a new target solution by building a prototype.
How do you know if your ideas for the new target system will work?
This problem is difficult because:
- It is risky to make radical changes to a working system.
- It can be hard to anticipate how design changes will impact existing functionality.
- A solution that works is more believable than one that one that has not been tested.
Yet, solving this problem is feasible because:
- You don’t need to reengineer the whole legacy system to test the new ideas.
Develop a prototype of the new concept and evaluate it with respect to the new, emerging requirements.
- Identify the biggest technical risks for your reengineering project. Typically they will concern things like:
- choice of a new system architecture
- migration of legacy data to new system
- adequate performance — or performance gains — with new technology or platform (for example, demonstrating that a certain transaction throughput can be achieved)
- Decide whether to implement an exploratory (i.e., throwaway) prototype that will service purely to evaluate the feasibility of a technical option, or rather an evolutionary prototype that will eventually evolve into the new target system.
- An exploratory prototype must be designed to answer very precise questions. These may be purely technical questions, such as whether the new platform can meet performance constraints set by the legacy system, or they may be usability questions which require participation of and evaluation by the users. The exploratory prototype does not need to be designed to address any other issues or questions, and will not be part of the migrated system (although the answers it provides will influence the new system).
- An evolutionary prototype, on the other hand, is intended to eventually replace a legacy component, and must therefore reflect the target architecture. The new architecture most not only adequately support the legacy services, but also overcome the obstacles that limit the legacy solution’s usefulness. The prototype must be design to answer these risks first.
- A prototype can be built quickly, since it does not have to implement all the functionality of the legacy system.
- You can hack parts of the legacy system to get your prototype running.
- You can learn quickly if your ideas for the target system are sound.
- Users may not be highly motivated to spend a lot of time evaluating a throwaway prototype.
- You may be tempted to continue to develop the throwaway prototype.
- It may be hard to convince yourself or your customer of the need for a prototype — after all, you already have a running system.
- It can take too much time to get an evolutionary prototype up to speed. Consider applying Present the Right Interface to legacy components to provide a good interface for legacy services to the prototype.
A prototype can tell you quickly whether a certain technical approach is sound or not. Brooks in The Mythical Man-Month [Bro75] advises us to “write one to throw away” since it is hard to get it right the first time.
Love [Lov93] takes this one step further and warns us that, for object-oriented systems we should “write two to throw away"! Foote and Yoder [FY00] argue that, among other things, Throwaway Code is often the best way to clarify domain requirements, but they also warn that a prototype risks evolving into a “Big Ball of Mud”.
You might consider applying Make a Bridge to the New Town to migrate legacy data to an evolutionary prototype.