The Estate Is Not a Tree
An enterprise system serves several business processes. A business process runs through several systems. Neither observation is contentious, and neither describes a failure. A system serving one process and no other would be a system that declined every reuse it was ever offered. A process confined to a single system would be a process nobody thought worth carrying across the organisation. The two observations are what a working estate looks like after a few decades of sensible decisions.
Taken together, though, they constrain what can be drawn around that estate. A framework that asks an organisation to place every system, and therefore every team, inside exactly one long-lived container is asking for something the two observations may not permit. Whether they permit it is a property of the particular estate, and the striking thing about the framework that prescribes the container is that it never asks.
The mechanism
The Scaled Agile Framework publishes a procedure for deciding what its containers hold. It appears in the implementation roadmap as one of the critical moves, and it runs in six steps: identify the operational value streams; identify the solutions those value streams use or provide to customers; identify the people who develop and support those solutions; identify the development value streams that build them; add the people needed for the full business solution; realise the development value streams into Agile Release Trains.¹
Compressed, and the compression is faithful:
- Map the operational value stream.
- Assign the systems that support each of its steps to those steps.
- Assign people — Solution Trains, ARTs, teams — to those systems.
The framework distinguishes two kinds of value stream, and the distinction survives scrutiny. An operational value stream is the sequence of activities by which the business delivers something to a customer: fulfilling an order, providing a loan, admitting a patient. A development value stream is the sequence by which software gets built and supported. Building a system and running a business are different activities, and separating them is sound. Nothing in what follows disputes it.
What is worth noticing is where the axis changes. The portfolio is organised around value streams and funded through them. But the ART, the container that holds people, is described throughout the framework’s own material as aligning teams around a product or a related set of products, holding the capabilities needed to define, build, validate, release and operate one or more of them.² The value stream supplies the name. The system supplies the container. No rule is given for what to do when those two things want different boundaries.
When the coercion is free
It is worth being clear early that the mismatch often does not arise.
Where each system supports a step of one operational value stream, or several adjacent steps of it, and no other, step three costs nothing. The systems partition cleanly, the people who build them partition with them, the containers are well formed and the promised benefits are available. This is the picture the framework’s own figures show, and it is not a hypothetical case. It is the ordinary condition of a product organisation whose modules and whose customer journeys were designed in the same exercise. It is also the ordinary condition of the outer edge of many enterprise estates: channel applications, customer-facing portals, systems bought to serve one process and never asked to serve another.
A critique that treats every estate as broken is both false and easy to set aside by anyone whose trains are running. The question is not whether the mechanism can work. It is what happens as the condition under which it works is progressively withdrawn.
Relation and function
Step two of the mechanism records which systems support which steps of an operational value stream. Run once, it produces a map. Run across the several operational value streams a large organisation has, it produces an incidence: a record of which systems are touched by which processes.
That incidence is a relation. It may happen to be one-to-one; it may be many-to-one, with several systems serving a single process; it may be many-to-many, with systems appearing under several processes and processes traversing several systems. Where it is many-to-many, the picture in the figures fails in a second way. A system reached at the second step of a process, again at the seventh, and again at the period close is not a stretch of that flow. It is a node the flow passes through, as it does for the other processes reaching the same system from their own directions. Segments can be owned in sequence. Nodes cannot.
Step three requires a function. Every system must sit in exactly one container, and every person with it.
The conversion is lossless under one condition: the systems partition must refine the operational value stream partition. Set the incidence out as a matrix, systems as rows and operational value streams as columns, and the condition is that the matrix can be permuted into block-diagonal form. Where it can, the blocks are the containers and nothing is lost. Where a system appears under two processes, mass remains outside the blocks, and no permutation removes it.
Everything that follows is a matter of degree rather than a switch. A small residue is a tax on a workable structure. A large one makes the structure a fiction maintained alongside whatever is really routing the work. Where the crossover lies is a property of the particular estate and not a constant, and neither the framework nor this essay can state it. What can be said is that the framework offers no way to pose the question. There is no step at which the incidence is examined as a whole, and no artefact in the method that could hold it: the value stream definition template is per operational value stream, the development value stream canvas is per development value stream, and the figure that maps systems to steps is drawn inside one process. A practitioner who wanted the transposed view — take the finance system, ask which processes touch it — would have to invent the artefact, and would then have no step in the sequence to bring it to.
Trees and semi-lattices
Christopher Alexander set out the underlying structure in 1965, writing about cities rather than software.³ His subject was why deliberately planned cities feel dead where cities that grew do not, and his answer was a claim about the shape of the structures planners impose.
A collection of sets forms a tree, in his definition, if for any two sets in the collection either one is wholly contained in the other or the two are wholly disjoint. Team inside ART inside Solution Train is a tree in exactly this sense. He drew out the restriction the definition carries: within a tree structure, no piece of any unit is connected to other units except through the medium of that unit as a whole. Applied to a city, this is the assumption that the smaller elements within a neighbourhood belong together so tightly that they interact with elements elsewhere only through the neighbourhood they belong to. Applied to an ART, it is the assumption that a team’s work reaches other teams through the train.
Alexander’s case against the assumption came from Ruth Glass’s plan for Middlesbrough, which divided a town of two hundred thousand into twenty-nine neighbourhoods by locating the sharpest discontinuities in building type, income and job type. Having drawn them, she asked whether the units defined by the town’s actual social systems — the school, the post office, the youth club, the adult club, the grocer — fell inside the same boundaries. They did not. Nor were they disjoint. They overlapped. Alexander’s account of why is the sentence to carry across: nothing in the nature of those various centres requires their catchment areas to be the same, their natures differ, and so the units they define differ.
Nothing in the nature of a running system makes its boundary a process boundary either. Different natures, different units.
The more useful half of Alexander’s apparatus is the alternative he names. A collection forms a semi-lattice if, whenever two of its sets overlap, the set of elements common to both is itself a member of the collection. In the city, this says that where two units overlap, the overlap is itself a recognisable thing. His example is a newsrack that belongs both to the system of the traffic light and the pavement and to the system of the drug store and its entrance, and is a unit in its own right either way.
That supplies a test that can be put to any proposed structure: name the overlaps, then ask of each whether it is a unit. In the containment scheme under discussion, the intersection of two ARTs — the change that has to touch both systems — is not a unit. It has no owner, no backlog, no capacity, no cadence, no queue policy and no demonstration of its own. The tree axiom does not merely forbid overlapping containers. It forbids the overlap from having any existence at all.
One further point of Alexander’s is worth keeping, because it prevents the argument from becoming an accusation. His explanation for why designers build trees is cognitive rather than ideological. The mind reduces ambiguity by putting things in one category at a time, and a semi-lattice cannot be held in a single mental act where a tree can. The tree is what any designer reaches for under pressure to produce something graspable. That includes anyone making this argument.
What follows where the estate is connected
Consider what a shared system does to the incidence, rather than to any single container.
Get Bruno Baketarić’s stories in your inbox
Join Medium for free to get updates from this writer.
A system serving two operational value streams does not merely get claimed twice. It joins them. Take the systems and the operational value streams as a graph, with an edge wherever a process touches a system, and the smallest containers that can be drawn without severing anything are that graph’s connected components.
Not every shared system contributes to that joining in the same way, and the difference decides which cases are difficult. What matters is not how many processes reach a system but whether what they need from it differs. An identity service is reached by everything and is not a problem: every process needs it to do the same thing, so there is no variation for the system to absorb and the interface can be specified once for all comers. A system in that first position is a supplier, and a supplier relationship is not a containment problem. The same holds for a delivery pipeline or a cloud substrate. A master data platform sits in a second position. What the processes want from it does differ, and can conflict: finance, procurement and compliance ask for different attributes and different rules on the same vendor record. But the conflicts are all of one kind, questions of how data is structured, owned and kept correct, and one body of expertise can adjudicate them. What arises is contention over priority rather than incoherence of domain. A resource planning system sits in a third. The processes reaching it want different business logic, and that logic belongs to unrelated domains: procurement rules, payroll rules, revenue recognition. No single discipline adjudicates between them, because they are not the same kind of question.
The second and third positions drive the result. One master data platform and one resource planning system, each reached by most of the organisation, and the components merge until the estate is a single component. The only structurally correct container then holds the whole of IT.
It cannot be an ART. The framework’s own criteria for an effective train list fifty to a hundred and twenty-five people, focus on a holistic solution or a related set of products, long-lived and stable teams, minimised dependencies on other ARTs, and the ability to release independently.⁴ Those criteria are given flat, with no priority among them and no rule for the case where the first and the fourth cannot both be had. Where the estate is connected, they cannot both be had. Correct containment and the size limit are jointly unsatisfiable, which means every implementation on such an estate has already broken the containment condition. The open question is only where the breach was placed, and whether anyone wrote it down.
The framework does address the shared-system case, and its answer is to enlarge the container. Several operational value streams, it says, can often be served by a single development value stream that builds and configures the systems those processes need in order to function and to share common information; the worked example is an enterprise-wide resource planning system.⁵ The illustration is therefore drawn from the third position, the hardest of the three, which is worth pausing on rather than passing over. The framework is not avoiding the difficult case. It is answering it, and the answer is absorption: containment satisfied by making the container large enough to hold the coupling, which trades an external premium for an internal one and moves towards the size limit rather than away from it.
Where the pattern is filed matters as much as what it says. It appears among supporting value streams, alongside the annual audit and employee onboarding. The resource planning system in that illustration is serving internal administration, where the demand arriving from each process is thin and the domains held together are few — a system closer to the second position than the third, whatever its product name. The pattern is offered for the case in which absorption is cheapest. It then stands as the framework’s answer for the case in which it is dearest: the same class of system carrying order-to-cash and its neighbours, where each process brings its own business logic and its own domain.
Size is the visible cost of absorption and the smaller of the two. The larger one is that the container now holds several business domains. Whoever owns the enlarged system holds procurement, payroll and revenue recognition at once, or specialists in each share one codebase and one release calendar. The framework’s imported team topologies speak to technical depth — the complicated-subsystem team exists to contain deep specialist knowledge of a subsystem — and say nothing about breadth across unrelated business domains.
Stakeholders arrive with the domains. A train assembled by absorption has business owners whose mandates have no common ground, competing for one backlog, and there is no forum above them in which to settle the competition, because business owners attach to trains rather than to systems. The instrument the framework supplies for ranking assumes what absorption removes: weighting requires a shared frame in which the candidates can be compared, and a procurement change, a payroll change and a revenue recognition change have no common denominator beyond whoever argues hardest. What returns is a queue with several masters and no basis for ordering it, which is among the problems the alignment machinery was built to remove. Absorption satisfies the containment rule by reintroducing the condition the containers were meant to end.
An independent case study records the move being made. Researchers studying a Danish pension and insurance company through twenty-four interviews found that splitting pension and insurance into two value streams was discussed and judged extremely difficult, because of resource constraints and because very specialised people worked across both products; the two product groups were therefore put into a single joint train.⁶ That train came out at a hundred and twenty people across eleven teams, at the top of the permitted band. In the same organisation, a train assembled from many departments whose people did not share qualifications was judged unable to form full-stack teams and was built from component teams instead.
The second of those trains is the same cost arriving without anyone having chosen absorption: draw a container around a shared system and the breadth comes with it, whether or not the estate was ever connected enough to force the question. Absorption at least makes the cost deliberate. Ordinary shared ownership makes it incidental, and harder to see.
Why this lands on IT
The misalignment is not peculiar to enterprise IT. A product organisation whose checkout, returns and renewal journeys all traverse a shared pricing or subscription service has the same many-to-many map. What is peculiar is the absence of any axis that can be moved.
The clearest way to state it is by asking where the business process sits relative to the estate boundary. In product development, the process the product supports is on the far side of it. It is the customer’s process, running through the product rather than through the developing organisation’s own systems, and it therefore never becomes a cross-cutting concern of that organisation’s containers. One axis, and a tree is legitimate. In enterprise IT the process runs inside the estate. Order-to-cash traverses six systems the same organisation owns, funds and staffs, so it is a path through its own containment scheme and cross-cutting by construction.
Both axes are then fixed by parties other than the organisation drawing the boundaries. The system axis is imposed by production: one deployment authority, one release calendar, one schema owner per running instance, enforced whether or not anyone organises around it. The process axis belongs to the business, is frequently constrained by regulation or contract, and is further constrained by what the vendors embedded. A product organisation facing the same misalignment owns the internals on both sides and can move a rule from the journey into the service or back. That option is not available here.
It is worth separating three couplings that this discussion runs together, because a standard response addresses the wrong one:
- System to system. Technical dependency between software systems. This is what architectural runway, decoupling and independent deployability target.
- System to operational value stream. One system serving several business processes. This is the relation that decides whether containment is possible.
- Entity and data. Shared master data and invariants spanning processes, which is why the second relation persists.
The advice to invest in architectural runway is sound advice about the first. It does not touch the second. Decompose the resource planning system into a dozen services and order-to-cash now traverses a dozen nodes instead of one, each still touched by several processes. The matrix grows without coming any closer to block-diagonal form: the residue is preserved and the number of things needing allocation rises. Whether that is better or worse for coordination is arguable; it is not progress on containment, because containment was never a system-to-system problem.
Where the second relation could be reduced, the price is the third. Nobody consolidated onto an integrated resource planning system by accident. One version of the master data, one close, consistency across processes. The coupling is the feature that was purchased. A vendor contract is legitimately part of the value streams of procurement, of finance, of operations and of compliance, and those four do not hold four copies of it. They hold four views of one record, with one identity, one lifecycle and one authoritative state. Processes are partitioned by purpose: hiring, paying, procuring, auditing. Systems and data are partitioned by entity: vendor, contract, employee, product. Neither refines the other, because they are cut on different things, and any tree has to choose one and leave the other cross-cutting.
This also explains why the step-two map of the Scaled Agile Framework cannot show the difficulty. What it records is usage and flow — which process touches which system, in what order, with what delay between steps. That is what a value stream map is for and it does it well. Coupling of the third kind was never within its remit: shared master data, an invariant spanning two processes, a common period close produce no edge on it, because nothing in the instrument asks for one. The defect is not in the mapping. It is in treating the resulting artefact as a sufficient model of coupling on which to draw permanent organisational boundaries. The Lean tradition never asked a value stream map to carry that load.
What is not known before the commitment
The guidance may yield a structural setup that cannot be sustained. Where the incidence between systems and operational value streams is sparse it will not, and where it is dense it will. Most estates of any age sit between those poles, and where a particular one sits is what decides the matter.
The framework offers no way to establish, before the commitment is made, which case a given estate is in. The workshop draws boundaries while the property that determines whether boundaries can be drawn goes unnamed, the roadmap places the first train’s launch at the end of that same exercise, and correction waits for a later step reached after several more trains are running.
So the structure is committed to without the information that decides whether it will hold. And when it does not hold, the account offered is that identification was done badly. That account is always available, it fits every failure, and nothing observable separates a boundary drawn poorly from a boundary that could not have been drawn well. Alexander declined to sketch the semi-lattice city, on the grounds that overlap alone gives no structure and he could not yet say which overlap was the right one. The comparable restraint is to notice that the question was never put, and to leave it there.
¹ Scaled Agile, Inc., “Identify Value Streams and ARTs”, scaledagileframework.com, last updated 10 February 2021. The current framework site places this article behind a login; the version cited here is the Internet Archive capture of 18 January 2022.
² Scaled Agile, Inc., SAFe Explained: Succeeding with Lean and Agile at Scale, April 2025, pp. 11 and 21.
³ Christopher Alexander, “A City is not a Tree”, Architectural Forum, April and May 1965; reprinted in Design 206, 1966, from which the passages here are taken.
⁴ The five criteria appear together in the identification article cited above; the range of fifty to a hundred and twenty-five people is repeated in SAFe Explained, p. 21.
⁵ Scaled Agile, Inc., “Development Value Streams”, scaledagileframework.com, last updated 18 March 2021, Internet Archive capture of 8 December 2021.
⁶ Abheeshta Putta, Maria Paasivaara and Casper Lassenius, “How Are Agile Release Trains Formed in Practice? A Case Study in a Large Financial Corporation”, in P. Kruchten et al. (eds.), XP 2019, LNBIP 355, Springer, pp. 154–170, doi:10.1007/978–3–030–19034–7_10. The wider transformation is reported in the same authors’ “SAFe transformation in a large financial corporation”, Empirical Software Engineering 29:27, 2024, doi:10.1007/s10664–023–10420-w, whose discussion of external validity names tightly coupled legacy systems among the conditions under which its findings would transfer.
