The Types of Digital Service

Not every digital service an enterprise runs exists for the same reason. A checkout flow, an internal expense system, a shared application platform, and a rack of virtualized compute are all digital services in the sense The Layers of a Digital Service describes — each with an Offering and an Interface, each occupying its own slice of the stack. But that layer model says nothing about why a service exists, and the DSLC Model needs an answer to that question too: the right process weight for a checkout flow is not the right process weight for the platform it happens to run on.

The DSLC Model currently distinguishes four types that recur across enterprises of very different shapes and sizes. They form a separate classification axis from the layers a service directly manages. The two axes are related but not equivalent: type describes why the service exists and whom it serves, while layers describe what its provider manages to deliver it. That distinction is exactly what the DSLC Model needs to make its classification and patterns concrete rather than generic.

Four Recurring Types

A service is classified by its primary consumer and promised capability, not by the team operating it or the implementation layers behind it. Classification is always relative to the enterprise whose directly managed portfolio is being examined.

If a service primarily serves consumers outside that enterprise, it is Customer-Facing regardless of the technical capability it exposes. If it serves internal business functions, it is Business-Enabling. Services for internal technical teams are classified as Platform or Infrastructure according to the level of capability they provide.

A commercial PaaS is therefore Customer-Facing within its provider’s portfolio, even though it exposes platform capabilities. Within the customer’s portfolio, that PaaS is an external dependency rather than a directly managed Platform service. Where one managed service still appears to fit multiple types, it may be bundling offerings intended for different consumers.

These types classify the digital services an enterprise directly manages as part of its own service portfolio. Externally provided dependencies remain digital services in their own right, but fall outside the consuming enterprise’s directly managed service portfolio. Within that scope, adoption still tends to follow a pattern: most enterprises manage at least one Customer-Facing or Business-Enabling service directly, a real internal Platform tends to appear only once enough services would otherwise duplicate the same capability, and Infrastructure is managed directly only where the economics or constraints actually favor it over buying it — but these are tendencies, not guarantees. A government department, a holding company, or a traditional manufacturer may manage internal services without operating a customer-facing one of its own at all.

Related to, but Different from, Team Topologies

Readers familiar with Team Topologies may recognize some parallels, but the two classifications do not map one-to-one. Customer-Facing services are often owned by stream-aligned teams, and Platform services are often owned by platform teams — beyond that, the axes diverge.

A Team Topologies enabling team helps other teams acquire capabilities, typically through temporary coaching or facilitation; it is not the equivalent of a Business-Enabling service such as payroll or finance. A complicated-subsystem team owns work requiring deep specialist knowledge — a mathematical model, a codec — which may exist at any service layer rather than specifically in Infrastructure. Stream-aligned teams can also serve internal value streams, not only external customers.

Team Topologies classifies teams according to their purpose, cognitive load, and interaction with other teams. This model classifies services according to the capability they provide and the consumers they primarily serve. Changing which internal team operates a service does not change its type; only a change in its primary consumers or promised capability does.

Why the DSLC Model Needs This

A model that treats every service the same regardless of type ends up either too heavy for the services that do not need it, or too light for the ones that do. Classifying a service by type — alongside the risk, criticality, and data sensitivity tiers the DSLC Model already uses — lets its processes and patterns actually differ where the needs differ: a Customer-Facing service under active competitive pressure justifies a different cadence and a different set of patterns than a Platform service whose main obligation is stability for the services depending on it. Type is one input into that weighting, not a proxy for importance on its own — a Business-Enabling service handling regulated data can outweigh a Customer-Facing one that carries none.

This is what keeps the model concrete rather than aspirational. It is not enough to say a service has activities and owners; the type is part of what decides which activities matter most and how heavily they should weigh.

The Contracts Between Them

These types frequently depend on one another — a Customer-Facing service may depend on Business-Enabling systems behind the scenes, and both may run on an internal Platform that itself depends on Infrastructure. What one type owes another across that dependency — availability guarantees, change notice, support boundaries — deserves to be made explicit rather than assumed. That is worth its own post; I am not going to promise here what it will conclude, only that the gap is real and I intend to come back to it.