A number of factors have caused IT organizations to support a variety of applications. They include: specialized needs, politics, mergers and acquisitions and simply unmanaged application growth. These combine to cause IT to have an excessive number of applications to support.
Organizations now need to go back and weigh the trade offs of total cost and total benefits to then make the appropriate business decision about whether to continue supporting each application. On that note, application is a limiting term but one many IT people can relate to. The problem is that the application view fails to account for all that goes into supporting a solution. Instead, we need to think in terms of services.
To manage this efficiently and effectively, a formal project should be launched with the objective to identify underutilized services and then appropriately disposition them. The project should be funded and resourced based on the scope of effort, technologies involved, and so forth. If not handled as a project, then there is a high probability that risks will not be effectively managed. Moreover, this effort will recur on a scheduled basis and can benefit from reviewing the lessons learned after each project.
The first task is to inventory services. This is far easier said than done. At a minimum, IT needs to document parent-child relationships between business services, IT services, applications/software and the relevant supporting hardware. Applications that cannot be linked to business services are immediate candidates for decommissioning.
As IT services are documented, a review must take place to identify where there are functional overlaps or utilization that crosses some pre-defined lower threshold, say, for example, 10%. Whatever the defined criteria is, the low-utilization or functionally redundant services should then be reviewed by a board comprised of the business and IT to decide the fate of the service.
To re-iterate, care must be given to document the candidates for decommissioning and solicit input from business and IT personnel before simply shutting the service down. For example, some service may appear unused, be dismantled and then unavailable for use when desperately needed by the business at year end.
Services that are identified for consolidation or removal need to be project managed to better ensure not only effectiveness and efficiency but also that risks are properly mitigates. In terms of planning, for example, the following are potential factors to take into account:
There needs to be a planned and managed method to identify applications that can be consolidated or shut down. Rather than treat them simply as applications, a services mindset is needed to understand what other dependencies may exist and, ultimately, what the supporting hardware components are.
The decision to consolidate or shut down services must be made jointly by the business and IT based on an understanding of total costs, total benefits and risks. Once services have been identified for consolidation or removal, there needs to be a well thought out plan that minimizes negative impacts to the business while facilitating the disposition of targeted systems. The end result will be a more streamlined production IT environment that meets the needs of the business at a lower cost and with better managed risks.
George Spafford is a principal consultant with Pepperweed Consulting and a long-time IT professional. George's professional focus is on compliance, security, management and overall process improvement.