> ## Content Index > Fetch the complete content index at: https://www.ariet.net/llms.txt > Use this file to discover other available public pages before exploring further. # Architects without Architecture - URL: https://www.ariet.net/architects-without-architecture/ - Published: 2026-10-09T12:52:57.000Z - Updated: 2026-10-09T12:52:57.000Z - Author: Richard Thackeray - Tags: Enterprise Architecture Yes, you read that right; it's the reverse of Rudofsky's MoMA exhibition, Architecture Without Architects. You noticed it. Anyway, onto the article. # The observation Some engagements produce no target state at all; no future-state diagram, no gap analysis, and no roadmap; the client owns the estate, and the architect's work covers one slice of it. On work like that, I have found myself thinking I wasn't doing much architecture. I was wrong about that. The work is deciding where boundaries sit, establishing which system holds which record, separating what the supplier can resolve from what only the client can, and writing definitions precise enough to survive a commercial conversation. It doesn't look like the outputs architects are trained to produce, yet it shapes the system that eventually gets built and maybe more than any diagram would. # Rudofsky's argument In 1964 the Museum of Modern Art in New York showed Bernard Rudofsky's exhibition "Architecture Without Architects", subtitled "a short introduction to non-pedigreed architecture". It was a set of photographs of buildings made without professional designers: hill towns, cave dwellings, granaries, covered streets and whole settlements shaped by communities over generations. Rudofsky's point was that this building carried real design intelligence. Its forms had been fitted to climate, materials, defence and daily use by long trial, and they often worked better than what trained architects produced. The official history of architecture, organised around named designers and notable buildings, had left it out. # The estate as vernacular Most enterprise estates are vernacular in Rudofsky's sense. No one designed them as a whole; they accreted through acquisitions, projects, workarounds, and local fixes, each sensible at the time. Over years, they come to encode how the business works and often more accurately than its process documents. There is a familiar pattern, for example, a large core system holds most of the data, and everyone calls it the system of record, while the real process model sits somewhere else. It might be an old front end, a set of overnight jobs or a spreadsheet that one team depends on. That layer holds the rules that matter, such as which exceptions are allowed, what happens before a transaction is committed and who can override what. It is not written down, and it is often the part scheduled for retirement. By the way, this is a real example, but one I must keep shrouded. The intelligence in a vernacular estate sits in places that don't appear on the system landscape: in screens and scheduled jobs, in the habits of the people who use them, and in the few individuals who understand how the pieces fit together. # What the architect does there The work on an estate like this is closer to Rudofsky's than to a design studio's. It has four parts. - Read before drawing. Find out what the estate does, including what it does that few notice. The useful questions are about behaviour (where is this record created, what happens when this step fails, who decides this) rather than about which products are installed. - Decide where boundaries go. These are often the most consequential outputs: which system masters which record, which party owns which risk, which logic sits in the new product and which sits outside it. - Write definitions that work. One test I have found useful: process orchestration is logic that has to remember where a process has got to after the user's interaction ends; anything that doesn't is interaction logic. A test like that can settle a scope line that a layered diagram leaves open, and that would otherwise come back as an argument about price. - Make unknowns visible and owned. Many of an estate's unknowns can only be resolved by the client, and a fixed price doesn't transfer them. Stating each as an assumption with an owner and a date decides what the design is allowed to rest on. Still no future state architecture, but there is the start of some clarity. # The built environment already does this I wondered if this is the same in the built environment; architects whose primary job isn’t to create an end state architecture and turned to the internet with some questions and found that this is not new in the built environment. There is a long line of architects who shaped places without drawing the end state: • Christopher Alexander's work with the University of Oregon in the 1970s, which replaced a master plan with agreed patterns and piecemeal growth • Walter Segal's self-build housing in Lewisham, where he designed the method and residents designed their homes • Alejandro Aravena's Quinta Monroy in Chile, where families were given half a house and built the rest themselves. Two examples fit the argument here especially well. In 1996 the city of Bordeaux asked Anne Lacaton and Jean-Philippe Vassal to redesign Place Léon Aucoc, a small square in the city. They spent time there, talked to the people who used it, and concluded that it already worked. Their recommendation was to do very little: renew the gravel, care for the lime trees, clean it more often and adjust the traffic slightly. They then had to persuade the city that this was a better use of its money than a redesign. **The architecture activity was the reading, and the decision that followed from it.** They went on to make the same principle central to their housing work, improving and extending existing tower blocks rather than demolishing them, and were awarded the Pritzker Prize in 2021. The Dutch architect John Habraken is my second example. In Supports (1961) he divided housing into two levels: the support, the shared structure that the architect and the collective decide, and the infill, which each household decides and changes over time. **His architect contribution was less a building than a decision about where control sits and who holds it at each level.** That is the same work as deciding which system masters a record or which party owns a risk; it fixes the boundaries and leaves the detail to the people best placed to settle it. # Two kinds of problem solver Most people on a delivery team are problem solvers, but they solve different kinds of problem, and it helps to separate two of them. The first kind creates product. Developers, analysts and most architects are trained this way: take a problem that has already been framed, break it down, specify the parts and build them. Progress shows as things that now exist which didn't before. That is valuable, and it is why projects get delivered. The second kind creates direction where it is unclear. Either the problem hasn't been framed yet, or it has been framed in a way that hides the real risk. The work is to decide which question matters, gather enough evidence to answer it and say what the answer is; progress shows as things that can now be ruled out. The output is a position someone can act on rather than an inventory. The two are easy to confuse because they share ceremonies and often people. A team of product-makers placed in unclear territory will do what it is good at, decomposing and specifying. The material is often good, but build detail has no natural end, so the work keeps growing while the central question stays open; nobody has the job of owning the conclusion. A vernacular estate needs the second kind first. The skills that matter there are different from the ones architecture training mostly builds: - Establishing the decision the work supports before starting. - Finding the person who knows. Often, it is one individual outside the formal stakeholder list, for whom helping isn't part of the job; working with them without undermining the people formally responsible matters more than any model. - Asking questions that expose behaviour rather than inventory. - Weighting unknowns by how much they could hurt, so effort goes where the risk is rather than where the noise is. - Maintaining a current answer from early on and revising it as evidence arrives, rather than waiting for the analysis to finish. Some architects sit in the first kind while believing they are in the second. It produces documents and waits. The documents are often sound; they set out principles, options and recommendations. Then nothing happens, and the conclusion drawn is that the organisation isn't listening. On a vernacular estate, that approach fails for a predictable reason: the knowledge isn't held in documents, and decisions don't follow from a document existing. An organisation that doesn’t write down its own system is unlikely to read a long document about it either; it works through conversation, demonstration, and the few people who know. Lacaton and Vassal worked in the medium the square already used, by watching and talking, and their conclusion fitted on a page. An architect working with a client like that should do the same: find out how the client decides things, and bring the finding there. A document earns its place as the vehicle for a decision someone has agreed to take; on its own it is commentary. # The pedigreed mistake TOGAF and similar methods put the target state near the centre: describe the baseline, design the target, analyse the gap, plan the migration. I used to teach that sequence and think it is sound. The problem is emphasis. Because the target is the most visible product, architects reach for it early, and they treat the baseline as inventory to replace rather than a body of knowledge to understand. A target drawn that way looks clean because it leaves things out. I have seen early targets include whole layers to reconcile data supposedly held in several places, when a conversation with the right person showed the split ownership didn't exist. The same targets left out the layer that carried the process rules. Building to them would have removed the real process model without anyone deciding to. In Rudofsky's terms, that is the pedigreed mistake: valuing the designed object and overlooking the vernacular it replaces. # The limit This argument can turn into a defence of never designing anything. Clarity work without a target state can drift into commentary, and some architects are comfortable there. The test I would apply is whether the work changes a decision. A definition that settles a scope line passes that test. A careful analysis that nobody acts on fails, however accurate it is. The target state still matters. It comes later than the frameworks imply, and it should be built on the reading of the estate rather than in place of it. # Close Rudofsky didn't think architects were unnecessary; he thought they had been looking in the wrong place for what good building is. Enterprise architecture has a similar habit. On an estate that grew rather than being designed, the architect's main contribution may be keeping the conditions for good change in place: knowing what the existing system does, where its boundaries should fall, and who owns which risk. A target state is one product of that work, and not always the first. Not every output has to be a monument to the architects greatness.