This article was featured in Architecture and Governance Magazine in November 2015. It describes a blended technique I developed as a consultant, using the combined strengths of TOGAF and Business Analysis techniques, to rationalise the application portfolio of a complex organisation.
IT has revolutionized the business world. Initially, an organization’s software is carefully selected, well-ordered, and fit for purpose, but as the years go by, the organization’s application holdings grow organically. Inevitably, its application landscapes become increasingly fragmented, outdated, and opaque. At the same time, its business processes evolve, often without due consideration to the underlying IT, resulting in a misalignment between the application and business architecture layers, the consequences of which can be enormous.
Organizations with complex application landscapes find it extremely difficult to invest effectively in their IT. Beyond the challenge of confirming what they’ve got, there is the additional complication of understanding the co-dependencies that exist. For example, the organization may be dependent upon certain core applications and afraid to update them in case they stop working. By contrast, a well-understood and ordered application landscape, aligned with the business architecture, provides senior management with a holistic view of their organization. This insight enables them to make more effective decisions and ensure that money is not wasted on applications that are no longer required.
If the business architecture of an organization is already known, then it is possible to provide a basic insight into an organization’s application portfolio by creating several co-dependent deliverables from the TOGAF specification. This approach is light-weight and scalable; it can be used for organizations of any size, and it is extensible, since further artefacts may be created to describe the technology infrastructure and data layers if a deeper, more detailed view is required.
The Application Portfolio Catalogue is the starting point for any portfolio management or rationalization task; this is a complete list of applications, their cost, co-dependencies, number of users, the names of the person responsible for each, etc. The catalogue allows patterns, inconsistencies, and knowledge gaps to be identified. Finding a gap can be vitally important; decision makers may be unaware that they are missing key information. Completing the catalogue allows you to fill the gaps and provide a firm baseline for further analysis.
Using the data in the Application Portfolio Catalogue, the Application Interaction Matrix, Interface Catalogue, and Application Communication Diagram can be developed to help the organization understand how the applications connect and interact. These will highlight the standalone applications that are not connected to any other. In certain environments, the defence industry, for example, certain applications will not be networked for security reasons. However, if the organization does not have such concerns, a plethora of standalone applications might indicate the presence of outdated and inefficient working methods. In such cases, the rationalization can be used as a driver for business transformation, triggering the organization to invest further in architecture development.
The next step is to align the business and IT within the organization. An Application User Location Diagram will show the organization’s systems administrator where the installations need to be so that the correct people can use the software. An Application/Organization Matrix and an Application/Business Function Matrix will help the organization to understand which parts of its enterprise use which applications.
These matrices will also reveal instances of duplication, in which multiple applications are doing the same job, and redundancy, in which an application is still present but no longer used. Duplications often arise through poor communication; the organization’s staff might have purchased applications without realizing that either they or someone in a different department already had the required function. Redundancies occur when a business process has changed, but the IT or finance team hasn’t been informed. The IT team continues to maintain an application that is no longer used, and the finance team continues to pay for the associated maintenance and licences, resulting in significant cost inefficiencies. Acting to remove the duplicate and redundant applications not only reduces the complexity across the entire IT portfolio, but the potential cost savings can be enormous.
Having fully understood the application landscape, we can assess the security, technical, and functional risk. To do this, one looks at the system software. That is the standard software and operating systems (for example, Acrobat Reader, Windows Server, etc.) upon which the organization’s applications depend.
If the organization intends to use a particular application until the end of 2017, but the system software that it needs runs out of support before that, then there’s a problem. Depending on the software, this could make maintenance difficult, raise exposure to security threats, or increase the risk of system failure.
By developing an Application Roadmap, such as in Figure 1, the applications can be plotted on a timeline to show their projected useful life. Including dates for the system software associated with each of the applications will highlight the potential technical risks. Using the roadmap, the organization can put an effective plan in place to upgrade/update the systems as needed within the necessary time frame.
In April 2014, Microsoft ended extended support for Windows XP. Since the UK Government had not anticipated this, it was forced to pay Microsoft £5.5 million to continue to provide support for an extra 12 months in order to mitigate the security risk this posed. This huge cost, which added no value or functionality, could have been avoided if an Application Roadmap and transition strategy were in place.
Marrying enterprise architecture with business analysis techniques can be extremely powerful; especially for the business executives and senior management team who will ultimately be the people responsible for making the decisions. Quite often, nontechnical people find it hard to understand architecture views. Although the enterprise architecture allows you to do a deep analysis of the application portfolio, the two business analysis grids shown in Figure 2 and Figure 3 allow you to extend that analysis and communicate the findings in a digestible format, where the message is clear and easily understood.
First, determine the strategic relevance of your applications to your organization and distribute them into the appropriate parts of the grid detailed in Figure 2.
An application is considered ‘strategic’ if, should it stop working, the whole organization would be affected. A ‘factory’ application would impact only part of the organization if it were to break down. ‘Support’ applications have very low business value; you should determine whether or not the organization really needs them, and if it does, if they could be outsourced. ‘Turnaround’ applications and technologies are those that you don’t currently have, but need to consider, as they are likely impact the organization in the future. Cloud technologies are one such example.
The Application Portfolio Optimization Grid in Figure 3 indicates the health of the applications. In an ideal world, all the applications will be healthy, low-risk and a good business and technical fit. However, if the business processes have changed, some of the applications might no longer be appropriate. These require ‘functional reengineering’ to adapt them to the new way of working. If the application still fits perfectly well with what you’re doing but it might need to be updated or upgraded to bring it back into health again, then it will require ‘technical reengineering.’
‘Retirement candidates’ include redundant and duplicate applications. These require a specific decom-missioning strategy; they should not simply be switched off, as they may contain data that needs to either be archived or moved to a different application. The key benefit of this grid is that it helps business executives to prioritize the appropriate actions required to bring the applications into ‘healthy’ or ‘retirement.’
Regardless of size or operating sector, organizations that rely on IT can benefit from this combined approach. The enterprise architecture provides a clear view of the application landscape and identifies the associated business, technical, strategic, and operational risks, while the business analysis techniques determine the health and strategic relevance of the applications. Together, these provide business executives with the objective information they need to make effective decisions when managing and investing in their IT infrastructure.