Digital Service Life Cycle Model

What Is a Digital Service?

A digital service is a defined and managed boundary encompassing the technology and related capabilities required to deliver an outcome for its consumers. It may exist at any level of the technology stack—from a business-facing application to a shared platform, virtual infrastructure, or physical infrastructure—and may serve people, other digital services, or both. Every digital service also has a type—Customer-Facing, Business-Enabling, Platform, or Infrastructure—describing why it exists and whom it primarily serves, independent of which layers it happens to occupy. Digital Service is itself one branch of enterprise service, managed under the DEHSO Model—the branch whose outcome is delivered through a technical interface, distinct enough in its life cycle concerns (software evolution, reliability, security, operability, scalable consumption) to warrant this dedicated model, rather than being managed directly the way DEHSO manages the human-delivered branch: Companion Offering, Enablement, Governance, and Strategy.

Digital services can be built on and operated through other digital services. For example, an application platform may be a digital service in its own right while providing the foundation for one or more business-facing digital services.

The boundary includes everything needed to deliver and sustain the outcome, such as software, infrastructure, data, integrations, operational processes, people, and accountability. A digital service is managed across its entire lifecycle, from design and delivery through operation, evolution, and eventual decommissioning.

Craft is a Ceiling

Digital service life cycle management should be an engineering discipline — not a craft. In craftsmanship, the service is dependent on the practitioner’s capability — it is only as good as the person who built it, and only as maintainable as the person who understands it. That is not a model that survives at the pace modern delivery demands.

Engineering produces predictable results because the system is designed to produce them — regardless of who is executing it. Every service receives a guaranteed baseline. Every activity has a defined owner and a defined outcome. What the human brings determines how far above that baseline the outcome lands — and there is no ceiling on that difference.

The model is deliberately opinionated — and that is the point. A framework leaves the decisions to the implementer. A model makes them. The opinionated choices are what create the predictability; without them, you are back to craftsmanship.

The Same Three Failures, Every Time

Most digital services consistently fail to meet all six things their consumers actually need — the right outcome, on time, at justifiable cost, at reliable quality, with appropriate security, and with an experience they want to return to.

The root cause is three things rarely addressed together: individual capability gaps, where not everyone has the skills the work requires; structural capability gaps, where the systems and practices to compensate were never built; and chronic time and resource pressure that squeezes out capability even when it exists. Address only one and the other two fill the gap. The model is designed to address all three.

The deeper cost is fragility. Knowledge lives in people rather than in the system — when they leave, it leaves with them. When teams grow, the informal practices that held things together stop scaling. The model makes documentation and handoffs first-class activities so capable people spend their time building forward, not reconstructing what should already be there.

Nine Interlocking Building Blocks

The model defines what should happen and who is accountable for it. It is structured around nine interlocking building blocks:

Classification Tiers — the criteria used to assess a service’s risk, criticality, and data sensitivity at the start of Design. The tier governs everything that follows: which processes activate, which activities are required, and what deliverables must be produced. Classification is what makes the model opinionated without being one-size-fits-all.

Phases — the four stages of the digital service life cycle: Design, Develop, Operate, and Decommission. Some services are discontinued before they reach Operate — in Design when the business case does not hold, or in Develop when delivery is cancelled or scope collapses. Early discontinuation is a valid outcome. What varies across services is the processes that execute within each phase; the phases themselves are fixed.

Processes — within each phase, a set of processes that varies by classification tier, by the service’s type, and by which layers it spans. A low-classification Business-Enabling service activates a lighter set than a high-criticality Platform service running across Application through Data Center. Each process has a defined purpose, a defined trigger, and a defined completion condition.

Activities — within each process, discrete units of work each producing a specific output. Every activity is explicitly owned by a worker, with the tooling or criteria to support it. That ownership is auditable and designed to be reviewed as capabilities evolve — what matters is that every activity has a defined owner, not that the assignment is permanent.

Workers — a human or machine holding the capability an activity requires. The model defines eight capability sets: Business Analysis, Experience Design, Architecture, Security, Development, Quality Assurance, Operations, and Project Management. Capabilities are independent of layers — a Security worker may operate anywhere from Application down to Data Center; an Architect may span all seven. A worker qualifies for an activity by holding the relevant capability, not by carrying a title. In small teams, one person holds multiple capability sets. Which capability sets an engagement actually draws on, and how heavily, still depends on the service’s type and which layers are in scope — a Customer-Facing service spanning Interface and Application leans differently on those eight sets than an Infrastructure service spanning Virtualization, Hardware, and Data Center. The Project Manager is the coordinating worker: it activates processes by classification tier, dispatches activities to the worker with the right capability, and tracks life cycle state. That role may itself be held by a person, a machine, or both.

Deliverables — every activity produces a deliverable. Documentation and the running service are in equal standing: requirements, design decisions, architecture records, security assessments, operational runbooks, and incident records are deliverables; so is the deployed system at every increment. Because activities execute continuously in small iterations, deliverables accumulate the same way — not as a big-bang release at the end of a phase. Each increment is complete: the code runs, the documentation reflects it, and the knowledge is in the system rather than in someone’s head. That continuity is what makes the life cycle survivable across team changes, reorgs, and time. Which deliverables a given service actually produces follows the same rule as everything else in this section: they are scoped by its type and by which layers it spans, not produced uniformly regardless of either.

Type — the four recurring reasons a digital service exists, as defined in The Types of Digital Service: Customer-Facing, Business-Enabling, Platform, and Infrastructure. Type and Layers, below, are the model’s two structural axes: type describes why a service exists and whom it primarily serves; layers describe what its provider directly manages to deliver it. Together they decide which processes, activities, workers, deliverables, and patterns actually apply — a Customer-Facing service under competitive pressure needs a different cadence and pattern set than a Platform service whose main obligation is stability for the services depending on it.

Layers — the seven layers of a digital service: Offering, Interface, Application, Platform, Virtualization, Hardware, and Data Center, as defined in the general layer model. Each layer has its own activities, deliverables, and worker assignments. Not every service requires active work at every layer — a service may rely on a shared Platform, for instance, and carry no Platform activities of its own. Layers are what give the model its full-stack reach: the same life cycle framework applies whether the work is happening at the Offering level or the Data Center level.

Patterns — reusable service designs activated by requirement types, scoped to whichever type and layers a given service spans. Functional requirements point toward structural patterns; non-functional requirements toward others — availability, scalability, data residency, compliance, auditability. Patterns define the service throughout its life cycle, not just at design time. Across every phase — Design, Develop, Operate, and Decommission — the service is continuously validated against its patterns through an OODA loop of observe, orient, decide, act. When requirements are met, patterns are confirmed. When they are not, patterns are challenged on evidence: rejected, modified, or complemented. The model does not protect patterns — it uses them as the baseline against which the service is measured.

Still Developing

The model is not complete, and it is not meant to stay that way — the intent is for it to stabilize as it matures, not to keep changing indefinitely. It is not there yet. It develops alongside the organizations that adopt it — real adoption surfaces what it needs next, and early adopters get a more capable foundation with each iteration.

From Specification to Operating System

The model has value on its own — a clear specification of what should happen and who is accountable for it, usable as-is by any organization willing to run it by hand. The DSLC Platform is what turns that specification into an operating system, removing the overhead of making it happen. Both are developed under Alpha Phase Studio AB.

Putting them to work inside an organization is a different kind of work again. DSLC Team Enablement builds the internal capability to run the model, Solution Architect (Interim) runs it hands-on for a specific service, DSLC Platform Custom Development adapts the tooling to how your organization actually delivers, and where the model itself does not quite fit, DSLC Model Custom Adaptation adapts the model.