This post is part of a three-part series on ghost assets.
In my last post, I discussed the ghost asset epidemic many organizations unknowingly face. These assets were once productive test systems, but have since dropped out of focus. They are rogue machines, falling outside the spectrum of active management and are often effectively invisible to daily IT operations, yet these assets present serious monetary and compliance risks for organizations. In this post, I’ll explain how organizations conjure these ghost assets.
Abandon all hope, assets who enter here
If there is so much value in these assets, how are they so easily lost? From sepulchral server farms to phantom PCs and laptops entombed in storage closets and desk drawers, there are countless ways assets become ghosts. One of our customers calculated that ghost assets were costing them $1.7 million per month! How can more than $20 million a year just vanish? Here are some of the most common scenarios we see every day.
The primary goal of a migration is getting essential systems up and running quickly and reliably, leaving ghost towns of servers behind — often with no defined plan to decommission or repurpose them.
2. Mergers and divestitures
Devices that are part of a merger or acquisition typically fall into two categories: The infrastructure that holds the business value being acquired and everything else. Everything else systems that are never incorporated into the primary environment are consigned to purgatory. Divestiture, the other side of Charon’s coin, can be just as tricky. Devices not sold off during a divestiture no longer have a clear purpose and end up alongside the everything-else assets, trapped on the wrong side of the river Styx.
3. Project or product specific
Servers and software are routinely purchased expressly to serve a specific project or product. When the project ends or if the product fails, they leave behind ghost assets, typically without clear follow-up plans for repurposing the assets acquired to support them. Then new projects and products spur the purchase of more assets and the cycle continues. As a business moves forward, ghost assets appear in its wake.
4. Legacy compatibility
Older — often antiquated — systems often remain in an environment because a previously business-critical product was incompatible with more current technology. When the product these assets supported is upgraded, replaced, or changed, they are no longer needed, yet they often remain in place, sometimes for so long it’s forgotten what need they originally served. Telnet-based financial transaction systems, manufacturing interfaces, custom-built mainframes, and similar specialty systems easily become zombies — present but devoid of purpose. A customer that I worked with a few years ago had two rooms full of mainframes and legacy servers that we discovered weren’t connected to anything but power. No one in the IT department could explain what function those assets served or who was responsible for them. They’d always just “been there.”
5. Lack of dependency mapping
Fear is one of the most prevalent drivers in the creation of ghost assets: How many thousands of servers are out there because no one knows what would happen if they were removed? The most effective way to avoid this confusion is to create solid dependency maps. A dependency map is a schematic that visually represents the organization’s physical and software infrastructure with a focus on dependency relationships.
For example, an online product catalog requires web servers, networking, security, authentication, databases, storage, load balancing, backup, disaster recovery, etc. Remove the database from this system and the catalog function will fail. Remove disaster recovery or backup and the end-user functionality is not affected.
Dependency mapping is often overlooked at many organizations because, frankly, it’s very difficult to do. Application dependency mapping is particularly labyrinthine, creating Visio diagrams that look like they sprang from the imagination of M.C. Escher.
The resources you commit to creating and maintaining dependency maps are resources well spent. They play a vital role in “what if” planning, which is critical to understanding what aspects of your environment serve what business needs. Using dependency maps will uncover far more ghost assets — and savings and risk mitigation — than would be found without them.
Ghost assets don’t just emerge from the tombs of obsolete versions and models. They’re created. Upgrades, refreshes, and organizational changes can leave assets in limbo, conjuring up the phantoms that haunt IT departments until some brave soul decides to face them. But how can organizations exorcize their ghost assets? Make sure to check back for part three in my ghost asset series to find out.