In today’s economic climate, cost savings are generally top of the business agenda. As IT departments’ budgets are squeezed, there is pressure to find savings by rationalising the application portfolio. The Honeywell Company’s recent achievement in reducing their 150 ERP systems to only ten is perhaps an extreme example of what can be achieved. (See The Chair of Honeywell on Bringing an Industrial Business into the Digital Age). But there are real dangers in embarking on such rationalisation initiatives with an over-simplistic approach. We believe that enterprise architects have essential roles to play in preparing for and guiding the execution of such initiatives in order to guarantee their success.
Rationalisation Approaches
We’ve seen many different approaches to application rationalisation: breaking down by business capability, by process then by application; a business unit driven application mapping; an application capability-driven approach; an informal best guess as to which Gartner TIME® quadrant applications fit in (Tolerate, Invest, Migrate or Eliminate); etc. All valid and with their own strengths, although we’re not fans of the informal guessing approach! These are, however, essentially just starting points for the rationalisation process. Clarity comes when more in-depth information on the applications estate is supplied, and this is where the enterprise architects can begin to make their mark.
There are several factors that should influence decisions in this area, including:
- Cost
- Business fit
- Technical fit
- Breadth and scope of usage
- Supplier effectiveness
- Vendor Lifecycle status
- Complexity of removal and replacement (interdependencies)
- Support for business differentiation
- Commoditisation in the product arena
Common Mistakes in capturing Business Fit
In reality, we quite often see organisations reduce the process to a set of limited, and easy to gather, criteria. These can often be as basic as business fit, technical fit and cost. There is typically a crude data gathering exercise where business users are asked to score how well each application fits their needs, and alongside this the IT people apply their own technical score. The technical scoring has a good chance of being reasonably consistent and will normally take account of such aspects as the lifecycle status of an application package. But a major problem with the business fitness assessment is that it is subjective, often reflecting a particular user’s recent experience that may not be typical. Furthermore, business users of a system who work in different functions are likely to have different usages, needs and expectations, for example, consider an application such as Workday where it has Finance and HR capabilities, and as a result users with very different needs. Simply averaging their scores will produce meaningless results.
Bringing the business evaluation into the mix is vitally important, but this should be done in a refined way. First, by eliciting the views of people who represent all the business functions that engage with an application and considering their results as separate inputs. Second, by getting them to rate an application with multiple measures: functionality, performance, usability, support, etc, but importantly, in the context of their usage (for HR, for Finance, etc). Follow-up interviews when unexpected scores are registered can be very informative.
Achieving clarity of business/technical fit in respect of all the individual applications in a portfolio will, however, not provide a sufficient basis to launch a rationalisation programme. This is because applications do not exist in isolation; they form part of an organisation’s enterprise architecture. And this is where an enterprise architects’ skills and knowledge should really come into play.
Other Considerations
A poor performing application may, for example, be a module within an integrated ERP suite: replacing its functionality by some other product would be a technical challenge, to say the least. In such cases, it may be better to put this into a longer-term migration plan – decouple over a long period and then remove later. As consultants with one UK organisation, we mapped out the integrations of a core system and then planned a two-year plan to slowly decouple the system (isolating the interfaces over time) as part of several smaller projects. Eventually, the system was able to be retired, saving millions of pounds per year. Bear in mind that even where an application is technically stand-alone, it will interface with other systems, and the cost and effort in ensuring the fidelity and efficiency of these critical links must be taken into account when considering its replacement.
There may be valid business reasons why multiple applications serving the same functional need may not turn out to be candidates for rationalisation. In the case, for example, of a global company, adherence to local market requirements or regulations will often hinder any rationalisation effort, so consolidating to a single platform can be impossible. It’s important to communicate such complexities to business management and set expectations when you reveal how many overlapping systems you have.
Differentiation/Commoditisation
Business differentiation is what makes organisations unique. If you have systems that look good for rationalisation, then it’s worth checking if they enable differentiation. If they do then consider the fit score carefully, for example, are the systems being impacted by technical issues, and consider what would replace them. They may not be ripe for rationalisation but more for consolidation, rearchitecting and/or rewrite. A good example is some of the Excel based applications in asset management that can provide the secret sauce behind key investment decisions. Technically, they may score quite low and be dragged into a retire classification, but they can be critical for differentiating investment decisions.
Commoditisation of products is an interesting area, where previously differentiating applications have become commodity in nature, and as such may be candidates for buying off the shelf rather than managing as a custom developments. The obvious case here is AI where many organisations built their own AI engines, which until a couple of years ago were differentiating. With OpenAI, however, it is in fact the custom Large Language Models (LLMs) that are differentiating. And this also raises considerations of the skills that are required, and whether applications for rationalisation require commodity skills or not. There are inherent costs in both of these, but custom-built applications will generally incur higher costs than commodity, off-the-shelf applications.
Summary
In driving their radical application rationalisation programme, Honeywell had good reasons for stopping when they cut the number of ERP systems to ten. Knowing where to reduce the complexity, and how far to go without damaging the business, requires deep knowledge of the applications and, importantly, of their business and technical context: in short, a qualitative view of the enterprise architecture. As the German philosopher Nietzsche rightly pointed out, “The Devil hides in the Detail”.
Useful Links
The Role of the Enterprise Architect in Application Systems Integration
Why Qualitative Enterprise Architecture Data Really Matters