Source: [Software should follow the business](https://treenodes.com/articles/software-should-follow-the-business/) This Markdown version is generated from the public page. Visit the source for interactive examples and full-size visuals. [All writing](https://treenodes.com/articles/) Published 12 May 2026 · Updated 6 September 2026 · Approach · 11 min read # Software should follow the business Follow one order, invoice or client request from start to finish. The waits, decisions and workarounds tell you what the software needs to support. Written by [Nermien Barakat](https://treenodes.com/articles/by/nermien-barakat/) · Systems & Applied AI Architect ![A woman tracing the real path of human work and shaping a coherent software structure around its decisions and handoffs](https://treenodes.com/assets/articles/software-should-follow-the-business-hero-treenodes.webp?v=d5309daed1ec) 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. ![FileTRX owner view showing a website content request with three of six required items complete and a visible 50 percent progress state.](https://treenodes.com/assets/case-studies/filetrx-owner-progress.webp?v=73804b1b7192) FileTRX tracks a request as a whole: three items complete, three still needing attention. 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: ### Not every part of today’s process deserves the same permanence The closer something is to business intent, the more confidently it can shape the architecture. The closer it is to a workaround, the more carefully it should be challenged. Slow-changing ### Purpose and capability What outcome must exist, for whom, and under which real constraints? Encode the meaning clearly Changeable ### Decisions and policy Who may decide, what evidence is required, and which rules apply? Make rules explicit and replaceable Often temporary ### Procedure and workaround Which clicks, copies and approvals exist because of today’s tools? Question before automating Treat the outcome, the policy and the workaround as different design decisions. 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](https://doi.org/10.1016/S0003-6870\(00\)00009-0) 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](https://doi.org/10.1145/50087.50089) 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](https://www.domainlanguage.com/ddd/) 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](https://treenodes.com/articles/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: ### Three tests for a useful boundary The tests will not always agree perfectly. The disagreement is useful because it shows where coordination or an explicit contract will still be needed. 01 **Meaning** Which terms, rules and invariants form one coherent model? 02 **Responsibility** Who owns the decision, the outcome and its exceptions? 03 **Change** Which policies and information tend to change together? **Candidate boundary:** a place where meaning, responsibility and change broadly cohere. Use the three checks to discuss a boundary; they do not require one team per component. The change lens has a long history. In 1972, [David Parnas argued](https://doi.org/10.1145/361598.361623) 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](https://www.melconway.com/Home/Committees_Paper.html) 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](https://doi.org/10.1093/icc/dtw027) 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. ### The same policy change, two ownership models Example change: fulfilment approval now requires a supporting evidence file. Both designs still have interface, rules and data. The difference is where ownership sits. Ownership by technical layer Each layer is a separate area of responsibility. InterfaceChange Business rulesChange DataChange Three ownership boundaries touched Ownership by business capability Each capability contains the layers needed to own its outcome. Quotinginterface rules data FulfilmentChangeinterface rules data Billinginterface rules data One primary ownership boundary touched Keeping related work under one owner can reduce handoffs for a policy change. ## 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](https://doi.org/10.1109/TSE.2012.32) found that gaps between technical coordination needs and actual coordination activity were associated with more software failures and lower productivity. Modern [DORA research](https://dora.dev/capabilities/loosely-coupled-teams/) 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. ### A short process-archaeology test For each step, ask what work it performs before deciding whether to encode it. **Does it create an outcome someone values?** Name the customer or operational result, not just the activity. Preserve the intent **Does it control a real risk or constraint?** Name the failure, obligation or safety condition it prevents. Preserve or redesign **Does it move or clarify essential information?** Identify the decision that needs the information and its owner. Make it explicit **Would it exist without the current tool?** If not, it may be compensation for an old system rather than real work. Question or remove Check why a step exists before removing it, especially if it controls a safety or compliance risk. ## 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. ### Software and operation learn from one another The model gives the first build a direction. Real use supplies evidence that can change both the software and the operation. 1. **Observe real work**Follow a case, including waiting and exceptions. 2. **Model**Make language, decisions and ownership explicit. 3. **Build a thin slice**Deliver one complete path through the work. 4. **Watch real use**Notice friction, side channels and missing states. 5. **Revise both**Change the system, the process or the boundary. Use each release to check and improve the model. 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. ## Try it: turn a file-request process into a discovery brief Before choosing screens or services, identify the commitments the software has to support. This uses the client-file request from the article. **How to try it.** Run the prompt in a new chat and challenge any proposed capability that has no supporting need in the notes. The example is fictional. Discovery and capability brief Included file: file-request-discovery.txt [Download file](https://treenodes.com/downloads/practice/file-request-discovery.txt) **Full prompt** ``` 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 your result should show - The first slice makes requirements, submitted evidence, review decisions and the remaining gap visible to the appropriate people. - R204 is still open: two missing items and one clarification remain. Renaming is treated as a workaround to investigate, not an enduring capability. ### Change one condition A seventh requirement is added after the client has submitted everything. Ask how the change is recorded, explained and owned without rewriting the original agreement silently. ## 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](https://treenodes.com/services/#svc-design). The [FileTRX case study](https://treenodes.com/products/filetrx/) shows the same principle in a product built around one specific client handoff. ## Takeaways - Understand who owns the work, what they need and where it stalls. - Keep useful controls and question steps that only compensate for the current tools. - Build a small complete path, watch it in use and revise the model with the team. READING PATH · 1 OF 6 ## Improving business workflows Understand the work people actually do before changing the software that supports it. [Next: The person missing from the diagram Find the people who keep handoffs moving and make their responsibilities explicit.](https://treenodes.com/articles/the-person-missing-from-the-diagram/) [View the complete reading path](https://treenodes.com/articles/reading-paths/#work-the-system-cannot-see) 1. 01 Software should follow the business 2. [02 The person missing from the diagram](https://treenodes.com/articles/the-person-missing-from-the-diagram/) 3. [03 What the spreadsheet knows that the system does not](https://treenodes.com/articles/what-the-spreadsheet-knows-that-the-system-does-not/) 4. [04 The exception path is the real workflow](https://treenodes.com/articles/the-exception-path-is-the-real-workflow/) 5. [05 Kaizen, applied to software](https://treenodes.com/articles/kaizen-and-software/) 6. [06 Jira and Confluence: From a Business Question to a Working Feature](https://treenodes.com/articles/jira-confluence-business-question-to-working-feature/) **REFERENCES AND FURTHER READING — 10 sources** 1. [How Do Committees Invent?](https://www.melconway.com/Home/Committees_Paper.html) — Melvin E. Conway, Datamation 14(4), April 1968, pp. 28–31 — The original observation that a designed system tends to reflect the communication structure of the organisation that produced it. 2. [The Mirroring Hypothesis: Theory, Evidence, and Exceptions](https://doi.org/10.1093/icc/dtw027) — Lyra J. Colfer and Carliss Y. Baldwin, Industrial and Corporate Change 25(5), 2016, pp. 709–738 — A review of 142 empirical studies. Mirroring is a prevalent pattern in firms and industries, but it is not universal and can sometimes be broken deliberately. 3. [Domain-Driven Design: Tackling Complexity in the Heart of Software](https://www.domainlanguage.com/ddd/) — Eric Evans, Addison-Wesley Professional, 2003 — The foundation for ubiquitous language, model-driven design and bounded contexts. A bounded context is a boundary around a coherent model, not automatically a department. 4. [A Field Study of the Software Design Process for Large Systems](https://doi.org/10.1145/50087.50089) — Bill Curtis, Herb Krasner and Neil Iscoe, Communications of the ACM 31(11), 1988, pp. 1268–1287 — A study of 17 large projects that identified domain knowledge, changing requirements and communication as major influences on design work. 5. [On the Criteria To Be Used in Decomposing Systems into Modules](https://doi.org/10.1145/361598.361623) — David L. Parnas, Communications of the ACM 15(12), 1972, pp. 1053–1058 — The classic argument for drawing modules around design decisions likely to change, rather than merely around steps in a processing sequence. 6. [Coordination Breakdowns and Their Impact on Development Productivity and Software Failures](https://doi.org/10.1109/TSE.2012.32) — Marcelo Cataldo and James D. Herbsleb, IEEE Transactions on Software Engineering 39(3), 2013, pp. 343–360 — In two large industrial projects, gaps between technical coordination needs and actual coordination activity were associated with more failures and lower productivity. 7. [Sociotechnical Principles for System Design](https://doi.org/10.1016/S0003-6870\(00\)00009-0) — Chris W. Clegg, Applied Ergonomics 31(5), 2000, pp. 463–477 — A modern account of joint design: work practices, social arrangements and technology are interdependent parts of one system. 8. [Enterprise Architecture as Strategy: Creating a Foundation for Business Execution](https://cisr.mit.edu/publication/enterprise-architecture-as-strategy) — Jeanne W. Ross, Peter Weill and David C. Robertson, Harvard Business School Press, 2006 — Connects operating-model choices about integration and standardisation to the architecture needed to execute them. 9. [Team Topologies: Organizing Business and Technology Teams for Fast Flow](https://teamtopologies.com/book) — Matthew Skelton and Manuel Pais, IT Revolution Press, 2019 — A practitioner synthesis of stream-aligned ownership, cognitive load, team interactions and the Inverse Conway Maneuver. 10. [Accelerate: The Science of Lean Software and DevOps](https://itrevolution.com/product/accelerate/) — Nicole Forsgren, Jez Humble and Gene Kim, IT Revolution Press, 2018 — Research connecting loosely coupled, independently testable and deployable systems with stronger software-delivery performance and faster feedback.