Walk it again: what the first tour of an organization hides from your architecture

The first walk through a business is a guided tour, and architecture built on it models the organization as presented. Why work-as-done differs from work-as-disclosed, what couriers taught a delivery portal, and how to walk an organization more than once.

Published
Series
Architecture starts with people, part 2
Reading time
7 min

Imagine you arrive in Białystok for the first time and want to get to Planty, a park in the city centre. You step off the train and either take a taxi or open GPS and walk. Either way, someone leads you by the hand. You keep checking the screen, you check whether you are still going the right way, or you simply trust the driver. You get to the park, but you saw almost nothing of the city.

The second or third time you walk the same route, it looks different. You notice the facades, what the park actually looks like, and the shortcuts between the blocks of flats that no navigation would suggest.

I like this picture because the same thing happens when an architect enters an organization. The first walk through a business is a guided tour. Someone explains the process, shows the official flow, and you come back with a clean set of requirements. Architecture built only on that first walk models the organization as it was presented, and in my experience that is very often a system with incorrect behaviour built in.

This is the second article in the series. The first one argued that the system will copy the communication channels of the temporary project organization that client and vendor form together. This one is about how to actually get to know that organization.

What you see on the first walk

Safety researchers have a useful vocabulary for this. Steven Shorrock describes several “varieties of human work”: work-as-imagined (how we picture others doing their work), work-as-prescribed (procedures, rules, checklists), work-as-disclosed (what people say or write about their work, often tailored to the audience) and work-as-done (what actually happens under real goals, pressures and resources). He calls work-as-done the most important and the most neglected variety (Shorrock, 2016).

A requirements workshop with business stakeholders mostly collects the first three. You hear how the process should work, how it is documented, and how a manager describes it to an external team. Work-as-done is somewhere else: in a warehouse, on a delivery route, in a spreadsheet someone keeps on the side.

Two other fields arrived at the same conclusion from different directions.

  • Lean manufacturing made “go and see” a management practice. The Lean Enterprise Institute describes the gemba as the actual place where value is created, and the gemba walk as a way for leaders to understand current conditions by looking firsthand and asking questions before acting (Lean Enterprise Institute, “Gemba”).
  • User research built a method on it. Contextual inquiry, developed by Hugh Beyer and Karen Holtzblatt, has the researcher observe people doing their work in their own environment, like an apprentice watching a master. The reasoning is that people recalling their work in an interview lose details, while observation reveals workarounds and steps they would never mention (Nielsen Norman Group, 2020).

Domain-Driven Design says the same about software specifically. Vlad Khononov writes that the only reliable way to gather domain knowledge is to talk to domain experts, and that the most important knowledge is often tacit: not documented or codified, living only in people’s heads, reachable only by asking questions (Learning Domain-Driven Design, p. 30).

Why one walk is not enough

Among architecture approaches, the one closest to my own thinking about this is Barry O’Reilly’s residuality theory, described in his book Residues (GOTO Book Club, 2025). In short: you start with a naive architecture that solves the functional problem, then stress it with possible changes in its environment. The states the business tends to fall into under that stress are discovered through stressors, often in conversations with domain experts, and the architecture is reworked so that it survives in them (Linders, InfoQ, 2025).

The first walk gives you the naive architecture. Every next walk, with different people and from a different point of view, gives you the stressors the naive design does not survive. In my practice it works iteratively: the more times we go through the organization and the better we understand the business, the better the architecture gets.

How the organization itself changes over time, and how to record why a decision made sense when it was made, is a topic for a separate article later in this series.

There is also a link to Conway’s Law from the first article. Who walks you around decides who you talk to, and those conversations become the communication channels of the project organization. If the only guide is the project sponsor, the system will be designed through the sponsor’s view of the work.

An illustration: three requirements that did not survive the couriers

From a delivery-portal project I worked on: the portal let a customer redirect a parcel to another address, to a partner pickup point, or leave a message for the courier, for example to leave the parcel in a deposit location. In conversations with the business it looked simple: we switch these features on and everything works.

Then we started walking further, looking from different perspectives and talking to different people. The most interesting conversations were with the couriers.

  • Tyres in a grocery store. One requirement was that parcels could be redirected to partner pickup points, often small grocery stores. A courier asked how he was supposed to leave a set of tyres in a small grocery store. They would not fit. The feature needed rules about what can be redirected where.
  • Tyres left in the depot. In peak season, such as Black Friday, parcels do not all fit on the truck, and tyres take a lot of space. A courier explained that he would rather leave the tyres in the depot and load thirty other parcels instead, because the company then pays one penalty for a late delivery instead of thirty.
  • A live map of the courier. The business wanted to show customers a map with the courier’s current location, so they would know when to expect the delivery. The feature looked great. The couriers said they would never agree to it: they often carry valuable goods, and if their location is public, it is easy to stop the vehicle and rob them.

None of this was visible in the first conversations with the business, and all of it affects the system: what the redirect feature allows, how delivery is planned under load, what data is exposed to whom.

The person everything passes through

There is one more pattern I see almost every time. After a few iterations of walking an organization, even with someone guiding you through the official process, you find a particular person. In Polish we would call her Mrs. Krysia or him Mr. Gienek: the go-to person everything passes through, who knows every process in the company, knows the shortcuts, and can tell you exactly who else you should talk to.

In Shorrock’s terms, a lot of the work-as-done knowledge lives with that person, together with the shortcuts the official process does not show. Designing without them means designing the guided-tour version of the organization.

What to look for on the walk

When I walk an organization, I look for two things.

The first is obvious: the functional requirements we have to deliver.

The second is just as important: the people, and their classification. Who has influence over the project, who is interested in it, who will actually use the system, who can stop it. That is the subject of the next article, about stakeholder maps and RACI.

My rule from practice is simple: look around as much as possible and ask as many people as possible. In practice I turn that into a few deliberate choices:

  1. Talk beyond the sponsor. Ask to meet the people at the end of the process: the couriers, the warehouse, the service technicians, whoever does the work the system will change.
  2. Ask about exceptions. “What do you do when it does not fit, when there is no time, when the system is down?” is where tacit knowledge shows up.
  3. Ask who else to talk to. The question “who knows more about this than you?” is often how you find your Mrs. Krysia.
  4. Bring different perspectives into one room when it helps. Formats like EventStorming, a workshop format for collaborative exploration of complex business domains, are designed for this. Vlad Khononov names Alberto Brandolini as its creator and sees the real value of a session in sharing knowledge between stakeholders and discovering conflicting models of the business (EventStorming; Khononov, Learning Domain-Driven Design, p. 197).
  5. Walk again. Plan for a second and third pass, with a different guide each time.

What this means when you hire a software house

For a decision-maker on the client side, I would draw a practical conclusion. A vendor that only wants to talk to the sponsor and the product owner will design the system you described in the workshop. A vendor that asks to talk to the people who do the work, and plans time for more than one pass through your organization, is trying to design the system you actually run.

That second kind of vendor will ask for some of your people’s time early in the project, and it is worth giving. Architecture is more than drawing diagrams: it also means building an understanding of the organization and a map of the people in it, so that the decisions we make can be justified.

Sources

Choosing a vendor or shaping a project team?

Tell me what you are deciding and who is involved. I will tell you honestly whether I can help.

Work with meAll writing