Perhaps your organisation justifies the cost with an uncomfortable acceptance that integration is somehow needed? Perhaps you have enough integration capability inertia to make the costs palatable (or appear normal) for now? Perhaps you live in hope that there is an alternative to costs? That integration can be monetised and provide revenue? For instance, by charging some nebulous customer segment for access to your data?
If your organisation is still focused on business cases, you'll see this cost centre view of integration get a lot of business case focus. At business case time, it is common for organisations to take a quick and dirty, tactical, and isolated attempt at articulating the ROI of integration technology or action. These tactical attempts often result in data of poor enduring quality as the data is solely focused on getting the business case approved (after which the data is effectively discarded).
Well, all if this sounds familiar, it's time to get down to fundamentals...
Fundamental 1 - You have to connect to things. More and more things.
You do have to connect things. Though connectivity is, in some areas, getting easier, the number of things to connect is rising in volume. Enterprise architectures are becoming more granular and more dynamic. In addition, solutions are more fluid and flexible so integrations need changing, refactoring, reconnecting at speed. So not only do you need integration capability. It has to be agile.
Fundamental 2 - Bad integration pushes cost everywhere else.
If things are not connected or are badly connected (e.g. inefficient architecture, unreliable runtime integrations), or take too long to connect, the costs rise elsewhere. For instance:
- Delivery - If you're integrators are slow, you can get less done in a sprint. Or your projects take longer and in turn those longer projects need PMs, BAs, architects, Testers, Test Managers, etc for longer. This increases your costs and slows time to market!
- Front line services - If your data is not where it is supposed to be, is of bad quality or out of sync, your front line are less efficient. They take longer to carry out tasks and customers are put off transacting. This increases your costs and impacts revenue!
- Back office - If your data is not where it is supposed to be, is of bad quality or out of sync, you have to have teams of back office staff armed with manual procedures to copy data between systems, fix bad quality data and otherwise trawl through customer complaints. This increases your costs!
- Customers - If your customers are served slowly or they see bad data then they get frustrated, lose trust, and leave. This impacts your revenue!
Fundamental 3 - Front-footing beats drifting defence
Rather than trying to measure to the value of integration in an ad-hoc manner when you need to spend (or business case), start gathering and reporting meaningful integration value metrics for your business. You may not hit the mark first time but you can make a start and improve.
Think about gathering...
- Direct costs of integration technologies and human resources (delivery through ops).
- Indirect delivery costs. e.g. delays and wait times for other teams and roles in project/product delivery.
- Indirect front-line costs. e.g. surveys of front-line staff to capture/measure data access efficiency and customer impact.
- Indirect back office costs. e.g. the numbers of manual processes and associated resource costs.
- The things that are important for your specific business today, for your strategic direction, and for your customers.
Gathering metrics helps you learn about your business and is a stepping stone to targeted improvement.
And for those that are already on this journey, think about automating your value metrics where possible. For instance, by building meta-data into your delivery processes and runtime integrations to track costs and value in real time.
If you wish to talk about best practices and how your organisation can sustainably track and report integration value, message Ian Vanstone on LinkedIn and mention Integration ROI.