How long do you think it takes to remove and retire a system for a typical large organisation? If you are one of those who thinks a few days or a few weeks would be enough - then hold on tight! For a large global organisation, it takes months if not years to make only the decision. And then the real work can start - to plan and execute the chosen strategy. I hear you ask why. Well, for a start, typically there are hundreds if not thousands of applications to consider, each with its own story. Often many of these applications have no up-to date documentations; each of these applications, in some way are connected to many of the other applications. On top of that businesses are evolving constantly – so what an application may seem not value-adding now, might become a key asset after, say, a business merger takes place. So, in short – there is lots to think about and it takes time. In this post, I am discussing what a client often has to do before they come to us for developing a new application, giving it a technology refresh or integrating with other applications. This is a lengthy and complex work and one that requires the client to work with people across the organisation to build a consensus through convincing arguments. This means a strategy or an auditable process is essential. This post is about this method. I have tried to describe how to analyse the applications, develop an application strategy through developing a roadmap for each of them and in the process, breathe a new life into the application landscape.
Simplify to Succeed
We all know that organisations are dependent on IT applications to conduct their business from purchasing and operations to selling and servicing their customers. This dependency makes the applications hard and crucial assets. In most companies there are a multitude of applications at different stages of their life, delivering different levels of value. We call this the Application Landscape.
This landscape is under continual pressure to satisfy ever changing business needs. As a result, changes are often made in a way that compromises the original design principles of the applications. Ad hoc extensions, built as short term measures, and temporary “point to point” integration solutions lead to the degeneration of the overall architecture.
This decaying, complex and cluttered landscape cannot support the business as well as it should.
In fact, the accumulated dead weight causes support costs to rise and business changes to slow down. Inevitably, business managers feel frustrated and become critical of the technology used and the team responsible for that technology.
I have seen that many companies are scrutinising their application landscape to see how it can be simplified or de‐cluttered to improve the value that IT delivers. In addition, this simplification reduces operational cost, freeing up capital.
Tried & Tested Process
My approach describes a method that allows a complex application landscape to be analysed using the following four steps:
- Understand the Business Context
- Take stock of all applications within the landscape
- Analyse the applications
- Develop roadmaps
The first step captures the key strategic direction and intent of the business. This defines the context for the application landscape.
In the second step each of the applications is closely scrutinised. The attributes captured include: business value, total cost of operation, technology platforms and underlying architecture.
The third step develops an objective set of measurement criteria and uses those to analyse each application in turn.
The final step examines all the data collected to assess the applications in terms of value, cost and risk. After an intense, iterative process the final outcome is an agreed pragmatic roadmap that defines the optimum course of action for each of the applications.
Step 1: Understand the Business context
The first step in this method is to create a simple model of the organization that gives a high level view of all business activities, their drivers and overall purpose.
This model acts as the foundation for the remaining steps. It provides a contextual framework onto which the applications can be mapped and analysed which helps to determine their strategic purpose either individually or collectively.
The model visualises the organisation as a logical set of business activities grouped together and placed in the form of a matrix – “business on a page”. This “top down” approach makes the model easy to understand and use, enabling fast and informed decision making. Once developed, the model is validated and refined using a few key business processes with the help of the business executives.
The findings are then summarised in a single page. The simplicity of the approach and the output allows the senior executives to remain engaged in the method.
Step 2: The Application Stock Take
In this data gathering step, key attributes are collected for each application in the landscape.
The data includes: the business case for the application, how it has evolved, technology platforms, architecture and data quality.
By analysing business value, the total cost of ownership and operational risks, a set of cost, benefit and risk profiles for each of the applications are also produced. This improves the project team’s understanding of any shortcomings of the applications.
Application coverage charts are then produced by over‐laying the application profiles on the business model developed in the previous step. This identifies business areas with a lack of adequate application support, as well as duplicate applications with overlapping functionality causing potential issues for the business users. I call this a “Heat Map”.
In addition, these charts provide insight into the governance mechanism of the application landscape that is in place.
Step 3: Analysis
Consistency in evaluating the applications is essential for success and an objective analysis of the applications is at the heart of my approach.
I use a proven set of measurement criteria as the starting point and then build an additional set which fully reflects the unique situation of client’s business
The measurement criteria can be divided into the following categories:
- Value: The importance of the application.
- Function: The use and breadth.
- Data: Quality, accuracy, span of use and any missing pieces of information
- Technical: The appropriateness of the platform and architecture used.
- Financial: All costs associated with owning and running the application.
- Risk: The technical and operational risks along with their severity and likelihood.
The project team use the data gathered on the applications and apply the measuring criteria one at a time in a workshop. The results are reviewed in separate sessions with business managers to ensure a consistent and objective outcome.
Step 4: Develop the Roadmap
As I said, for a typical large organisation, the application landscape contains between a few hundred and many thousands of applications. Deriving the optimum roadmap for an application landscape that is complex is not a trivial exercise.
The information collected in the Analysis phase is used to assess the applications from various perspectives. For example, its strategic value by getting a sense of how critical the application is to the business and essential for sustaining business benefits in the future. The other categories could be
- Turnaround—Not critical to the business currently but has the potential to be so in the future
- Factory—Critical to the operation but unlikely to give any business advantage in the future
- Support—Not critical to the business now, nor in the future
Applications are plotted along different dimensions and a set of initial hypothesis is established for each applications. The following diagram gives an example of such an analysis.
This hypothesis is then tested again and again by more inspection, resulting in a robust and objective conclusions. Further analysis are made for the application to inspect from multiple points of view. For example, an analysis of Value vs Risk will help to look at the application landscape from a risk portfolio perspective. Other examples could be Current Value vs Future Value, Application Value vs Value of Data Held, Application Cost vs Value etc. Once all the analyses are complete, we can start to draw conclusions about the potential recommendations.
For each of the applications, these can be grouped into Retire, Replace, Realign and Retain. Within Realign and Replace, we can also consider: Consolidate, Integrate Re-platform or Technology Refresh.
This is an iterative process where potential scenarios for each application are evaluated and refined. They are also aggregated into work streams and re‐evaluated in workshops against the agreed criteria. Finally, the agreed work streams are crystallised and the road map is complete.
Putting it all together
Management of the application landscape is not a static, one off exercise. It is a continual and evolutionary process involving data collection, analysis and deciding upon a set of actions to achieve better strategic alignment with the business. Ultimately, these activities increase the value of the applications and minimise business constraints.
In this article I introduced the overall method along with the steps involved in it and highlights the benefits of De-cluttering the Application Landscape. These steps describe the first iteration of the continuous process of application management. However, appropriate changes should be made to this process when designing the second and subsequent iterations.
Among public and private sector companies, Shared Service is a popular concept as it helps to reduce the cost as well as improve the value of IT. However, the implementation of shared services is not without its dangers. A cluttered application landscape lacks a clear and established strategy for the applications. Starting an implementation of a shared service facility that uses one such cluttered application landscape is one pitfall. In my experience, a de‐cluttered application landscape provides a perfect foundation for companies considering shared services.
It is a common occurrence to mistake Legacy transformation for de-cluttering the application landscape. Legacy transformation is about retaining and extending the value of legacy applications. It is a generic term for a number of specific actions to deal with a legacy application. The simplification of the application landscape however, considers all applications and decides a specific set of action(s) for each. The set of actions for a legacy application can be summarised as legacy transformation that is part of the roadmap.
Finally, as with any strategic initiative, it is important to build a strong business case before proceeding on the journey of de‐cluttering the application landscape. I firmly believe that there is a good business case for simplifying the application landscape. The impact of simplification can be felt in the short term by the IT organization through reduction of costs. However, the business functions will benefit in the long term as IT becomes an enabler to business change rather than a hindrance.