The service relationship model, supply chains and ecosystems

No organization provides services entirely on its own. A hospital depends on electricity, network carriers, software vendors, medical device makers and staffing agencies. A small online shop depends on a hosting platform, a payment processor, a courier and a marketing tool. Each of these is a service relationship, and together they form chains and networks through which value flows. This lesson explains the service relationship model, the idea of supply chains and ecosystems, the different kinds of relationship organizations have with suppliers and partners, and the arithmetic of dependencies.

The service relationship model

Lesson 3 showed that provider and consumer are roles, and that the same organization plays both in different relationships. The service relationship model makes this explicit. An organization receives services from its providers, combines them with its own resources to create new products and services, and provides those to its consumers, who may in turn use them to serve their own customers.

In this model, the outputs of one relationship become resources in the next. The retailer's hosting service is a resource in its shopping product. The retailer's shopping service is, in turn, a resource in a household's weekly routine. Problems and improvements travel along the chain: a faster payment processor improves the retailer's checkout, which improves the household's experience.

Supply chains, value networks and ecosystems

When relationships form a sequence, people speak of a supply chain. In digital services, the structure is usually more of a network than a chain: many providers and consumers connected in many directions, often called a value network or service ecosystem. A mobile app ecosystem, for example, connects device makers, operating system vendors, app developers, payment providers, advertisers, network operators and users.

ITIL (Version 5) gives more attention to these digital ecosystems, recognizing that value is often co-created by many organizations at once and that no single party controls the whole experience.

Suppliers and partners

Organizations relate to their providers in different ways. A useful spectrum runs from basic relationships, through cooperative ones, to partnerships:

• Basic relationships: the provider offers standard, often commodity services, and the consumer takes them largely as they are. Buying a standard cloud storage plan is an example. Relationship management is light.
• Cooperative relationships: provider and consumer work together more closely, sharing some information and adapting offerings. A managed service provider running a client's network with regular reviews is an example.
• Partnerships: the parties share goals, risks and sometimes rewards, plan jointly and invest in the relationship. A hospital and a technology firm jointly developing a new patient system are partners.

No type is best in all situations. A partnership with every supplier would be exhausting and expensive. Organizations usually reserve partnerships for the few relationships most critical to their strategy and keep commodity services basic. The skill lies in choosing the right type for each relationship and investing accordingly.

Dependencies and their arithmetic

When a service depends on several others in series, all of them must work for the service to work. The availability of the combined service is roughly the product of the individual availabilities. This explains why a service built on many components can be less available than any one of them.

Redundancy works the other way. If a service can use either of two independent components, it fails only when both fail. The combined availability is then one minus the product of their unavailabilities.

These calculations assume failures are independent, which is not always true. Two payment processors hosted in the same cloud region may fail together. Real availability planning looks for such common causes. The simple formulas are still valuable for showing why chains are fragile and where redundancy helps most.

Managing an ecosystem of providers

As the number of providers grows, coordinating them becomes a challenge of its own. Some organizations appoint a service integrator, an internal team or external firm that manages multiple providers as a single, coherent service for consumers. This approach is often called service integration and management (SIAM). Whatever the model, a few habits help:

• Map the chain: know which providers each critical service depends on, including providers' own key suppliers where possible.
• Align agreements: make sure service levels in supplier contracts support the service levels promised to consumers.
• Share information: incidents and changes at one provider often affect others; agree how to communicate.
• Plan for exit: know how you would replace a provider if needed, to reduce lock-in risk.
• Review regularly: hold joint reviews for services that span several providers.

Dependencies beyond technology

Supply chains are not only about technology. Services depend on people, information and organizations as well. A call center outsourced to a partner depends on that partner's staffing levels and training. A payroll service depends on accurate data from the consumer's HR system. A delivery service depends on roads, weather and local regulations. When mapping a service, include these non-technical dependencies too, because they fail just as often and are frequently overlooked.

Geography and law matter as well. A provider may rely on staff or data centers in another country, which affects data protection, time zones for support and exposure to local events. Organizations in regulated sectors, such as health and finance, are often required to understand and manage these dependencies, including those of their providers' own key suppliers. Regulators increasingly speak of "third-party risk" or "outsourcing risk" and expect organizations to have plans for a supplier failing or leaving the market.

A dependency map does not need to be complicated to be useful. A simple diagram showing each critical service, the internal teams and external suppliers it relies on, and the agreed service levels at each link, is often enough to reveal single points of failure and mismatched promises. Reviewing the map once a year, and whenever a major supplier changes, keeps it accurate.

Mapping also supports conversations with sponsors. Showing that a promised availability target depends on a supplier contract that falls short turns an abstract risk into a concrete decision: pay for a better contract, add redundancy, or agree a lower target with consumers. Each choice has a cost, and the map makes that cost visible.