Yet another interesting question to ask. What applications can I retire in my application portfolio? How do we identify which applications can be retired and potentially replaced by others? When reviewing a portfolio this is a fundamental question that needs to be addressed, but it often isn’t. So, let me propose you a simple but effective method to do so. We’ll take a two-step approach. First, we will identify which applications you no longer need because they are not used any longer, and second, we will look at applications can be replaced.
What about your zombies?
Many companies have servers and applications running that are in fact no longer used. A recent study from Stanford highlight that 30% of servers in datacenters are comatose, in other words they did not do any useful work in the last 6 months. This may seem strange, but is typically related to the way datacenters are managed. Something is on those servers. Often it is unused applications. How do we find out? Actually through the server and interactions with the servers. By enabling the Sflow features in your switches (here is the list of switches supporting Sflow), you receive a sample of the traffic going through the switch. Analyzing this information allows you, once you have removed the noise and irrelevant data, to understand the communication between applications and with databases. You will often find isolated servers with little or no connections. What is running on these servers? Is this server and its content still required? Or can it just be retired?
Obviously check if any data requiring archiving is still maintained on these systems as you want to make sure you stay compliant. Such approach will allow you to remove the applications that are no longer in use. But can we go further
Let’s now look at the application portfolio and identify which applications could be replaced by a COTS (Commercial of the Shelf) package or a SaaS service. But before discussing that, let me introduce some concepts. Let’s start by defining application types. The first two were originally introduced by Geoffrey Moore:
- Systems of Record: Established packaged applications or legacy homegrown systems that support core transaction processing and manage the organization’s critical master data. The rate of change is low, because the processes are well-established and common to most organizations, and often are subject to regulatory requirements. These systems are typically long standing and it is not uncommon to have the same application running for 10+ years.
- Systems of Engagements: Applications that allow peer to peer interactions. They support the collaboration needs between employees, with partners, suppliers and customers and foster communities around common projects and engagements. They have a medium life cycle (one to three years), but need to be reconfigured frequently to accommodate changing business practices or customer requirements. They typically have a lifecycle of 1 to 3 years.
- Systems of innovation: New applications that are built on an ad hoc basis to address new business requirements or opportunities. These are typically short life cycle projects (zero to 12 months) using departmental or outside resources and consumer-grade technologies.
Geoffrey Moore also divide the application portfolio between CORE and CONTEXT. Core is what companies invest their time and resources in that their competitors do not. Core is what allows a business to make more money and/or more margin, and make people more attracted to a business than to its competitors. Core gives a business bargaining power: it is what customers want and cannot get from anyone else. Context is everything else that needs to be done but that does not differentiate the company from its competitors.
Let’s now look at the application portfolio. What application is core, in other words, what application supports the business processes that differentiate the company all together, that make the company what it is? In the current increasingly digital environment, the chances that the differentiation of the enterprise relies on applications, services and functionality is large. So it is important to clearly identify which digital assets (applications, services etc.) enable this differentiation.
Let’s apply these concepts to our application portfolio
- Systems of Record
Core system of record applications are critical to differentiate the company but do not change that often. If they are used daily it is probably best to keep them in the existing environment. You may want to upgrade them to newer technologies to reduce the support costs, but there is no need to change anything else. Migrating them to cloud will not give you major financial benefits. For the applications that are only used occasionally, you may envisage a migration to cloud as this would allow you to only consume infrastructure services when the applications are used.
Context systems of record lead to a different conclusion. Indeed, those applications do not differentiate you. They consist of functionality you require to run your enterprise, but don’t add any value beyond that. So performing those tasks in the most standard way at the lowest cost should be the objective. For this reason, looking for a SaaS service performing the required functionality makes sense. And if no satisfactory SaaS service exist, investigate a COTS package. Don’t go for costly customization to mimic the current way of working. As this does not differentiate enterprise, it does not add value.
2. Systems of Engagement
Let’s now look at systems of engagement. If they are core, you need to protect them. They differentiate you from your competition. Remember those systems change rather regularly. Using a cloud environment makes sense. In particular, if the business is looking at exposing some of those systems to external usage (clients, suppliers, partners) having the capability to scale up and down depending on the utilization volume allows a constant user experience regardless of the amount of concurrent users. Migrating the applications to a private cloud (ore a virtual private one) is probably the most effective way.
If the application is a context application, is there a lower cost option, either SaaS or COTS? Would it make sense to retire the application and replace it with such component? Here again it’s worth asking the question. Often however systems of engagement have tied interfaces with other similar applications or with systems of record. That should be kept in mind when assessing the possibility of replacement as interface capabilities and latency may limit the SaaS options available.
3. Systems of Innovation
Systems of innovation are typically recently written systems addressing point opportunities or involving new technologies such as IoT. These applications typically retire when the opportunity they address has either disappeared or become mainstream. When becoming mainstream, abandoning the developed application and replace it with a COTS or SaaS product may be the most economic option, but is often difficult as the team who developed the application in the first place has an emotional bond with it. Taking the time to assess whether the application is core or context and whether the functionality provided can be replaced by a more standardized approach (COTS or SaaS) should be done by a team that is not directly involved in the original design. Often enterprises keep investing too long in developing supporting functionality that does not support their differentiation and do not take full advantage of the next innovation on the horizon.
Planning to retire applications should be done with the business
To finish this blog post I’d like to highlight the importance of the dialogue with the business. Defining what is core and context, how applications will evolve, what new opportunities are on the horizon and how they can be addressed imply a close working relationship between business and IT. This relationship is at the core of an effective management of the application portfolio and an improved utilization of the funds associated with digital technologies.
One last comment, make sure you understand what needs to be done with the data associated with the application you retire. Do you need to keep the data for compliance reasons? If you need to, do you still require the application to be able to read the data? In that case you may have to “mothball” the application, in other words, keep it in an environment where you can use the read options when you need to access the data. “Mothballing” the application as a virtual machine in the cloud is an excellent way to maintain the functionality for compliance reasons at low cost.