Skip to content

These are the working definitions of a proposed model. Each entry first states what kind of thing the term names, because the model distinguishes carefully between units, specifications, mechanisms, functions and the information that supports decisions. Where a term has its own explanation, the entry links to it, and that page links back here.

You do not need these terms to follow the idea. The model explains it through a single demand first and introduces the vocabulary as it becomes useful.

Products of work. Concrete outputs, such as requirements, prototypes, code, and tests, available for evaluation or later use.

Read more: Artifacts.

Economic decision mechanism. A decision point about economic commitment: to continue, revise, or stop.

Read more: Commercial Gate.

Unit of transformation. A bounded transformation that consumes inputs and produces outputs that can be evaluated.

Read more: Delivery Stage.

Representation of the demand’s situation. The current situation of a Delivery Unit, relating progress, pending items, dependencies, and the conditions for continuing.

Read more: Delivery State.

Tracking unit. A bounded demand whose progress and state are managed individually. It may have dependencies. It is not a unit of charge.

Read more: Delivery Unit.

Exception-routing mechanism. Routes a question to the competence or authority it requires when it exceeds the scope available.

Read more: Escalation.

Assessment activity. Examines outputs and evidence against the relevant criteria to support the Quality Gate decision.

Read more: Evaluation.

Decision-support information. Information that supports evaluation and decisions. It can also reveal uncertainty that was previously unknown.

Read more: Evidence.

Execution policy. Rules for the eligibility, selection, autonomy, and supervision of execution, within the authority and scope of decision that have been delegated.

Read more: Execution Policy.

Structure for organizing capacity. A set of eligible resources shared across demands to organize recurring capacity, while preserving the context and constraints of each piece of work.

Read more: Execution Pools.

Execution resource. A person, agent, or arrangement eligible to perform work, including decisions within delegated authority.

Read more: Execution Resources.

Operational function. The articulation of execution, evaluations, dependencies, returns, and decisions. The model assigns this function to the Orchestrator.

Read more: Orchestration.

Rules and responsibilities. Establishes authority, delegation, review of conditions, and responsibility for the effects of the operation.

Read more: Governance.

Flow coordination function. The articulation of state, dependencies, execution, and decisions, carried out by the Orchestrator.

Read more: Orchestration.

Operational function. The function that coordinates states, resources, evaluations, and transitions. It may plan and replan within its authority.

Read more: Orchestration.

Intended result. The intended result. Software delivery and business effect must be distinguished explicitly.

Read more: Outcomes.

Setting commercial terms. Establishes price and charging in relation to the contracted object, the commitment, and the allocation of responsibilities.

Read more: Pricing.

Mechanism for revising commitments. Expanding or revising commitment as the demand becomes better defined.

Read more: Progressive Commitment.

Mechanism for updating estimates. Updating estimates as context, artifacts, and evidence change.

Read more: Progressive Estimation.

Technical decision mechanism. A decision on technical or quality acceptance, distinct from authorization to spend.

Read more: Quality Gate.

New-attempt mechanism. A bounded re-execution, justified by the conditions and respecting the authorization, limits, and effects of the previous attempt.

Read more: Retry.

Selection and dispatch mechanism. Applies the Execution Policy to authorized work, eligible resources, and actual availability.

Read more: Routing.

Operational, economic, and commercial model. A model for consuming software delivery on demand whose enabling hypothesis is an AI-driven change in the cost of learning, producing, coordinating, and deciding. Organized capacity of people and systems performs bounded advances that produce outputs and information for new commitments. Progressive consumption and the production arrangements behind it are ways of realizing that possibility.

Read more: The model.

Delivery operating system. The operational composition of coordination, execution, evaluation, and continuity that carries out demands and maintains the capacity to provide the service. The model does not claim to coin the term.

Read more: Software Delivery Engine.

Specification. The entry conditions, execution policy, expected outputs, and acceptance criteria of a stage. “Contract” names the specification; it does not imply a separate legal document for each stage.

Read more: Stage Contract.

Economic sustainability analysis. Relates attributed revenue or resources, consumption, and results per explicit unit of analysis and period, without assuming that a Delivery Unit is a unit of charge.

Read more: Unit Economics.

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