The Types of Enterprise Service

The Types of Digital Service classifies Digital Service — the branch of enterprise service whose core outcome is delivered primarily through a technical interface. Technical interfaces bring their own life cycle concerns — software evolution, reliability, security, operability, scalable consumption — distinct enough that this branch gets its own dedicated life cycle model, the DSLC Model. But Digital Service is a branch of enterprise service, not a category outside it. When a Digital Service Still Needs a Human landed on a boundary: some enterprise capability delivers its outcome differently, primarily through people rather than a technical interface. This post names four recurring human-delivered types that make up the other branch of enterprise service, managed directly by the DEHSO Model rather than through DSLC’s specialized life cycle.

Classifying an enterprise service is a two-stage test. First: what actually delivers the promised outcome — a scalable technical interface, or situated human judgment, relationships, and organizational authority? That decides the branch. Second, within whichever branch it lands in: who is the primary consumer, and what capability is promised? That decides the type. Digital Service answers the second question with four types of its own — Customer-Facing, Business-Enabling, Platform, and Infrastructure — because a technical interface can serve very different consumers. The human-delivered branch answers it with the four types below.

The same hierarchy, written out:

Enterprise Service
├── Digital Service — core outcome delivered primarily through a technical interface
│   ├── Customer-Facing
│   ├── Business-Enabling
│   ├── Platform
│   └── Infrastructure
└── Human-Delivered Service — core outcome delivered primarily through people
    ├── Companion Offering
    ├── Enablement
    ├── Governance
    └── Strategy

The Human-Delivered Branch

Within this branch, the same second-stage move applies as it does within Digital Service: classify by primary consumer and promised capability, not by who happens to staff it or what it is called locally. Four types recur across enterprises of very different shapes and sizes.

These are the four types identified so far; the classification is not necessarily exhaustive. Additional types may surface as the DEHSO Model is tested across more enterprises. None of these four are Digital Service, though several of them can have an offering and an interface in the ordinary sense — a catalog, an intake form, a portal. A Companion Offering extends a specific digital service’s promise where contextual judgment, implementation work, or relationship continuity cannot — or should not — be standardized into its technical interface; it is anchored to that service without being part of it. Unlike a Companion Offering, Enablement, Governance, and Strategy need not be anchored to a specific digital service; they may operate at service, domain, or enterprise scope. Each may itself be supported by a digital service — a policy engine, a learning platform, a portfolio tool — but that digital service facilitates the work rather than supplying the human capability that fulfills the enterprise service’s core promise.

The Branches Also Differ in Economics

Having a catalog, an intake channel, or repeatable engagements is not what separates the branches, since types on either side can have those — it is the branch test itself that decides it, not these surface traits. What the branch test does explain is a further asymmetry: Digital Service can serve additional consumers with relatively little additional human coordination. Human-delivered services remain constrained by human attention, judgment, relationships, or authority, even when forms and portals streamline access.

That asymmetry shows up in how services in each branch tend to be funded and priced, though this is an observed tendency rather than a hard rule — plenty of enablement and advisory work is billed by the workshop, assessment, or engagement. A Companion Offering is more often priced separately, because its delivery capacity scales with specialist time rather than with the digital service’s cost structure. Enablement, Governance, and Strategy are more often capacity-funded — staffing, budget, and opportunity cost — because their value accrues across teams or across the portfolio rather than through individual consumption transactions.

Related to, but Different from, Team Topologies

The two classifications answer different questions. Team Topologies describes how software-delivery teams are structured and how they interact; this taxonomy describes the capability being promised and to whom. Enablement overlaps directly with what Team Topologies calls an enabling team: helping other teams acquire a capability rather than operating a system on their behalf, with any one engagement staying temporary even if the enabling function itself is long-lived. Governance and Strategy generally sit outside Team Topologies’ unit of analysis altogether, and a Companion Offering does not map onto a team shape at all — it is a promise made to a customer, not a way of organizing the people who deliver it.

Where This Leaves the Portfolio

An enterprise’s real portfolio, then, is one enterprise-service taxonomy with two branches beneath it, not five peers on a flat list. The DEHSO Model manages the whole of it. Where a service lands in the Digital Service branch, DEHSO applies the DSLC Model as the specialized life cycle for that branch’s distinct technical concerns; where it lands in the human-delivered branch, DEHSO manages it directly, because Companion Offering, Enablement, Governance, and Strategy do not carry the same technical life cycle concerns that justify a separate model. Every type, on either branch, still needs to be identified by primary consumer and promised capability before anyone can reason sensibly about how it should be funded, staffed, or measured — that test just runs one level down from the branch test, not in place of it.