Introduction
As Enterprise Architects we can play an important role in enabling technology-driven business transformation, and our insights, based on what we understand about the organisation, ought to support critical business decisions. However, the reality for many organisations is that their enterprise architecture does not play the key role in decision support that perhaps it should. One reason for this, especially in organisations with less experienced architects, is that the architects oversimplify the complexity of the organisation, with the result that their insights are interesting but not useful.
As enterprise architects, we strive to simplify things, especially for communication purposes, but the true challenge is simplifying complexity without losing the context that gives it value. An oversimplified problem can lead to a misinformed decision.
Rationalisation Example
As an example, and this is a common one, a company is looking to rationalise its application portfolio, with the goal of reducing costs and simplifying operations. Enterprise architecture clearly has a key role to play here.
Enterprise architects can readily map applications to capabilities. They are usually aware of the applications used by teams like Finance, HR, Trading, and so on. They can then show the business how these applications align with the company’s core business capabilities. For example, a company might identify three essential business capabilities and map its existing applications to these capabilities:
-
- CRM: Salesforce, Sugar CRM
- Financial Management: QuickBooks, SAP
- Product Inventory: Brightpearl, Oracle Fusion Cloud Inventory
Based simply on this mapping, the architects can conclude that there are duplicate applications, so they can easily be tempted to claim that there are opportunities to remove some of them. Their opinion is formed solely on the fact that multiple tools serve the same business capabilities, but without any consideration of how these tools actually support the organisation’s business processes in these three areas. They may acknowledge that more investigation is needed, but they often set expectations with business leaders that there is easy scope for rationalisation.
So, using the above example what have we oversimplified?
- Overlooking Process Integration: Digging deeper you may find that Salesforce is deeply integrated with the company’s marketing and sales workflows, while Sugar CRM is more aligned with customer service operations. QuickBooks might be used by the finance department for budgeting, while SAP supports procurement and supply chain management. Brightpearl, on the other hand, may be critical for inventory tracking and order management in a particular department that needs fine-grained control.
- Ignoring Organisational Usage: A simplistic view overlooks specific needs within the organisation, and critical business processes may have tight dependencies with the applications. For example, the finance team, or multiple finance teams in the organisation, may rely on certain features in QuickBooks that others in the company don’t use, meaning that replacing this application with SAP could disrupt their particular process.
- Process Complexity: Simplifying the application landscape based on business capability ignores the underlying processes that these tools enable. The real value lies in understanding how the applications enable cross-functional processes, data flows, and collaboration between teams. By rationalising the application portfolio based purely on business capabilities, the company might inadvertently create gaps or inefficiencies in operational processes.
So, oversimplifying the problem by mapping business capabilities directly to applications, the company in our example risked missing key information that informed decisions need. A deeper understanding of the processes that used the applications and the specific organisational context would have provided a more informed, thoughtful approach to application rationalisation.
‘Cloud is cheaper’ Example
As another example, many companies were badly burnt with the ‘Cloud is cheaper’, ‘we can lift and shift’ message that was widely promoted a few years ago. Enterprise architecture had a major role in identifying possible opportunities, with business cases setting expectations that costs could be reduced. However, companies soon discovered that legacy systems needed significant and expensive refactoring to work in the cloud. Many applications had been designed with on-premise infrastructure in mind, so when applications were simply lifted and shifted, it meant they didn’t take advantage of cloud-native features such as auto-scaling, cost-efficient resource allocation, and enhanced performance tuning. As a result, these systems often ran inefficiently in the cloud, leading to higher-than-expected costs, such as excessive compute resources and storage consumption. While many companies found benefits in moving to the cloud, too many businesses didn’t.
Managing Expectations
This is really all about expectation management. If you don’t have the detail to back up your high-level insight, i.e. you don’t know the processes and organisational functions that underpin your business capabilities, then be absolutely clear that the insight is purely indicative and focus the next phase of work on investigating the usage of the applications. Ensure significant investment decisions are not made based on the high-level insight alone. If you have the detail to back up the business case, then you can tell people they can make a confident investment decision.
Oversimplification can lead to poor decisions, costly failures, and unrealistic expectations. As enterprise architects, our expertise lies in simplifying complexity while preserving its core essence. Experienced architects clearly communicate what information the audience is looking at, they know when it is interesting information (‘There could be something in this’), and they know when it is useful information (‘there is something in this’) that is enough to drive a decision.
Useful Links:
The importance of modelling business functions and capabilities, not just business processes
Why Qualitative Enterprise Architecture Data Really Matters
Why Enterprise Architects should guide IT Rationalisation Programmes
Applications to Business Capabilities – Why Essential models via Process