Overview of Application Decommission
Application decommission is a trending veracity with more and more organizations assessing the benefits of it. Gone are those days when companies were stacking their applications hoping to leap benefits from those applications some day! Organizations have addressing decommission area more intensely off late due to growing cost and exigent economy. Scrupulous thought process and study underway in organizations to slender their inventory of applications leading to consolidations and migrations to product suites.
This topic has gained severe momentum due to Eagle eye supervision of leadership teams on IT spending. New opportunities being explored from the cost benefits of Application decommission.
It is not uncommon for firms that have been in business for years to have stacked legacy applications that deliver small value to the business but yet represent a significant working and maintenance cost. There is a severe press to find and retire applications which are no longer providing any cost benefits to organizations. With newer technologies rearing to go, why companies need to spend dollars on maintaining those applications which are obsolete!! The challenge companies are facing is which applications to keep and which to retire. Those which are statutory needs and reporting purposes needs a deep dive look before decommission act is put together.
Said so, diverse parameters have to be considered by organizations well before getting into an act of decommission or else it might turn fatal. Thus thought process and strategic assessments are key success factors for system decommissioning. Unfortunately there are no off the shelf criteria’s for decommission application. Organizations have to consider their business pulse, impacts and benefits while making this decision. On times systems decommission can also become very sensitive matter in few organizations as resources would have associated themselves with those systems. There may be an element of job insecurity with decommissioning as staffs may be using those applications for decades! This would be tied to learning and training curriculum of employees if decommission study outcome points towards new applications having flashy features!
Summary – Organizations are looking at streamlining the existing application portfolio to move towards newer generation of computing paradigm. The analogy will be selling old car and buying newer cars with latest technology, features and performance.
The critical parameters details will be covered in next section. Précis of this topic are cost elements (licensing and maintenance) in legacy applications, Complexities, support etc. We will depict this section with a Decision matrix
In strategy section, we will discuss about the best approach to handle system Decommission. We will demonstrate this with an Activity Map
Decommission activity is closely tied to Consolidation and Migration activities. We will touch base on how they are related and what approaches need to be taken for smooth handshake. We will demonstrate this with a process map.
The sine qua non with decommission is benefits. We will outline the key benefits by successful system decommission activity.
The most imperative aspect of the life cycle of decommission is its execution. This can “make or break” the organization purpose of Decommission activity. We will cover the execution model through a sample vision plan.
Contemplation during application decommission
System decommissioning decision cannot be instantaneous. A rigorous analysis followed by methodical approach is the key for successful decommissioning. Mostly but not always decommissioned systems functionality will be replaced by new system or migrating to another existing system in the organization. The key factors which needs to be considered by organizations before decommissioning are –
- Licensing and implementation cost ( value when purchased and installed)
- Maintenance cost of the application
- Key business functionalities
- Application Return on Investment
- Relevance to modern days
- User ratings / opinions
- System credibility
Decision matrix –
The decision matrix is a crucial element in determining the right Decommission for an organization. There are proven records about applications being decommissioned and later reverted ( De-decommissioned ! ) . The best way to avoid this is by ensuring the decision matrix is amply evaluated and assessed. The factors can vary from company to company. This can be customized based on the need of the organization. There are no thumb rules in deciding the various factors or weight age. This will be determined during blue printing stage of the project.
Key stakeholders / Decision makers in the decommissioning activity are:
- Business team
- IT team
- Technical engineering team
- Audit / Compliance
Business team plays a vital role in determining the factors and weight age to be adopted for the applications to be decommissioned. By the end of Blue printing phase applications to be decommissioned should be determined. Various functional and technical analyses are must before making final decision.
Now the decision of decommissioning is made and the applications to be decommissioned are also finalized, it’s time to plan and execute decommissioning. Important artifacts during realization phase would be
- Flow diagrams (Inbound and Outbound flows)
- Feeds to 3rd party systems
- Impacts due to decommissioning
- Jobs affected
- Business impacts
Timing is the most crucial element in decommissioning. When and what will be decommissioned has to be solidified before implementation. The various technical analyses during realization will help in determining this. The current processes have to be well versed before getting decommissioning act together. Decommissioning can be an isolate activity or can be tagged along with ERP implementation. Studies have shown enterprise wide package implementation will be the most suitable time for decommissioning activity as it helps business and IT teams to identify the obsolete, Fit and Gap processes.
An application or functionality can be made obsolete if for certain that the new system will have that functionality (FIT in new system).If an application or its functionalities are no longer needed at all, it can be completely decommissioned without building any functionalities in new system (OBSOLETE).During decommissioning it will also be determined if there are any GAPS which exists between legacy and new systems. Requirements have to be identified and written for those functionalities.
Point to remember here is any rework during latter stages of the projects involves higher costs, Thus thorough due diligence is recommended to avoid last-minute chaos. It is general tendency to revert decision on decommissioning during final execution due to lack of analysis. The prime reason is the new system would not have that functionality developed or due to the complexity involved in developing that functionality in new system.
Five Phase Decommission strategy (L0)
Following information are key to determine what to be decommissioned and when to be decommissioned. This will be captured during business interviews and further technical analysis.
- Business Functionalities in the application – List the key functionalities used in this application
- End users – Who uses this application and functionalities
- Application inputs – Inbound feeds to application in scope for decommission
- Application outputs – Outbound feeds to application in scope for decommission
- As IS Reports generated from application – List of reports which are being generated from this application, frequency of usage and users / groups.
- External interfaces – Application level interfaces with 3rd party systems
- Application inventory – List of tables, Databases, Programs
- Online Screens / Batch programs – Lists the screens used in the application. This information is critical during implementation as those screens links to be removed so that users are refrained from using those screens.
- Job inventory – List of Jobs and frequency of it ( Hourly, Daily, Monthly, Yearly)
- Application flow – High level application flow with context diagram stating upstream and downstream applications
- Recommendations – Timing, Fit / Obsolete / Gap, Data migration, Data Volume and Pros and Cons of decommissioning.
Key Things to consider –
- 1. Data retention – It’s important to keep asking this question again and again till concrete direction is laid out. Mind you, Data retention for compliance purposes is a must requirement
- 2. Retain Business context and referential information – Once an application data is decided to be retained it is very important to retain the business context and referential information’s. E.g. – If Sales order information is decided to be retained, all transactional information related to SO’s like Item, Quantity, Billing information’s, warehouse and transportation information’s to be retained. Referential information’s like Customer, Item, Ship-To address information’s also to be retained.
- 3. Keep application SME in loop in all the decommission discussions. If possible form a CORE Decommission team with representations from Business, IT, Technical engineering (DBA, Operations), Compliance, Audit, people management / Training and security team.
- 4. Data access – Provide access to historical data on needy basis. Efficient way to provide access to data has to be planned out. Sales and audit teams would need historical data on time to time basis.
- 5. Timeframe for data retention – How long the data to be archived? How old data is needed for audit and sales purpose? It has to be borne in mind that data retention also involved cost. The purpose of retiring application will be defeated if proper planning for data retention is not made.
Drivers for Decommissioning
The key drivers for decommissioning are
Merger and Acquisition
Timing of Decommissioning is a tricky one. Companies would do due diligence on when and how the obsolete applications to be retired. As said before, it is not uncommon for companies to stack up applications who are in business for long. Pressing needs of newer technologies, functionalities and business needs would have driven for more applications to be bought or developed in-house. Companies have burnt their fingers retiring applications without proper planning and mitigation. So it is very important to decide on the timing of retirement of the applications.
Few companies choose during Merger and acquisition (if it happens! ) for decommissioning.
Imagine “A” company having hundreds of applications and merged with Company “B” which also has tons of applications!! Both these companies would have similar kind of functionalities build in their respective applications. It needs a diligent work to decide on which applications to retain and which applications to retire. It could also be a possibility that some functionalities in some applications itself might be needed and not the full application. Thus a detail STOCK TAKING OF APPLICATIONS is a MUST activity. The best approach to handle this has to be weighed out (like whether new interface to be developed or retain existing application).
One of the pain areas and challenges to IT teams during merger and acquisition IS RETIRE VS RETAIN.
Recommended approach to companies is to engage specialized vendor to perform assessment (Generally 8-12 weeks) before further decisions made.
COTS(Commercial off the shelf) ERP application
Companies leaning towards integrated software for their daily business operations from existing custom discrete applications. The philosophy behind many ERP systems is that a suite of software tools can quickly integrate all areas of business administration. This will set up a competitive environment with cutting edge functionalities. As the business evolves, driver here is to update older technology, consolidate and decommission applications and simplify the supporting IT infrastructure to eliminate redundancy and lower costs. As mentioned in earlier sections, organizations need to evaluate application portfolios regularly to decide whether their investment is delivering maximum business value. Weighing the costs and benefits of each application can help in deciding which applications should be maintained and which applications should be upgraded, replaced, consolidated or decommissioned.
Upgradation to ERP package gives new dimension to business processes. This would give an opportunity to adopt Industry best practices through cutting edge functionalities. As an ERP system provides an integrated solution, it provides an opportunity for companies to give another close look on retiring obsolete or redundant applications. If a legacy application is decided to be retained, a new interface (inbound and outbound based on requirement) has to be build to interact with the ERP solution. Similarly all the reports generated from the application must be evaluated and accordingly has to be retained or retired. End users have to be promptly communicated on the upcoming changes so that there are no surprises. Nobody likes to be taken by surprise, so ahead of time training and communication is key.
Benefits from decommissioning
Decommission is a huge savings for organizations. There are both tangible and non tangible benefits from decommissioning. The goal of the CIO and overall IT organization is to make sure that the applications are delivering maximum business value. By analyzing how business applications satisfy operational and reporting requirements and by estimating IT resource and application maintenance costs, companies can decide which applications should be maintained and which applications should be upgraded, replaced, consolidated or decommissioned.
The key benefits from Decommissioning legacy applications are
- Cost benefit –Huge savings from retiring redundant and obsolete applications. The savings includes operating costs, Licensing costs, maintenance costs, Hardware infrastructure, costs due to complexity of customizations
- Options to spend on other projects from the
- Savings in storage space and power consumption
- Brining newer technologies on board with consolidation and migration
- Annual productivity improvements
- Addressing Performance issues moving to newer system
- Setting new horizons and challenges to staffs
- Having measurable and manageable inventory of applications
- New look and feel applications to end users
- New learning’s to staffs. Higher motivational factors
- Cutting edge functionalities making staffs life easier.
Timeline and execution model
The key to any successful consolidation or decommissioning project is careful planning and assessment. Before the initiation of the project it is critical to have all stakeholders in agreement on the decommissioning applications and approach. Each group will have their own requirements. Business team might be in need of historical data. It is important to make sure that the data is easy to retrieve and restore. Efficiency is the key here.IT team would look for best and feasible solution that minimizes costs infrastructure complexity and operational risks. Audit and compliance team may want to make sure security, timely access and appropriate disposal to support corporate compliance initiatives. Corporate training team wants to communicate and equip the staff accordingly on upcoming changes. With these many stakeholders involved, it is important to manage organization’s application portfolio in a way that addresses the critical needs of each and every group.
Bear in mind that Communication and Training should be an integral part of decommissioning activity. The stakeholders have to be constantly posted on the developments. A proper planning and execution ensures smooth transformation without any surprises.