Skip to content

The enabling change is the possibility that AI reduces the effort of learning a demand, preparing its context, producing and evaluating outputs, and coordinating decisions. That could change the economics of keeping capacity across projects: less work would have to be rebuilt for each purchase and each hand-over between executors. The organizational implication is to maintain recurring capacity that turns intentions into advances that can be bought. Delivery Units, Execution Pools and policies relate each demand to that capacity, without imposing an organization chart.

One person developing for another can already offer discovery, construction and continuity. As new demands arrive, they have to decide what they can take on, which references they reuse and how they answer for what they delivered. Recurring capacity starts in that relationship; it does not require departments or a self-service platform.

In a larger operation, the provider keeps context, agent configurations, evaluation criteria, professionals and means of coordination that can serve many units. That takes work before and between contracts: preparing resources, updating references, calibrating evaluation and reserving capacity for existing obligations. The organization is oriented by the experience offered: an accessible entry point, a useful first advance, clear conditions for continuing and delivery of the authorized scope. The buyer does not have to organize each hand-over between resources.

This can use persistent teams, dedicated resources and shared pools. The change proposed is in the relation between the capacity kept and the commitments consumed. Its observable sign would be serving successive demands with less repeated preparation and less coordination imposed on the buyer, while keeping quality and complete cost.

The engine describes operational functions. Realizing them in an organization means identifying responsibilities, without turning each concept into a job title.

Responsibility Question that needs an answer
Understanding the demand Who clarifies the intended result and its constraints?
Commitment to delivery Who answers for the scope assumed and for continuity?
Coordination Who relates work, dependencies, evaluations and decisions?
Execution Who produces the outputs under the agreed conditions?
Evaluation and acceptance Who may examine and accept the relevant result?
Capacity Who deals with the availability, context and eligibility of resources?
Economic decision Who authorizes, revises or stops commitments?
Rules of the operation Who may define policies and handle exceptions?

One person can hold several of these; elsewhere, competence, capacity or authority may call for separating them. Responsibilities outside the provider count too: a business rule or an access can depend on the buyer, and that dependency does not remove the responsibility for following its effect on the delivery.

The Delivery Unit gives a reference for keeping the commitment through changes of execution. Its identity should not depend on which professional, agent or set of resources is acting at a given moment, which makes it possible to allocate differently by stage. That does not mean all work should change executor; keeping resources across several stages can be better when continuity of context matters. And responsibility for the service must not be spread so thin that nobody can deal with a divergence.

Records, contracts and artifacts help preserve context but do not guarantee immediate understanding. Part of it can depend on experience with the system, interaction with users and interpreting earlier decisions. An organization may need continuous domain references even when it shares execution capacity. That requires neither a fixed team per unit, nor showing that persistent teams stop being useful. The organization should also avoid concentrating all understanding in one person with no alternative for continuity; the model makes that condition visible without assuming documentation removes the dependency.

Dedicated resources, pools and mixed arrangements

Section titled “Dedicated resources, pools and mixed arrangements”

Pools can organize capacity shared across demands; dedicated resources can preserve availability and context for a specific set of work. The model allows both. In an organization built around pools, one group of specialists and agents serves discovery for many projects, another design, others implementation and evaluation, with the context following each demand to the eligible resources. AI could reduce the effort of preparing that context and carrying out the local cycle, widening the cases where this organization pays off. Where tacit knowledge, dependencies or reconstructing understanding dominate the cost, dedicated continuity may remain the right answer.

Sharing widens allocation options and requires more preparation and coordination; dedication favours continuity and limits availability for other demands. Neither structure is universally superior, and counting shared resources or dedicated teams does not show effective delivery capacity. What should be assessed is accepted results, total cost and commitments met.

The Execution Policy bounds the actions and decisions permitted to resources, and Governance establishes who may define those conditions. An organization can delegate choices of execution without delegating a change of result, access to environments or economic authorization. Centralizing every decision increases waiting; distributing decisions without a reference produces incompatible commitments. A system can plan, evaluate, authorize and carry out next steps within explicit delegations; the organization still answers for effects and exceptions, and buyer, provider and environment keep distinct scopes of authority even when they delegate.

The capacity to produce outputs has to be related to the capacity to evaluate them and decide on acceptance. An organization that expands production without dealing with that can accumulate results waiting to be examined, and the answer must not be to lower the rigour of acceptance to keep up an appearance of flow. Evaluation should not appear as a residual activity for whoever is free after production.

Consuming delivery as a service can reduce the direct coordination the buyer has to do. Clarification, conditions of access and decisions outside the mandate may still need them; business decisions, acceptance and continuation can also be delegated when their scope is defined. If a decision is pending, the demand should show its scope and effect, and the provider should neither assume every doubt will be resolved internally nor hand the responsibility for continuity back vaguely. In internal relationships these boundaries can sit between teams of the same organization; the absence of an external transaction does not remove budget, priority or the recognition of the expected result.

Someone wants online bookings. The provider offers discovery, organizes requirements, prototype and architecture decisions, and returns with conditions for building. There is no need to assign a different person to each transformation. A hybrid composition can use a professional to clarify a rule and agents to produce alternatives and run checks; another can carry out the route and its decisions automatically within the mandates. Responsibility for the service stays identifiable in both, and technical autonomy grants neither the buyer’s commercial authority nor the environment’s permission.

When another barbershop arrives, the same capacity can reuse procedures and checks for overlapping bookings, but service durations, professionals, access and conditions of use must match the new unit, and reuse does not authorize sharing private data or copying one client’s business decisions to another. An accepted discovery can close the commitment without construction: the organization delivers its artifacts and deals with remaining obligations, instead of counting the case as lost. Its incentives should recognize the useful advance and a well-founded decision to stop, not only conversion to construction.

Hours, executions or artifacts give operational information, but do not on their own show quality, acceptance or benefit. An organization following the model should be able to see where there is waiting, which conditions cause rework and how consumption relates to deliveries. Raising the utilization of one resource can create waiting in evaluation; lowering the cost of one activity can move preparation onto someone else. Incentives should not reward the formal closing of stages alone, since inadequate criteria can lead to outputs accepted on the record that do not serve their purpose.

A bounded adoption can use existing functions and make their relations explicit in some demands, which allows the cost of recording, deciding and transferring context to be examined before expanding. The model provides no evidence that reducing or replacing teams would be the right decision, and it does not require every demand to use the same design. The organizational hypothesis is that separating demand, coordination and the composition of execution supports a recurring capacity the buyer can call on without building an operation of their own. Signals to follow include preparation effort per demand, time to form offers, the load of exceptions, continuity of context and the participation required of the buyer. Fewer roles or more agents do not confirm the hypothesis. These are proposed, conditional implications; they prescribe no organization chart, replacement of teams, reduction of people or universal structure.

Software Delivery as a Service is a proposed model by Renan Deves and Marcelo Scheidt, Independent Researchers. See the paper for citation and license.