Skip to content

Strategy & Systems Design

Solution architecture: every part traced to a requirement

Before anything is built, the system should be something you can look at: its parts, what each one does, which records it owns and what crosses between them. Every part traces back to something the business needs, and every need lands in a part. A part that traces to nothing is left out, however good it would look on a diagram. You get a plan you can check before paying for code.
Talk through your systemSee the seven parts ↓
requirementsparts of the systemR1Technicians close out jobs on site,with photosR2Invoices reach accountingwithout re-typingR3Invoices over $2,500 waitfor the managerR4Customers get remindersand can see their jobR5The owner sees jobs and revenueby area each weektechnician app← R1office app← R3customer account← R4backend · database · files← R1 · R2 · R3accounting connection← R2reminders · queue and texts← R4weekly report · reporting copy← R5customer chatbotno requirement · left out

Seven parts, one job each

The screens own nothing. Every record has one home, and everything else asks it.
Technician appclose out a job on site, with photosnothing; it asks the backend
Office appschedule, approve and follow upnothing; it asks the backend
Customer accountlet customers see and approve their jobsnothing; it asks the backend
Backend, database and filesapply every rule and keep every recordcustomers, jobs, photos, invoices
Accounting connectionsend invoices to accounting and record what came backthe record of what was sent
Reminderssend texts at the right time, and retry when they failthe record of every message
Weekly reportanswer the owner's questions without slowing the officethe reporting copy, refreshed hourly

Three decisions, written down

Each one with what it cost and what would change it, so the next person doesn't have to guess why it was done this way.

One backend, not separate services

Decided
one backend, divided into jobs, customers, scheduling and billing
Because
a small team, one database, and parts that usually change together
Gave up
scaling or releasing one part on its own
Revisit if
one part needs to scale or be released separately

What the architecture draws

The lines matter more than the boxes.

  1. 01

    Who owns each record

    One home, everyone else asks

    Two parts keeping the same record will eventually disagree.

  2. 02

    What crosses each line

    And in which direction

    Every connection says what it carries, who starts it and what happens if the other side is down.

  3. 03

    Now or later

    Before the screen answers, or after

    Only what the person needs to see happen waits; the rest is queued.

  4. 04

    Where people decide

    Software stops here

    The points where a person takes over, with what they need in front of them.

  5. 05

    Where each part runs

    And who looks after it

    Bought tools, built parts, and who's responsible when each one has a problem.

  6. 06

    What's left out

    With the reason

    Parts that were considered and not built, so nobody adds them later without asking why.

Tool by tool, or one designed system

Tool by tool

  1. 01A new tool for each problem as it comes up
  2. 02The same customer kept in each one
  3. 03Connections added when someone complains
  4. 04Nobody can draw the whole thing

Each tool works. The business runs on the gaps between them.

One designed system

  1. 01Each part there for a requirement
  2. 02One home for each record
  3. 03Connections planned with the parts
  4. 04A drawing anyone can read

Fewer parts, and every one of them has a reason.

What the architecture is drawn from, and what it decides next

Drawn from

Requirements
from the future-state design
Tools that stay
and what they hold
Constraints
budget, team, rules
Solution architecture
parts, owners, connections, decisions

Decides next

Integration architecture
how records move
Technology selection
build, buy or keep
Roadmap
what comes first

Worth doing when several parts have to work as one

Good fit

  • Several apps, people and tools have to work as one system.
  • You want to see the system's shape before paying to build it.
  • You're replacing tools and need to know what depends on what.

Not the right fit

  • A single app with one job. Its shape is obvious.
  • An off-the-shelf product already does what you need.

Where this capability is used

Next to solution architecture

Questions about solution architecture

Do you just produce diagrams?

Diagrams and the reasons behind them. A drawing without its decisions doesn't help the next person who has to change the system.

Can another team build from it?

Yes. It's written to be built from, by us or by someone else.

How do you keep it from being over-engineered?

Every part has to trace to a requirement. Parts that don't are left out, and the reason is written down.

What happens when requirements change?

The trace shows which parts a change touches. If it touches one, it's a normal change. If it touches many, that's the moment to revisit the design, before building.