Organizations are waking up to the costs associated with operating and maintaining applications in production. And the Green IT movement is highlighting the environmental issues and hard accounting costs associated with the electricity consumption of data centers. While there are many vendors frothing at the opportunity to sell technical solutions, there are, in fact, many opportunities to reduce the number of applications in production that are process oriented. An approach that can yield substantial benefits is to consolidate applications and reduce hardware requirements in the data center.
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”.
The IT Infrastructure Library (ITIL) espouses the perspective that IT provides services to the business that are comprised of software, hardware, facilities, people, vendors, contracts and so forth. These all come at a monthly cost that can be calculated and compared to the benefits for both IT and the business to decide how to proceed with each service: continue as-is, consolidate with another IT service or shut the existing service down outright.
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:
- If any design changes are needed to the existing services to support the new users. This could include business rules, table design, reporting, etc.
- How to migrate existing users to another service and this includes training, access levels, etc. -Any security requirements that the old system had that the new system must accommodate.
- Any regulatory compliance requirements that the old system had that the new system must accommodate.
- How to migrate data, if any, to the new service?
- Will the existing service be left operational in read-only mode for a period of time to allow for research?
- What data integrations may need to change.
- If the existing service has adequate capacity, availability and continuity support (note, these are important requirements to address in virtualized environments, as well).
- What to do with the hardware of the service being shut down.
- What security procedures need to be followed to wipe existing hard drives and backup media. -Data retention requirements that need to be supported.
- Any special business events that could affect the project schedule. For example, if the remaining service has peak demand in November and December then it may be wise to target the end of the migration for August 31st.
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.