Chapter 1 — Computing and service architecture
Lesson map
Lesson 01 published. Map, example, EX001.
flowchart TD
N0["Learning outcomes"]
N1["1.1 Services"]
N2["1.2 Tiers"]
N3["1.3 Where testing starts"]
N4["1.4 Fragile dependencies"]
N5["1.5 Architecture diagram discipline"]
N6["1.6 Change windows"]
N7["1.7 Owner contacts on the diagram"]
N0 --> N1 --> N2 --> N3 --> N4 --> N5 --> N6 --> N7
N7 --> EX["Worked example"]
EX --> Q["Exercise EX001"]
Logical drawing
flowchart LR
N0["Learning outcomes"]
N1["1.1 Services"]
N2["1.2 Tiers"]
N3["1.3 Where testing starts"]
N4["1.4 Fragile dependencies"]
N5["1.5 Architecture diagram discipline"]
N6["1.6 Change windows"]
N7["1.7 Owner contacts on the diagram"]
N0 --> N1 --> N2 --> N3 --> N4 --> N5 --> N6 --> N7 --> Q["EX001"]
[Learning outcomes]
|
v
[1.1 Services]
|
v
[1.2 Tiers]
|
v
[1.3 Where testing starts]
|
v
[1.4 Fragile dependencies]
|
v
[1.5 Architecture diagram discipline]
|
v
[1.6 Change windows]
|
v
[1.7 Owner contacts on the diagram]
|
v
[Worked example] --> [Exercise EX001]
Learning outcomes
You will (1) sketch NMT's main services; (2) explain tiers and trust boundaries; (3) locate where authorized testing usually starts; (4) identify fragile dependencies.
1.1 Services
NMT runs a public website, a journey planner API, a staff intranet, Active Directory for employees, a VPN, and a fare-collection network that is out of scope for ordinary tests. Sam Park's ordinary authorized work at Northline Municipal Transit covers the public website, the journey planner API, the staff intranet, Active Directory and the VPN. The fare-collection network is drawn on every diagram in red and stays out of ENG-512 unless a specialised ROE is signed. Confusing those services with fare gates is how operators ask for probes they must not run.
1.2 Tiers
Internet-facing web and API tiers sit behind a load balancer; application servers talk to databases; staff identity sits in AD. Trust boundaries are the places where packets or credentials cross from less trusted to more trusted zones. At NMT the load balancer fronts both the public website and the journey planner API, so one WAF rule set covers both. The AD boundary matters because a phished staff password crosses from the VPN into the staff zone. Sam's ENG-512 checks start outside the WAF and stop before the fare network, because crossing that line without specialised authorization is out of scope.
1.3 Where testing starts
Authorized technical tests usually start at internet-facing web and API tiers and at staff remote access, because that is what strangers and phished staff reach first. Strangers reach the website and journey planner API, while phished staff credentials reach the VPN, which is why those three come first. Fare validators and radio gear are not starting points for ordinary windows. Sam's ENG-512 kickoff sheet therefore lists website, journey planner API and staff VPN in that order, with fare validators listed under do-not-touch, and no tool runs before it is read. Starting elsewhere is a scope error even if a tool makes it easy.
1.4 Fragile dependencies
Fare gates and radio systems can harm operations if disturbed. They stay excluded unless a specialised engagement says otherwise. A stuck validator at a busy station during the morning peak would turn a test into a rider-facing incident. Sam's kickoff sheet lists fare validators and radio under do-not-touch, beside the name of the operations contact, and his ROE for ENG-512 repeats the exclusion in the same sentence as the Saturday window so nobody treats fare as an interesting side path. Specialised fare work would need separate funding, a different ROE and operators trained on validators; ordinary Saturday windows never inherit those rights. Sam repeats that boundary when managers ask for just a quick look.
1.5 Architecture diagram discipline
Sam keeps a dated diagram with owners on each box. The date sits in the title block, next to the network owner's initials from the last confirmation. Testing against an outdated diagram causes scope errors such as probing a retired staging host that now shares a name with production. Before ENG-512 Sam asks the network owner to confirm the diagram date in writing and files that confirmation under the ENG-512 ticket before lab_ports runs. A diagram without that confirmation is treated as untrusted even if it looks familiar.
1.6 Change windows
Architecture changes, such as a new API gateway or an AD upgrade, trigger a review of the ROE before the next test. The trigger list sits at the top of the ROE, so the network owner knows which changes require a fresh signature. Sam will not reuse last quarter's ENG window if the journey planner moved behind a new WAF rule set without a signed update. After an AD upgrade he re-checks tst-sam-web group membership and MFA before the next window. Reusing last quarter's ROE without that check is how stale rights survive.
1.7 Owner contacts on the diagram
Every box on Sam's diagram names a person, not only a team. When a finding appears on the journey planner API, he knows whom to call without hunting through a directory. The journey planner API box, for example, carries the API owner's name and an out-of-hours number. That saves minutes during a stop, when the SOC needs a decision from the owner rather than a directory search. The diagram contacts are copied into the ENG-512 kickoff note and the SOC start message, so overnight responders reach the API owner without calling Sam's personal phone. A team-only label is not enough.
1.8 Why diagrams go stale
A contractor adds a staging CDN and nobody redraws the picture. Contractor changes reach the diagram only when someone files the redraw, so Sam asks the contractor lead what changed since the last engagement. His first task each engagement is to confirm the diagram with the network owner in writing; a stale box is how an approved listener list becomes wrong before lab_ports even runs. When a staging CDN appears without a redraw, Sam opens a model-update ticket before any new listener is trusted. Stale pictures are the root cause of many NOT APPROVED surprises.
Worked example (synthetic NMT)
Sam draws NMT: Internet → WAF → web/API → app → DB; separate path VPN → jump → intranet/AD; fare network drawn in red as out of scope.
Synthetic case — Northline Municipal Transit (NMT). The transit agency, Sam Park and all figures are invented for teaching.
Errors and limits
Live transit systems and fare equipment are never tested without a separate, specialised authorization. This book uses synthetic data only and grants no authority to test real systems.
Exercises
- EX001 — Boxes. List five NMT services. Rubric: 3 = five correct; 2 = four; 1 = two; 0 = none.
- EX002 — Trust boundary. Give one trust boundary on Sam's drawing. Rubric: 3 = e.g. Internet to WAF/web, or VPN to jump; 2 = vague; 1 = minimal attempt; 0 = none.
- EX003 — Why fare is red. Why is fare-collection out of ordinary scope? Rubric: 3 = operations/safety impact if disturbed; needs specialised auth; 2 = partial; 1 = "old"; 0 = none.
- EX004 — Start point. Where do ordinary authorized tests start at NMT? Rubric: 3 = internet-facing web/API and staff remote access; 2 = partial; 1 = fare gates; 0 = none.
Synthesis
Architecture shows tiers, trust boundaries and exclusions before any tool runs.