“What is dead may never die”
George R. R. Martin
The Good
As part of the implementation of an application (or at worst retrofitted) all of the data associated with an application that are subject to records retention are either:
- extracted as part of a Data Strategy and stored in a corporate data lake
- migrated to the successor application
Basically – good data governance principles have been applied.
The Bad
Due to cost, time or just crappy reasons a decision is taken that only some of the data from the legacy application into the successor application, meaning that there is an archiving initiative launched to secure the data in the data vault, build reports, test the migration … all wasting time and money.
And The Ugly
Due to cost, time or just crappy reasons a decision is taken that only some of the data from the legacy application into the successor application … but the business insists that they also still need to keep the old legacy application. For the reports, as a comfort blanket, insert other nonsense here.
Time to stand your ground as a zombie application is being born.
What Would Clint Eastwood Do?
Probably something very cool and intimidating, but not much help in this situation.
What Would An IT Garbageman Do?
Far less cool, but perhaps more practical.
This is a problem that others try to hand over to the IT Garbagemen but basically has nothing to do with us. Regardless of how IT and the business try to categorize the application it is still a production application. The business needs the application for reporting, so it is still a live application.
End of story.
Mike drop.
Geek reference mixing reaching critical level.
There are basically three paths out of this situation.
- The application is treated as a live application and is subject to upgrades, support and maintenance and all other costs that live applications incur.
- The data subject to records retention is transferred to the current production application (which should have happened in the first place) and the zombieapp (copyright pending) is laid to rest.
- A new minimalistic production application consisting of the database and all necessary reports is deployed, and the Product Owner foots the substantial bill for this waste of time and effort.
What is Dead May Never Die
If option 3 (the zombie application) is chosen then there are other points to be considered.
If the original application was not the system of record for any data then neither it nor the zombie application should be archived. This should be noted in the application documentation for the zombie application so that there is no confusion in the future.
If the original application was the system of record then a decision must be made on whether to archive it or not. If yes then the full end of lifecycle process must be followed and the application documentation for the zombie application should note that it is a read-only copy of the original application and not subject to archiving. If no then the application documentation for the zombie application should note that it is a successor application and is subject to archiving.
And to add to the fun … both the zombie application and any archive of the original application are both subject to data privacy obligations, meaning that if a request is made to delete data it must be done in both the zombie application and the data archive.
Conclusion
As Rick Grimes, Ash Williams or Sean (of the dead) will tell you … zombies are bad news.
They are fundamentally a failure of data governance practices and are not the responsibility of the IT Garbagemen to clean up. You can explain the rules and give guidance on next steps, but it has to go back to the Product Owner for resolution.
