Technology Concentration

Technology concentration arises when important services share a platform, a software component, a database, an identity service, or a way of connecting, so that a fault in that shared element affects them together. The suppliers involved may differ, and the business functions may look unrelated, yet they depend on the same technical foundation. When that foundation fails, the failure does not stay within one service. It travels along the shared dependency to every service that uses it.

This form of concentration is often invisible in organisational charts, because it lives in architecture diagrams rather than in contracts. Two teams may believe they run independent services, while both call the same authentication service, write to the same database cluster, or pass through the same integration layer. Mapping the technology underneath the business services is therefore the core task, and it requires input from the people who build and run the systems, not only from procurement records.

One form is a shared platform: several services run on the same cloud platform, the same core banking or insurance system, or the same workflow engine. Another is a shared component: a payment library, a messaging service, a fraud scoring model, or a document generation tool used across services. A third is a shared connection method: services that all reach customers, counterparties, or data sources through one gateway, one network provider, or one application programming interface pattern.

Legacy technology adds a further form. A firm may depend on an ageing system that few people still understand, or on a component whose vendor support is limited. In that case the concentration is not only about shared use. It is about shared fragility: the same hard-to-maintain element underpins several services, and fixing it under pressure is difficult because knowledge and parts are scarce. Naming that fragility is part of the assessment, even where replacing the element is a long project.

A shared component spreads failure because services assume it will work. A customer login service that fails does not only block one product. It blocks every product that requires login. A shared database that becomes unavailable does not only affect reporting. It affects every transaction that needs to read or write a record. The blast radius is set by the architecture, not by the business priority of any single service.

Software updates can spread failure in a similar way. A change to a shared library, a configuration change in a shared platform, or a certificate expiry in a shared gateway can affect many services at once, even when each service was tested in isolation. That is why change management for shared components deserves attention in a concentration assessment. The question is not only what the component does when it fails, but how changes to it are tested across all of its users before release.

Consider an illustrative custody service. Client instructions arrive through a portal, are validated, and are passed to settlement systems, while records are kept for reporting. Different suppliers might provide the portal, the validation tool, and the reporting tool. If all three tools depend on the same identity and access service, supplied as a shared component, a failure in that service could prevent clients from logging in, prevent staff from validating instructions, and prevent reporting from running, all at once.

The business impact in that illustration is wider than a portal outage. Work queues build up, settlement deadlines approach, and staff cannot easily tell clients what has happened, because the same access problem affects internal tools. A technology map would show the identity service as a convergence point. It would also prompt questions about fallback access, about manual procedures, and about whether the most urgent instructions can be processed through an alternative route while the shared service is restored.

Testing shared components in isolation can hide concentration, because each test passes while the shared element works. Scenario testing that removes the shared element, or degrades it, is more revealing. A firm can rehearse what happens when the shared database is unavailable, when the gateway returns errors, or when the identity service is slow, and observe which services are affected and in what order. Those observations often surprise teams that thought their services were independent.

Testing also reveals hidden dependencies. A service may call a shared component indirectly, through another service, and that indirect call may not appear in its own documentation. An incident or a test that breaks the shared component exposes the indirect link. Recording those links after a test, rather than treating the test as a one-off exercise, improves the map for the next assessment and for the next change.