Commentary

From Software Factories to AI-supported enterprise engineering

Revised October 29, 2026

Published in 2004, Software Factories brought together a powerful set of ideas: software product lines, domain-specific languages, patterns, frameworks and automation. Its central proposition was that developing each application as an isolated undertaking wastes knowledge and effort. Organizations could instead capture what they know about a domain and use that knowledge to build families of related systems. The book’s historical significance lies in this synthesis. In treating development knowledge as something that could be packaged, reused and enacted through tools, it was arguably ahead of the industry’s capacity to put the vision into widespread practice.

Over roughly the past decade, software product line research has developed practical ways to analyze families of systems. Feature models describe shared capabilities, permitted variations and dependencies. Research on architectural optimization explores trade-offs between competing design objectives. Configuration testing addresses a concrete difficulty: there may be too many valid products to test them all. Sampling techniques select configurations to exercise specified combinations of features, while leaving other combinations untested. These are useful advances in managing complexity, with explicit limits on what they establish. [1] [2]

Research on AI-assisted requirements engineering explores how language models can help articulate and analyze requirements. Work at the intersection with product lines is also underway. For example, a 2025 paper on LLM-enhanced product-line scoping uses a smart-home example to explore conversational support for evaluating alternative feature models. It addresses the balance between commercial relevance and technical feasibility, but presents an exploratory approach with open research challenges. This is evidence of work on a specific engineering activity; it does not establish a complete enterprise method. [3] [4]

The proposition explored here is AI-supported enterprise engineering: could explicit engineering knowledge help AI-assisted development remain connected to business purpose? Begin with an objective and the capabilities needed to achieve it. Relate those capabilities to processes, information, services and architectural constraints. Investigate whether AI can use that context to help select and adapt reusable assets, produce implementations and assemble evidence that requirements are met. This is a proposed approach to investigate, with people responsible for objectives, trade-offs and acceptance.

As a proposed experiment, consider an insurer adapting an existing claims service for another market. Capture shared capabilities such as intake, assessment and payment, and identify variations such as local reporting obligations. Record the relevant information definitions, integration contracts and security requirements. Then ask AI to help propose a configuration, adapt approved components and generate tests. Compare that work with the insurer’s normal development process, including whether the result satisfies the same business and architectural requirements. This is an illustrative study design, not a reported implementation or evidence of shorter settlement times.

The practical case for bringing these approaches together remains to be established. Research on product-line configuration, architecture and testing provides useful foundations. Emerging work on AI-assisted product-line scoping explores another part of the problem. These contributions support investigation; they do not yet demonstrate a complete method for connecting business objectives, enterprise architecture and AI-assisted delivery. Evidence on coding productivity also varies by setting: field experiments found more completed tasks, while a study of experienced open-source developers using early-2025 tools found slower completion. Neither demonstrates enterprise-wide savings from combining AI and SPL. [5] [6]

A useful next step would be a bounded experiment within an existing family of applications. Capture shared requirements, permitted variations and architectural constraints, then assess whether AI can use those assets to support a real change. Compare the result with the organization’s normal process, measuring total effort, defects, architectural compliance and the cost of subsequent changes. Include the effort required to create and maintain the models, guide the AI and review its output. Faster generation alone would be insufficient evidence of success.

Seen this way, Software Factories offers a set of ideas worth testing again under changed technical conditions. Its historical significance does not establish its present effectiveness. A useful reassessment should ask which ideas remain useful, which proved difficult to apply, and what AI actually changes. Can it make reusable engineering knowledge less costly to capture, easier to apply and more useful in keeping systems aligned with business needs? Answering those questions through practical work would give substance to the promise of AI-supported enterprise engineering.

← Return to overview