Software should follow the business

When someone brings me a software problem, I ask them to follow one piece of work from start to finish. An order, a client request or an invoice is enough to begin.

Who picks it up? Where does it wait? What gets copied into another tool? Which decisions depend on someone remembering an earlier conversation?

The answers often lead beyond the official process: an approval in a message thread, a missing detail requested by email or progress tracked in a spreadsheet.

Consider a client who has been asked for six files. Three have arrived, two are missing and one needs clarification. A generic upload tool sees six independent files. The operation has a different object: one partially completed request, with an owner, an expiry, a follow-up path and a definition of “complete”. That distinction should shape the system.

Following the business starts with understanding those needs. Keep the meaningful outcome and responsibilities, then question the steps that exist only because the current tools make them necessary.

What deserves to shape the software

Separate what the business needs to achieve from the way today’s teams and tools are arranged. The outcome may be stable even when the policy, reporting line or workaround changes.

I find it useful to separate three layers of what we observe:

A customer outcome may stay the same for years. Its approval policy may change next quarter. The spreadsheet coordinating it may be replaced immediately. Give each the right amount of permanence in the design.

Observe the work as it is done

In a workshop, people may describe how work should happen. Follow an actual case as well. Inspect its records, waits and exceptions, then map five things:

1. Outcome. What must be true before this work is genuinely finished?
2. Events and waiting. What happens, and where does the work queue or stall?
3. Decisions. Where is judgement exercised, by whom, and against which evidence?
4. Information. What does each decision need to know, and which copy is authoritative?
5. Responsibility and recovery. Who owns the normal case, and who notices when it goes wrong?

This treats the unit of design as a work system, not a codebase. Chris Clegg’s account of socio-technical design makes the deeper point: people, work practices and technology are interdependent, so improving one in isolation can make the whole worse.

Software research points in the same direction. Curtis, Krasner and Iscoe’s field study of 17 large projects identified thinly spread domain knowledge, changing requirements and communication breakdowns as important influences on design work. Understanding the domain is not a polite prelude to the technical work. It is part of the technical work.

A model should make disagreement visible

Use the shared model to find disagreements while there is still time to resolve them.

Ask Sales, Finance and Support when an “order” exists and each may give a different, internally sensible answer. Put one unexamined status field into the database and the disagreement does not disappear. It becomes an API contract.

Eric Evans’s Domain-Driven Design gives this discipline a name: a ubiquitous language shared by domain experts and developers, with explicit boundaries where a term carries a different model. The point is not to make everyone use one vocabulary everywhere. It is to stop hidden translation from doing architectural work.

Once the language and responsibilities are explicit, the detailed modelling becomes much easier. I describe that practice in Modelling the system before the code.

Choose boundaries that make changes easier

Before splitting a system into parts, ask what each part should own and what tends to change with it. I use three checks:

The change lens has a long history. In 1972, David Parnas argued that modules should hide design decisions likely to change, rather than merely follow a sequence of processing steps. The responsibility lens meets Conway’s 1968 observation that communication structures constrain the systems organisations produce.

Conway’s Law is a tendency, not a law of physics. A later review by Lyra Colfer and Carliss Baldwin examined 142 empirical studies and found mirroring prevalent in firms and industries, but not universal. That nuance matters. The lesson is not “copy the org chart”. It is that technical dependencies and organisational communication cannot be designed independently.

The deliberate version is often called the Inverse Conway Maneuver: shape team interactions to encourage the architecture you want, while reshaping the architecture so teams can own meaningful outcomes. Team Topologies turns that into a practical organisational design approach.

Use the path of an ordinary change as the test

Choose a routine policy change and trace the work needed to release it. How many teams must interpret it? Where does it queue? Which releases and data contracts have to move together?

If a routine fulfilment policy needs three teams and a release meeting, the architecture is telling us something. Cataldo and Herbsleb’s study of two industrial projects found that gaps between technical coordination needs and actual coordination activity were associated with more software failures and lower productivity. Modern DORA research likewise treats the ability to test, deploy and change a system without fine-grained cross-team coordination as an important architectural capability.

The goal is not the highest possible number of services. A well-structured monolith can support local change; a collection of microservices can remain tightly coupled. The useful measures are behavioural:

• How many handoffs does a normal case require?
• Can a team test and release a routine change independently?
• Is ownership explicit when work stalls or becomes exceptional?
• How much state must people reconstruct from messages and spreadsheets?

Decide which steps are worth keeping

Some steps protect a real requirement. Others survive after their purpose has gone: an approval added after one incident, duplicate entry between systems or a report nobody reads. Find out which is which before automating them.

Generic software is not automatically the enemy either. Payroll, expenses or identity management may be better served by a standard product and a standard process. Enterprise Architecture as Strategy is useful here because it frames standardisation and integration as operating-model choices, not purely technical ones.

The question is not simply “build or buy?”. It is: which assumptions are safe to standardise? If a process does not differentiate the organisation and its exceptions carry no distinctive risk or customer value, changing the operation to fit mature software may be the sensible choice. If the process embodies important judgement, responsibility or a promise to the customer, the software should usually do more of the adapting.

Try the design with real work

Once the important assumptions are clear, build a small complete path through the work. Use it to find what the model missed.

Watch someone complete the task. Where do they hesitate? Which exception has no route? Which label needs explaining? What do they still track elsewhere? Use those observations to decide the next change.

This is consistent with the risk-driven logic of iterative development and with the findings reported in Accelerate: feedback is faster when teams can change and release their part of the system without a large coordination event. Confidence should rise through contact with the work, not through the polish of the diagram.

TASK
Prepare a discovery brief for a client-file collection service, using only these notes.

[D1] Each request specifies six required files and a named internal owner.
[D2] In request R204, three files are accepted, two are missing and one needs clarification.
[D3] The client should know exactly what remains and whether a replacement was accepted.
[D4] Staff currently rename attachments and update a tracking spreadsheet.
[D5] A reviewer decides whether evidence satisfies a requirement. An upload is not approval.
[D6] The team has not agreed how to handle a requirement that changes mid-request.

OUTPUT
1. The business outcome and the evidence that would show progress.
2. A table separating enduring policy, current workflow and local workaround,
with note IDs and unresolved questions.
3. A capability map: capability, responsible role, authoritative record and
first useful delivery slice. Keep it independent of technology choices.
4. Acceptance examples for R204: what the client sees and what the owner can decide.

BOUNDARIES
Do not assume six uploaded files completes the request. Do not automatically
turn attachment renaming or a spreadsheet column into a product requirement.
Ask which file-handling rules have a business or legal reason before preserving them.

What I mean by “follow”

The result should make everyday work clearer: who owns the decision, which information is needed, what happens when a case stalls and how someone can recover it.

Start with the operation, keep the parts that serve a purpose and make the system easy to revise as the work changes.

TreeNodes applies this through systems design. The FileTRX case study shows the same principle in a product built around one specific client handoff.