If zombie apps are attacking your company, you need to hire an application assassin.
Is your company suffering from application bloat? Do you have expensive, overlapping legacy apps that need to be decommissioned as you move to modern, lightweight apps, or to the cloud. Do you have zombie apps lurking in your IT infrastructure, applications that nobody uses anymore but that are still live and contain sensitive data?
Then you need an app assassin – someone to help identify and properly kill off applications that you don’t need anymore.
According to Forrester, “Twenty-six percent of North American and European software decision-makers at enterprises see it as a critical priority to update and modernize legacy applications,” says analyst Paul Hamerman. “An additional 49 percent rate this as a high priority.
Gartner analysts Andy Kyte, Jim Duggan, and Stefan Van Der Zijden have a unique solution for decommissioning such applications: the “Application Assassin.”
+ MORE APPS: Apple’s best apps of 2015 +
“Before an application can be properly decommissioned, it needs to have no live use,” says Kyte. “It should be, for all intents and purposes, dead.” Kyte explains that the project manager responsible for eliminating the necessity of an application — by executing an effective alternative — is called the “Application Assassin.” It’s the assassin’s job to to kill all needs for that application’s use for live data processing purposes.
The app undertaker
And even after the application is dead, some post-mortem activities may still need to be undertaken “to ensure that the last traces of the application are removed and that the historic data finds a home that ensures compliance with regulatory requirements,” adds Kyte.
That’s the role of the “Application Undertaker,” the person who buries the application corpses.
Gartner says that between 2016 and 2020, IT organizations will decommission more than three times as many apps as were decommissioned since 2000. By separating the roles of the application undertaker from the application assassin, CIOs can focus on measuring and managing these decommissioning activities using appropriate metrics, rather than trying to manage several major application-replacement projects and hoping that decommissioning might happen.
A bloated application portfolio is large, complex, and expensive, says Gartner analyst Duggan, and does not easily adapt to businesses’ changing needs. The escalating demand for more features, flexibility, functionality, integration, mobility and analytics mandates that this bloated folder is trimmed down “removing low-value duplications and embracing cloud-based delivery models to replace aging and expensive on-premises solutions,” says Duggan.
“Modern solutions and architectures are out there,” adds Van Der Zijden, “but grasping them and their manifest advantages will involve a ‘bonfire of the legacy’ type campaign.” In order to extinguish the old and expensive, and then liberate those resources that focus on innovation and modern, efficient delivery models, that bonfire must include a significant demand for application decommissioning, he explains, which then requires the “Application Undertaker.”
Confessions of an App Assassin
Patrick Hubbard, head geek and technical product marketing principal at SolarWinds Worldwide, LLC was once such a mercenary at a leading airline. His job was to extract, replace, or otherwise shutter outright applications that were inefficient, brittle, or too expensive.
“Many global 1000 companies have similar situations, where a preferred vendor, supposedly, has fiduciary interest in seeing its mother organization succeed, but with directly conflicting revenue interests,” Hubbard says. “They must extract as much business as possible, one program at a time. Recurring cost technology services critical to operations are cash cows, especially when the parent company has lost the technical expertise to accurately assess individual implementations. It’s not as insidious as a host/parasite relationship but, for many companies, it’s far from symbiosis.”
Hubbard explains that most of the airline’s projects were technology leadership and innovation focused, which performed faster, better, and more affordably than the preferred vendor’s products. For example, the preferred vendor proposed a new pager notification for passenger flight information system that was estimated to cost over $1 million and take a year to complete. The airline’s IT group had a prototype running in less than a week, and it went live for less than $50,000.
“We did dozens of projects using then-current web- and client-server technologies,” says Hubbard.
Because he and his team had access to all the deep, technical details of how the company’s systems worked, they quickly realized that it was an environment ripe for cost savings through system automation, combination, and termination.
The App Assassin’s job
So, what does an app assassin do?
First, attend all meetings with product and program managers and assume the role of the client/vendor interface. Second, perform regular census sessions with users to discover which systems they like, which were effective, and which were outright hated. Then analyze the systems’ designs vs. user training, to identify systems that are actually effective, but with user communities that don’t know or understand how to exploit these applications’ features. And last, create and deliver proposal presentations to the budget owners.
+ ALSO: How to create enterprise apps employees will actually use +
Hubbard explains with this example: Pricing and yield management (PYM) is the secret sauce that makes airlines succeed or fail. If the demand analysis can accurately predict how many passengers are willing to pay a given price at the time of departure for a given city pair, airlines can profitably offer service, direct or connect the frequency, or elect not to serve the market at all — with limited exceptions for competition, route building, or tax incentives. The IT systems that support this are computer-human hybrids of algorithms and analysts who juggle billions of individual fares published by reservations systems.
“Our PYM team had three separate systems, each offering a portion of the functionality the analysts needed, each with considerable overlap,” says Hubbard. “Each had been custom developed by the technology vendor before the spin-out, and each hit a different budget line. The company was collectively spending millions, year after year, supporting these three systems when only one was necessary.”
When, why and how to murder old apps
First, when a single application is replaced by another, the application assassin can arrest, then jail that app (for decommissioning) until the live process migration is complete (then he can kill it). Second, when a single application is replaced by many applications, there could be a couple of assassins — but the final migration process must be complete before the app is murdered. And third, when several applications are replaced by one or more new applications, which are implemented together; then multiple assassins may be required to terminate each one separately, once each application achieves full redundancy.
According to Gartner, all applications have multiple activity streams; therefore, it’s vital that the project managers assuming the role of Application Assassin know and understand how and when to kill an application. The most effective method for this process is to create a template that’s revised and updated — based on the actual experiences of a trained Application Assassin or Undertaker. This ensures that all the bases are covered.
For example; Kyte, Duggan, and Van Der Zijden suggest that this template should include:
- Any contractual obligations such as licensing from an independent software vendor, which may have existing contracts regarding usage rights and maintenance fees.
- Any third-party services such as application maintenance outsourcing, which might require collecting all source code, documentation, and/or test scripts so the vendor manager can expunge all relevant data from the third-party environment.
- Any operational events regarding the live environment that hosted the application should be terminated immediately and all data must be purged. Note: Specifically investigate the disaster recovery and business continuity management plans for any connections to the murdered apps.
- Any copies that may reside in the development, support, and operational environment are now redundant; therefore, should be expunged along with any/all associated hardware, which should also be retired or reallocated.
- Also note any possible infrastructure software dependencies like, for example, licenses for stack components such as those used in content management systems, integration and analytical tools, and/or databases.
- Any additional software tools such as testing, source code management, and/or configuration management tools, plus compilers and editors, should be checked for exclusive use by the specified applications or, if cost-effective, reallocated to other compatible apps.
The downsides
Decommissioning legacy applications often means a reduction in force. Sometimes, the staff can just be reassigned to the new ‘replacement’ app. But when the new application replaces three of the zombie apps, it’s reasonable to assume that one new application won’t require as much attention as the three older apps.
Another downside is the enormous collection of clutter that has accrued over the years for each legacy program. “Artifacts such as the originating business case, project plans, contracts, organization charts, progress reports, designs, bug reports, training videos, enhancement requests, and a host of other materials have accumulated around each application,” says Kyte. “These must all be sorted, sifted through, and eliminated. Each organization needs a set of policies, which are appropriate to that specific organization and its culture. While some organizations are happy to fill a dumpster, some prefer to shred all of the physical material, while others choose to archive the material.”
Third, there are no guarantees that killing off all the zombie apps will enhance or degrade the company’s ROI. “The straightforward and simple answer is that there is no correlation whatsoever between the original cost of implementing the application and the cost of decommissioning it,” Kyte adds.
Decommissioning has two phases: the assassination phase and the undertaker phase. There are no easy rules for the assassination’s job; that is, to implement a replacement application so the legacy app can be decommissioned. However, as the number of zombie apps grows, the responsibilities and the cost for the undertaker’s job also increases.
Sartain is a freelance writer. She can be reached at julesds@comcast.net.
