Most network projects start with a diagram, but a diagram by itself does not represent an architecture.
Most of the time, when an engineer is asked to deliver an architecture, what they actually deliver is just a diagram of boxes, lines, labels, IP ranges, and zones. Over time, this has become so normalized that even clients often see the diagram as the architecture.
This is a typical experience when working with people who have spent most of their time configuring systems by following guides. If you are one of them, this post explains what architecture really means when someone asks you to hand it over.
A design diagram shows what is connected.Architecture explains why it is connected that way..
Difference may seem subtle, but it is where most troublesome or trouble-free networks are decided.
What a Design Diagram shows us?
- What devices are in the network?
- How are they connected?
- Where are the firewalls, routers and switches?
- What VLANs or subnets exists?
Basically, it focusses on structure only..
The main purposes of having design diagrams are to help engineers build, troubleshoot and communicate, If you think about it for a moment, "same diagram in two different environments can behave very differently in production", In other words "a diagram can be correct and still represent a fragile system".
What an Architecture gives us?
- Why was this kind of topology chosen?
- What trade-offs were made between cost, complexity and resiliency?
- Where are failure domains intentionally placed?
- What assumptions does this design rely on?
- What kind of failures is this network designed to survive?
Architecture captures intent, constraints and decisions which can never be covered by a diagram..
How it can relate to a architecture of a house / building in real world?
A house floor plan shows walls, doors, windows, rooms..
Architecture explains how the bedrooms are placed away from noise, how airflow and lighting are handled etc..
Same story applies to Networking..
What Diagrams don't show (but Architecture must..)
- Failure domains (what breaks when a link, device or control plane fails?)
- Blast radius (how far does an incident propagate before it is contained?)
- Operational Simplicity (how easy this network to be operated even at worst days?)
- Security Boundaries (where is trust enforced and why those points?)
- Growth Paths (what should be changed when the network is needed to be expanded?)
Architecture should answer these questions before they are asked by reality..
Why these things matter??
Most troublesome networks are not caused by missing devices in a diagram or a link, they are caused by architectural blind spots like hidden dependencies, unclear failure behaviours, overlapping responsibilities, unwanted complexity etc.
And that's also why Network Architects exist and they are paid for..
A Diagram becomes An Architecture when it has a story behind it,
Means when it is accompanied by;
- Clear reasoning for each major decision
- An understanding of trade-offs
- Explicit assumptions
- Awareness of failure scenarios
- Consideration for operations and humans
Architecture is the story behind the diagram.Without the story, the diagram is just a picture.
I wanted to start this blog to document those stories, the decisions, trade-offs and reasoning which turn network diagrams into real architectures, If you are interested, stay tuned..
