14 — Networks, Protocols, and the Day-to-Day Tools

OSI models and protocol acronyms were my least favorite cluster until I found its one habit. The model that organized it: networks are layered models, and every protocol and device lives at a specific layer — name the layer, and you've named where to debug [1]. That habit — naming the layer before reaching for a fix — is the practical payoff of the whole cluster, and it carries over from networking into almost everything else an architect does.

A computer network is a set of computers sharing resources, communicating over common protocols across wired, optical, and wireless connections arranged in various topologies [1]. The architect's job isn't to build the network; it's to design systems that communicate across it correctly and securely.

The layered models: OSI and TCP/IP

The OSI model has seven layers; the TCP/IP model is a more summarized four-layer framework that actually underlies how the internet works [2][3]. The roadmap's point is that these models help a developer design systems for interoperability — they describe the distinct responsibilities (physical link, network routing, transport, application) so you can reason about where a failure lives.

The reason both models exist: OSI is the teaching/reference model (more granular, good for thinking), and TCP/IP is the one the internet actually runs on (simpler, maps directly to real protocols like IP, TCP, HTTP) [3]. An architect reasons in TCP/IP and references OSI when the granularity helps.

HTTP and HTTPS: the application layer

At the application layer lives HTTP, the protocol underlying most web communication — defining how clients and servers exchange requests and responses [4]. HTTPS adds encryption on top of HTTP using TLS, protecting data in transit from being read or altered [4]. Nearly every modern web architecture relies on understanding how these protocols handle requests, headers, and status codes. The architect-relevant details: HTTP methods (GET, POST, PUT, DELETE), status codes, headers, and the fact that HTTPS is HTTP wrapped in TLS rather than a different protocol.

Proxies and firewalls: the intermediaries

Between client and server sit two important categories of intermediary.

A proxy is an intermediary server between a client and destination, forwarding requests and often adding caching, load balancing, or filtering [5]. Reverse proxies sit in front of backend servers to distribute traffic and hide internal infrastructure; forward proxies sit in front of clients. Architects use proxies to improve performance, security, and manageability.

A firewall is a network security device that monitors and filters traffic based on an organization's security policies [6]. It sits between a trusted network and an untrusted one (often the internet), allowing or denying traffic by rule. The architect's concern is that the firewall policy has to permit the traffic the system needs — a system that works on a developer's machine can silently fail in production because a firewall rule blocks the port.

The day-to-day tools

The roadmap tucks the collaboration tooling in alongside the technical skills, and they share a theme: they're how the work is tracked, communicated, and versioned.

• Git — the distributed version control system tracking changes to code over time, supporting branching and merging workflows that let teams develop features in isolation before combining them [7]. Almost every modern project relies on Git as its source-control foundation.
• Slack — the messaging layer connecting people to the information they need [8].
• Trello — a visual project-management tool based on boards, lists, and cards, popular for smaller teams or lightweight tracking [9].
• Atlassian tools (Jira, Confluence, Bitbucket, etc.) — support project tracking and documentation at scale: Jira manages tasks, sprints, and issues; Confluence stores documentation and design discussions [10]. Many enterprise teams standardize on these for both daily work tracking and long-term knowledge management.

These aren't architecture in the systems sense, but they're the substrate the architecture work happens on. An architect who can't read a Jira board or a Git diff is cut off from where the actual decisions get made and recorded.

How I use this

When a system can't talk to another system, I walk the TCP/IP layers: is the link up, is routing (IP) reaching the host, is the transport (TCP) establishing, is the application (HTTP) getting a sane response? Most "it doesn't work" incidents collapse to one layer once I check them in order. Firewalls and proxies I treat as explicit design constraints — the architecture has to fit the firewall rules and route through the proxies the environment provides. And I keep the collaboration tools as first-class: a decision that isn't in Git, Confluence, or a tracked ticket might as well not exist, because no one will find it again.

References

[1] "Networks," roadmap.sh — Software Architect. [Online]. Available: https://roadmap.sh/software-architect/networks

[2] Cloudflare, "What is the OSI model?," [Online]. Available: https://www.cloudflare.com/learning/ddos/glossary/open-systems-interconnection-model-osi/

[3] "TCP/IP Model," roadmap.sh — Software Architect. [Online]. Available: https://roadmap.sh/software-architect/tcpip-model

[4] "HTTP, HTTPS," roadmap.sh — Software Architect. [Online]. Available: https://roadmap.sh/software-architect/http-https

[5] "Proxy server," Wikipedia. [Online]. Available: https://en.wikipedia.org/wiki/Proxy_server

[6] Cloudflare, "What is a Firewall?," [Online]. Available: https://www.cloudflare.com/learning/security/what-is-a-firewall/

[7] "Git," roadmap.sh — Software Architect. [Online]. Available: https://roadmap.sh/software-architect/git

[8] Slack, "Getting Started with Slack," [Online]. Available: https://slack.com/intl/en-in/help/categories/360000049043

[9] Trello, "Trello Guide," [Online]. Available: https://trello.com/guide

[10] "Atlassian Tools," roadmap.sh — Software Architect. [Online]. Available: https://roadmap.sh/software-architect/atlassian-tools