Step 7: Decommission
There may come a day when the data warehouse, or a component thereof (a staging database, a data mart, a reporting database, a cube) no longer meets requirements, and it’s time to decommission it. Not every database can be constantly refactored or upgraded to meet new requirements. Sometimes you simply have to scrap and rebuild, especially if the database instance was “built on spec”, that is, never properly architected to fully reflect the goals and intent of the enterprise. When this happens, as PM, you have to synchronize the process.
Typically, the Decommission step happens in one of three ways: Decommission with no replacement; decommission with cutover; and decommission with phase in/phase out. “Decommission with no replacement” means that the function the database used to perform is no longer needed. Not only is the database retired, the functions it used to perform are also retired. “Decommission with cutover” indicates that another database will replace the one being retired, and that the functions performed will be quickly transferred from the old database to the new. One day the users will be pointing to the old database, the next day they’ll be pointing to the new. “Decommission with phase in/phase out” indicates that the old and new databases will be run side-by-side for some period of time while functions and users are incrementally transferred from the old onto the new, until at last there are no users or functions running on the old database and it can be retired. Each scheme has its risks and rewards; as PM you have to determine when the risks outweighs the rewards and which scheme makes most sense for your situation. Then you have to plan and execute, working with others in the Technology Track and the Applications Track to ensure a seamless conversion.
The Virtuous Cycle
As you work with these data warehouse components there will be subsequent rounds of discovery, during which you’ll assess the new requirements that have evolved over time. This can happen as a result of the information gleaned from the data stored in the data warehouse. These new requirements might lead to enhanced designs and expanded solutions for one or more tracks. You’ll need to integrate the changes in the existing data warehouse so you can deploy the newer, better solutions to the business users eager to take advantage of them. Some new requirements might cause changes in the day-to-day operations in order to keep the data warehouse running like a well-oiled machine.
Over time, multiple iterations of this lifecycle process will cause the data warehouse to be ingrained into the fabric of the enterprise, until the data warehouse and the business become a seamless unit. The PM part of this puzzle ensures that all activities and tasks are done according to specification, are accepted according to the success metrics established, and deployed synchronously. Even if your data warehouse project has no formal PM, even if you’re the only person listed under “resource, human” on this project, you should still do some sort of PM plan and keep it up to date. Then, when management asks “how’s the data warehouse project going?” you can show them exactly what stage the project is at and what’s been done.