Act 5: The brownfield path, layer by layer

Act 5: The brownfield path, layer by layer

Scene 19: onboarding

The brownfield journey starts where the customer's did, with onboarding. Every step of onboarding draws on the same domain invariants, which the language can represent once and share across the whole journey. Requirements would be stated in the domain's vocabulary, and the agent would write them as a document. The validator would check the configuration against the domain's rules before anything is applied. Customisation and training would draw on the same definitions, so each step works from one description of the domain rather than its own. The same onboarding document drives the data migration, and each failure cites the record and the rule that rejected it. The product itself is untouched, because the document compiles to inputs the product already accepts. For the provider, the knowledge a few specialists held is written into the grammar, and review moves from every attribute toward judging outputs. So far, only the migration step of onboarding has been demonstrated, on test data.

Scene 20: the interface

Next comes the interface, where the customer wanted the product personalised down to the individual user and operable by their own agents. With a grammar of what a screen can be, a screen becomes a document too: which entities it shows, which fields, in what order, with what validation, all checked against the domain's rules. Each tenant's layout, or one user's, is a variation of the screen's document, which the agent can write. In an existing product, the compiler emits those screens as source code at build time, reviewed and deployed through the normal pipeline, so each variation is a build. Composing the interface at run time, per user, needs a platform that accepts a desired-state description, which usually means new platform work. For the provider, there is a fixed cost to build the grammar and the compiler, then a cost per screen that falls as converted screens become worked examples, with close review of the first ones. The evidence supports converting screens at a faster rate, with review still needed. The same language is what a customer's own agent needs to operate the product in the domain's terms.

Scene 21: business rules and invariants

Then the business rules, which a brownfield programme reaches later, if at all. The language expresses each customer's rules in the domain's own terms, over the invariants: which entities exist, how they relate, and which workflows govern them. A customer's variation becomes that customer's own business rules, checked against the invariants, and the shared code stays as it is. The existing APIs may not offer the granularity the language needs, but they already cover a large part of the domain. Deciding what becomes an invariant is architectural judgement.

Scene 22: the deep layers

At the bottom of the stack, the deep layers stay where they are. Few customers' needs reach the deep layers, and those that do carry the most risk. In a brownfield product, the data model, the database and the infrastructure stay shared and unchanged, and an agent working in the language cannot reach them. The needs that do reach this far are handled case by case, and the site sets out how. Where a company already plans to rebuild the layer that applies configuration, that rebuild is the place to design the lower line in, and there the greenfield path begins.

Scene 23: the bill

The journey ends, as it did before, with the bill. The customer's domain document is, in effect, a bill of materials: the capabilities this implementation uses, and how they are put together. The price can follow the customer's document, the way modular physical products are priced: a price for each capability used, plus the work of assembling them for this customer. Packages for common scenarios, priced on their value, sit beside the components. Because the price is computed from the same document the compiler validates, the quote and the implementation cannot drift apart. Assembly becomes a visible, priced service.