Part IV — Compounding Capability
Factory Assets and the Economics of Reuse
When does reuse compound capability rather than create another dependency?
The platform that succeeded and still had to end
Chapter 9 established that a Software Factory cannot improve flow by keeping every person and capability fully occupied. Work moves more predictably when leaders control work in progress, expose queues and constraints, shorten feedback, and preserve capacity for variability. Yet a factory that only moves today’s work more smoothly still begins too much work from the beginning. Its next source of leverage is memory: the ability to preserve a useful result, make it available to others, and improve it through repeated use.
GOV.UK Platform as a Service was created in 2015 to let public-sector teams host applications without each team having to establish and operate the same underlying hosting capability. By 2021, an official live assessment described a multidisciplinary producer team, user research, support feedback, roadmap work, reliability work, and attention to technical debt. It also recorded harder questions about converting trial users, engaging organizations beyond familiar communities, recovering fixed costs, sustaining funding, and preparing an exit strategy.C10-R05
This was not a file placed in a shared repository. It was an operated capability with consumers, support, continuing engineering, and an economic context. In July 2022, the Government Digital Service reported that the platform served more than 60 departments, agencies, and local authorities, supported 172 digital services and 3,200 applications, and handled more than 122 tenant deployments a day. It also reported 99.95% uptime and one major incident across seven years. These are dated, first-party operating measures, not an independent audit or proof of value.C10-R06
The same decision record announced that the service would be decommissioned. Cloud providers had expanded their capabilities, departments had developed more of their own cloud competence, architecture preferences had changed, and further growth would have required substantial investment. The platform received an 18-month sunset window rather than an indefinite mandate. An operationally useful shared service had reached a point at which continuing it was no longer judged the best available choice.C10-R06
Retirement did not make the platform disappear. Consumers still had to leave it. A 2025 Department for Business and Trade account described moving 41 services through scheduling, code preparation, performance testing, data migration, acceptance criteria, new tooling, dedicated support, embedded migration expertise, and coordinated cutovers. The record is a first-party retrospective and does not provide a complete cost ledger, but it makes one fact difficult to ignore: exit was production work for both the asset owner and its consumers.C10-R07
The case interrupts two comfortable stories about reuse. The first says that building something once eliminates repeated work. The second says that continued adoption proves continued value. GOV.UK PaaS did reduce a class of repeated hosting work for its consumers, but it required creation, conversion, support, maintenance, improvement, and eventual migration. Its operating achievements did not settle whether the next unit of investment belonged there.
That is the central question of this chapter:
When does reuse compound capability rather than create another dependency?
A reusable resource becomes a Factory Asset only when an accountable owner manages its provenance, fitness, discovery, adoption, support, improvement, deprecation, and retirement, while consumers retain responsibility for local qualification, integration, operation, evidence, and contingency. Reuse compounds when the bounded benefits across those consumers exceed the full producer and consumer burden over the relevant horizon. It does not compound merely because an artifact is available, widely used, or inexpensive to copy.
This chapter develops that lifecycle and its economic boundary. It does not claim that every useful resource must produce a financial return, that central provision is always preferable, or that an asset portfolio can be ranked by one formula. Chapter 17 owns investment allocation among competing demands. Here the narrower task is to ensure that a reuse decision counts the work and risk it creates as well as the work it avoids.
The memory sentence is therefore deliberately qualified:
Reuse is not the absence of repeated work; it is the deliberate transfer of prior capability with ownership of the work that transfer creates.
A shared capability can operate usefully and still reach a rational retirement decision; migration and evidence remain part of its lifecycle.
A reusable thing is not yet an asset
Software is unusually easy to copy. A code library, policy rule, test harness, deployment template, data model, operational playbook, or body of documentation can be reproduced at negligible technical cost. That property makes reuse attractive, but it also encourages a category error. Replication cost is only one small part of the cost of dependable use.
The Factory Asset definition corrects that error. A Factory Asset is a governed and reusable resource whose lifecycle is managed to reduce future effort, risk, or variability or to increase quality and learning across the Software Factory. The definition includes code and platforms, but also patterns, policies, test capabilities, data, models, documentation, and operational knowledge. Reusability is necessary and insufficient. Ownership, fitness, provenance, lifecycle, and consumers must be known.
This distinction begins where Chapter 5 left it. A Work Center is a reusable production capability; a Factory Asset is a reusable resource used by people, Digital Workers, Production Lines, or Work Centers. An observability Work Center might operate a shared diagnostic service. Its configuration patterns, evidence schemas, alert libraries, test fixtures, and operating guides may be Factory Assets. The capability acts; the assets preserve and transfer resources on which action depends.
The distinction also prevents a catalog from becoming an asset strategy. A catalog can make a resource discoverable. It cannot establish that the resource fits a consumer’s context, that its dependencies are known, that someone will answer a support request, or that a replacement path exists. Discovery reduces search cost. It does not remove judgment.
The industrial evidence supports the promise of reuse, but less strongly than common reuse rhetoric suggests. A 2024 systematic literature review examined 30 industrial primary studies. It found the strongest evidence around quality and productivity benefits and reported the broadest benefit pattern where reuse was systematic rather than ad hoc. It also found that costs were addressed in only seven of the included studies and assessed 87% of the primary studies as low or moderate quality. Older reuse practices dominated, while evidence about more recent InnerSource and microservice contexts remained incomplete.C10-A01
The appropriate conclusion is not that reuse fails. It is that benefits have a more developed evidence base than full lifecycle economics. A review of successful reuse cannot tell an institution its own break-even point. The relevant artifact, architecture, consumer population, regulation, operational consequences, and available alternatives all alter the result. A component reused without modification differs economically from one that each consumer must adapt. A policy module operating in one legal context differs from one crossing jurisdictions. A test harness tied to specialized hardware differs from a portable library.
Architecture matters because reuse creates a dependency relationship. MacCormack, Rusnak, and Baldwin’s analysis of complex software designs supports a cautious proposition: coupling structure affects the cost of change, variation, and dependency. It does not prescribe an organization or asset model, but it explains why copying an interface is not enough. When consumers depend on hidden design decisions, local variation can require coordinated change or costly adaptation.
Knowledge creates another boundary. Naur’s account of programming as theory building warns that an artifact does not contain all of the understanding required to modify it safely. Documentation, examples, tests, and support can improve transfer, but no package entirely substitutes for the theory held by experienced people. A resource may therefore be technically portable while the capability to operate or change it remains concentrated.
This is why product-like ownership is useful language, provided it is not mistaken for a prescribed commercial product team. An owner must understand consumers, make scope and fitness visible, steward releases, respond to evidence, and manage exit. Those functions may be performed by a small community, a distributed maintainership, an internal platform group, a public body, or another accountable arrangement. The organizational form can vary. The lifecycle obligations do not disappear.
Reuse divides responsibility; it does not erase it
Every Factory Asset has at least two perspectives. The producer or steward is responsible for what is offered: origin, supported scope, release, change, maintenance, support, and retirement. The consumer is responsible for the local decision to depend on it: fitness, integration, configuration, operation, updates, evidence, and contingency. Some institutions perform both roles. The responsibilities remain analytically distinct because the costs and risks fall in different places.
The producer begins before creation. Someone must identify a recurring need and decide whether to create a shared resource, adopt an external one, allow local duplication, or leave the need unresolved. Reuse is not automatically the right answer. If consumer contexts diverge sharply, expected demand is low, change is rapid, or dependency risk dominates, local work may be more responsible than a common asset.
Creation or acquisition then produces more than an artifact. The owner must preserve provenance: where the resource came from, what supplied inputs and dependencies it contains, what process produced it, what rights and obligations attach, and what evidence supports the record. SLSA and SPDX offer current structures for parts of that problem. They improve the visibility of origin, build process, and software composition, but neither an attestation nor a software bill of materials proves security, compatibility, maintainability, or value.
Qualification asks whether the resource is fit for a stated use. That judgment is bounded. The producer can declare supported environments, interfaces, versions, performance ranges, and known limitations. The consumer must still decide whether those claims match its data, workload, risk, architecture, and obligations. A verified component may be well tested and still be unsuitable for a safety-critical context. A policy module may be correct in one jurisdiction and wrong in another.
Publication makes the qualified resource available. It requires a stable identity, discoverable description, version and change record, access path, documentation, support expectations, and evidence of supported status. Availability without these signals forces consumers to reconstruct the asset’s meaning. A repository full of unlabeled components externalizes catalog and qualification work to every potential adopter.
Adoption is then work, not an event counter. Consumers search, compare alternatives, read evidence, experiment, integrate, configure, test, train, obtain approvals, change operating routines, and prepare fallback. Some of this replaces work they would otherwise do. Some is created specifically by the shared dependency. Counting adopters while ignoring that effort can make an asset appear to compound when it merely redistributes cost.
Operation continues the relationship. Producers resolve defects, maintain compatibility, answer questions, update dependencies, publish changes, and learn from support demand. Consumers monitor local behavior, apply updates, retest integrations, handle incidents, and report evidence. Both sides need a way to distinguish a local problem from an asset problem. Without that connection, the producer sees adoption while consumers experience friction privately.
Improvement should follow evidence rather than prestige. Useful evidence includes defects, support demand, conversion and abandonment, consumer outcomes, compatibility, security or provenance changes, operating cost, and unmet need. Download counts, deployments, and catalog views may help explain activity, but they do not establish benefit. An owner needs to know whether the resource removes meaningful effort or risk for consumers and what new burden it creates.
Scope can narrow as well as grow. A mature owner may stop supporting a configuration that prevents timely improvement for everyone else. It may constrain use after new evidence changes the risk. It may replace the resource, announce deprecation, or retire it. These are not failures of stewardship. They are lifecycle decisions, and they become failures only when consumers receive no usable notice, evidence, migration path, or contingency.
Government Functional Standard GovS 005 makes several of these duties explicit in its own UK public-sector context: ownership, discovery, continual improvement, dependency-aware retirement, stakeholder engagement, migration, data handling, and disposal. A standard defines expected practice rather than proving outcomes, and its organizational form does not transfer universally. It nevertheless confirms that service and technology responsibility extends through retirement, not merely launch.C10-R08
ISO/IEC/IEEE 12207 provides a broader lifecycle baseline across acquisition, supply, development, operation, maintenance, and disposal. It does not define Factory Assets or determine how a particular organization should structure ownership. Its contribution is to make it difficult to treat creation as the whole lifecycle.
Figure F10.1 makes this two-sided responsibility visible. The main path moves from need and a create/adopt/duplicate decision through acquisition, provenance, qualification, publication, consumer adoption, operation, and support. Evidence returns to an improve, constrain, replace, deprecate, or retire decision. The exit branch preserves notice, dependency review, migration, data and provenance retention, and end of support.
Figure F10.1 production specification: Factory Asset lifecycle
Figure F10.1 — Factory Asset lifecycle. A reusable resource becomes durable shared capability through a continuing producer-and-consumer lifecycle with evidence and an explicit exit. The sequence is a decision model, not a mandatory stage gate or organization chart.
Source: Author synthesis based on C10-A01, S01, S13, S14, and C10-R01–C10-R08.
The figure’s dominant insight is that reuse is not a handoff. Producer and consumer responsibilities coexist for as long as the dependency matters. The owner cannot guarantee every local use, and the consumer cannot outsource local accountability to the producer. Good asset discipline makes that division explicit enough to manage.
A reusable resource becomes durable shared capability through a continuing producer-and-consumer lifecycle with evidence and an explicit exit. The sequence is a decision model, not a mandatory stage gate or organization chart.
The full cost sits on both sides of the interface
Reuse economics often begins with a comparison between building once and building many times. That comparison is useful but incomplete. It assumes that the avoided local effort is known, that the shared resource fits each consumer, and that creation is the principal cost. In practice, the cost boundary runs through the whole lifecycle.
Producer cost includes discovery, creation or acquisition, qualification, release, documentation, cataloging, maintenance, support, improvement, risk work, deprecation, migration support, and retirement. Consumer cost includes discovery, evaluation, adoption, integration, configuration, local assurance, operation, updates, switching, and contingency. Institutional cost may include duplicated alternatives, dependency concentration, delayed work, contractual obligations, and capacity that cannot be used elsewhere.
Benefits also need a boundary. Avoided duplicate work is a counterfactual: an estimate of work that would otherwise have been performed. Quality may improve where more consumers exercise the same component and fixes are shared, but only if evidence reaches the owner and updates reach consumers. Variability may fall because interfaces and operating expectations become stable. Learning may spread because decisions and incidents become reusable knowledge. Public value or risk reduction may matter even when it is not responsibly convertible into currency.
A bounded decision equation can make those terms inspectable. For a set of consumers over a stated horizon, cumulative net value equals avoided duplicate work and other bounded operating benefit, less producer creation and qualification, consumer discovery and integration, continuing maintenance and support, expected dependency risk, switching and migration, and retirement or archive cost. Every term needs an owner, unit, horizon, estimation method, and uncertainty.
Break-even is the earliest observed or modeled point at which that cumulative value becomes zero or positive. It is not a universal consumer count. An asset with high fixed qualification cost and low per-consumer burden may compound after repeated adoption. Another with weak fit, heavy adaptation, and growing dependency risk may become worse with every adopter. More adoption can increase value, or deepen a liability.
Figure F10.2 illustrates the distinction with normalized teaching units. In Scenario A, each adoption contributes 10 units of avoided work and bounded benefit, while consumer adoption costs 3, continuing producer support costs 2, and fixed creation plus retirement cost 25. Net contribution is 5 per adoption, so the scenario reaches zero at adoption 5. In Scenario B, benefit is 7 while consumer, producer, and dependency cost total 8 per adoption; cumulative value begins at negative 25 and falls by 1 with every adoption.
Figure F10.2 production specification: Reuse economics
Figure F10.2 — Reuse economics. In illustrative normalized units, reuse compounds only where each additional consumer contributes more bounded benefit than producer, consumer, and dependency cost and where fixed lifecycle and exit costs are recovered. The values are not observed company data, an industry benchmark, or a typical break-even point.
Source: Author synthesis informed by C10-A01, A16, C10-R01–C10-R08, S01, S13, and S14.
The no-break-even scenario matters more than the arithmetic. It prevents the graph from becoming a promise that scale will eventually rescue any shared resource. Poor fit at scale is not leverage. It is repeated integration burden plus concentrated dependency. An owner who measures only adoption can celebrate precisely while the economic mechanism deteriorates.
The equation also disciplines apparently free resources. An open-source component may have no license fee, but consumers still incur discovery, qualification, integration, update, verification, and contingency cost. An internal template may be inexpensive to produce but expensive to adapt. A policy module may save review effort while increasing the consequence of one incorrect rule. Price and cost are not interchangeable.
Nor should the equation force every benefit into money. A public institution may value accessibility, safety, legal consistency, resilience, or equitable service. A regulated institution may need an asset even when duplicated local implementations appear cheaper. Those benefits can be named, evidenced, and compared without false monetization. The economic discipline is completeness of the decision boundary, not reduction of every obligation to currency.
Portfolio comparison remains outside this chapter’s boundary. Chapter 10 stops earlier. It asks whether the proposed value of this asset has been defined against its own producer and consumer lifecycle, whether omitted burdens could reverse the conclusion, and whether exit remains possible.
In illustrative normalized units, reuse compounds only where each additional consumer contributes more bounded benefit than producer, consumer, and dependency cost and where fixed lifecycle and exit costs are recovered. The values are not observed company data, an industry benchmark, or a typical break-even point.
Log4j and the responsibility that travels with reuse
The Apache Log4j case tests the lifecycle from a different direction. Log4j is a reusable Java logging component governed within the Apache Software Foundation. Apache Project Management Committees provide project oversight and release authority, while the project’s release records show continuing corrective and compatibility work. These records establish an upstream governance and release structure; they do not reveal complete maintainer labor, funding, or project health.C10-R03C10-R04
When the Log4Shell vulnerability was disclosed in December 2021, the response was not confined to the upstream project. Vendors and consuming organizations had to identify direct and transitive use, determine affected versions, patch or mitigate, test, hunt for compromise, notify affected parties, and monitor subsequent releases. Government guidance emphasized inventory, scanning, updating, mitigation, monitoring, and incident response across downstream environments.C10-R01C10-R02
The event does not establish the typical cost or risk of open-source reuse. It concerned an unusually consequential vulnerability. Proprietary and internally developed components can create the same discovery and update burden. Public sources do not disclose the full dependency graph, consumer remediation cost, or maintainer hours. The case is not evidence that Apache lacked governance or that open source is inherently unsafe.
Its narrower lesson is about the division of responsibility. Upstream maintainers controlled the project and its releases. Consumers controlled selection, local inventory, integration, deployment, operational exposure, updates, and contingency. Access to source code did not turn upstream volunteers into the consumer’s staff. A producer’s fix did not prove that every downstream copy had been found, qualified, deployed, and verified.
This distinction sharpens the meaning of provenance. A software bill of materials may help an organization identify that a component is present. A build attestation may help explain how an artifact was produced. These records can reduce uncertainty about origin and dependency, which is valuable. They do not determine whether a version is safe in context, whether a mitigation is complete, or whether an organization can recover. Provenance enables questions; it does not answer every one.
The case also reveals why hidden transitive dependencies matter economically. A consumer may choose one direct resource while inheriting other components beneath it. If inventory and ownership stop at the direct interface, emergency discovery becomes expensive and incomplete. The asset decision must therefore include the dependency structure and the consumer’s ability to update, substitute, isolate, or operate under constraint.
Transfer the responsibility split, not the incident severity. Every shared asset has an upstream or producer side and a consumer side, even when both sit inside one institution. The producer must make supported scope, releases, provenance, and change visible. The consumer must know where the resource is used, decide whether it remains fit, and retain a contingency proportionate to consequence.
A shared component preserves upstream release authority while creating downstream inventory, qualification, update, verification, and contingency responsibilities.
GOV.UK PaaS and the discipline of exit
Return now to GOV.UK PaaS. The 2021 live assessment shows a service that already exhibited much of the lifecycle discipline: multidisciplinary ownership, user research, support feedback, roadmap work, reliability attention, and technical-debt management. It also exposed weak points in conversion, engagement, fixed-cost recovery, funding longevity, and exit planning. The assessment was not an independent financial audit, but it did not present adoption as sufficient evidence of value.C10-R05
The 2022 decommissioning decision added context. GDS cited changes in cloud-provider capability, departmental competence, architectural direction, growth, reach, impact, and the opportunity cost of the investment that continued evolution would require. The same record reported substantial use and a strong first-party operating history. Retirement therefore cannot be reduced to technical failure.C10-R06
Equally, the operating record cannot prove that continued investment was justified. Uptime, applications, deployments, and organizations served show activity and scale. They do not reveal the full counterfactual: what consumers would have spent otherwise, what they gained, which costs were shifted to the center, or what alternative investment could have produced. The unpublished investment model is a material limitation.
The later migration record makes the exit branch concrete. Forty-one services in one departmental cohort did not move through a single switch. Teams prepared code, scheduled changes, tested performance, moved data, established acceptance criteria, learned new tooling, and coordinated cutovers with dedicated and embedded support. The platform owner’s sunset decision created a series of consumer Work Orders whose burden belonged inside the asset lifecycle account.C10-R07
Migration effort does not prove that the original platform was uneconomic. Any long-lived shared capability can create switching cost, and avoiding all dependency would forfeit much of the benefit of specialization. The relevant question is whether exit obligations were recognized early enough, evidence was preserved, alternatives were feasible, and consumers were supported through change.
This is the opposite of “build it and they will come,” but it is also more demanding than “treat the platform as a product.” A product posture can improve consumer attention and ownership. Asset discipline adds provenance, local fitness, dependency, evidence, and retirement. It asks not only whether consumers choose the service but whether the institution can explain the responsibility and lifecycle economics of that choice.
The Log4j and GOV.UK PaaS cases rule out complementary shortcuts. Open availability does not eliminate ownership or downstream work. Formal ownership and useful operation do not justify indefinite continuation. In both cases, the dependency is real because the asset is useful. Good stewardship does not remove that dependency; it makes its obligations visible and revisable.
The asset lifecycle test
Leaders do not need a universal score to decide whether a reusable resource is becoming a Factory Asset. They need a set of connected questions that follows the lifecycle and keeps producer and consumer evidence in the same decision.
First, what repeated need is being addressed, and why is reuse appropriate? Name the class of demand, expected consumers, meaningful variation, and alternatives. A resource built for one exceptional use should not acquire a shared mandate merely because it exists. Local duplication may be rational when contexts diverge or coordination cost exceeds avoided work.
Second, who owns the offer and who owns each use? The producer owner must be accountable for supported scope, provenance, release, maintenance, support, improvement, deprecation, and retirement. Consumer owners must be accountable for local fitness, integration, operation, updates, evidence, and contingency. “The community” or “the platform” is not a sufficient answer unless its authority and obligations are inspectable.
Third, what evidence establishes provenance and fitness? Record origin, dependencies, rights, build or creation process, version, qualification method, supported contexts, known limitations, and change history. Separate what the producer has established from what each consumer must verify. Do not convert a standards-compliant record into a claim of security or suitability.
Fourth, can the intended consumer find, understand, adopt, and leave? Discovery includes description and comparison, not merely search. Adoption includes integration, assurance, learning, and operating change. Exit includes substitutability, export, data handling, migration support, notice, end of support, and retained evidence. An asset with no credible exit imposes a different kind of risk than one with an exercised migration path.
Fifth, does evidence support improvement, constraint, or retirement? Review defects, support demand, consumer outcomes, abandonment, compatibility, security and provenance change, cost, unmet need, and available alternatives. Adoption is one signal among many. A decline in adoption may reveal poor fit, or a deliberate narrowing to high-value uses. Rising adoption may indicate value, coercion, or simply the absence of an alternative.
Sixth, does the full lifecycle account still support reuse? Include producer and consumer effort, dependency risk, switching, and exit. State the horizon and uncertainty. Preserve non-monetized obligations separately where monetization would be misleading. The answer can be “continue,” “improve,” “narrow,” “replace,” “deprecate,” or “retire.” It need not be an irreversible yes or no.
These questions form a decision framework, not a maturity model. They do not prescribe central ownership, one funding mechanism, a standard lifetime, or a required number of consumers. A small asset can be valuable. A widely adopted one can be harmful. The test is whether managed reuse reduces future effort, risk, or variability or increases quality and learning under a complete and revisable lifecycle account.
The lifecycle test keeps producer and consumer evidence in one revisable decision without prescribing a maturity path or organization form.
What executives should require without centralizing every asset
Executive responsibility begins with the conditions that allow asset discipline to exist. Leaders should require named ownership, visible consumers, credible provenance, bounded fitness, lifecycle evidence, and a funded exit obligation for consequential shared resources. They should not decide every interface, test method, or release. Those judgments belong with qualified producers and consumers close to the work.
Leaders should also resist one-sided business cases. A central team can make its economics look attractive by excluding consumer adoption and migration. A consuming line can make local duplication look attractive by excluding repeated maintenance, inconsistent controls, and lost shared learning. The purpose of the lifecycle account is to keep both views inside one institutional decision without pretending that every cost can be measured precisely.
Adoption targets deserve particular scrutiny. Mandating use can sometimes protect interoperability, safety, or legal consistency. It can also conceal poor fit and transfer switching cost to consumers. Where use is mandatory, the decision should state the obligation, provide an exception path appropriate to consequence, and measure consumer outcomes and burden rather than presenting compliance as value.
Retirement reserves are equally important. An asset owner who can fund creation and growth but not migration has left part of the liability outside the plan. The reserve need not always be a ring-fenced monetary account. It can be capacity, contractual provision, portable data, maintained replacement paths, retained expertise, or another credible means of exit. The form varies; the obligation remains.
Finally, leaders should distinguish an asset portfolio from a collection. A collection accumulates resources. An asset portfolio makes lifecycle state visible: proposed, qualified, supported, constrained, deprecated, or retired; who owns each state; which consumers depend on it; and what evidence can change the decision. This chapter does not decide how scarce investment should be allocated across that portfolio. It establishes what must be known before such allocation is responsible.
What to remember
First, a reusable resource becomes a Factory Asset through managed ownership, provenance, fitness, discovery, adoption, support, improvement, and retirement. Copyability does not provide those conditions.
Second, responsibility exists on both sides of reuse. Producers own the offer and its lifecycle; consumers own local qualification, integration, operation, updates, evidence, and contingency. Shared ownership must not become missing ownership.
Third, reuse economics includes avoided work and bounded benefit, but also producer creation and maintenance, consumer adoption and integration, dependency risk, switching, migration, and exit. Adoption is not value by itself, and no universal break-even count follows from the evidence.
Fourth, provenance improves visibility without proving security or fitness. A catalog, attestation, inventory, or software bill of materials supports decisions; it does not replace them.
Fifth, improvement, constraint, replacement, deprecation, and retirement are legitimate asset outcomes. A useful asset can be retired when context changes, and a popular asset can remain unsustainable.
Reuse is not the absence of repeated work; it is the deliberate transfer of prior capability with ownership of the work that transfer creates.
From reusable capability to delegated action
A governed asset makes prior capability available without pretending that access removes responsibility. It gives the Software Factory a stable object that people and systems can discover, qualify, apply, observe, improve, and eventually retire. That is how one team’s learning can become institutional capacity rather than an unmanaged dependency.
Availability, however, does not perform work. Someone or something must select the asset, operate within its authority, produce evidence, recognize conditions outside its supported scope, and escalate when the next action is uncertain or consequential. As more of that work is performed by software-based actors, asset discipline becomes a necessary foundation but not a sufficient control.
Chapter 11 therefore asks the next question: What production work can be delegated to Digital Workers without losing control or accountability?
Governed assets make prior capability available; the next production problem is deciding what a software-based actor may do with that capability and when it must stop or escalate.