openskills.info
Course Preview

Architecture Diagramming

Architecture diagramming is the practice of representing software and infrastructure systems visually to communicate structure, relationships, and boundaries. It helps teams align on how components interact without ambiguity that prose descriptions often leave.

itEnterprise architecture and integration

Don't Panic — Architecture Diagramming

An architecture diagram is not a miniature copy of the system, squeezed into rectangles until nobody can read it. It is a view: selected elements and relationships arranged so one audience can answer one question. This sounds modest because it is modest. The modesty is doing the useful work.

Start with a sentence that names the audience, the question, and the system in scope. That sentence is the small fence that keeps a context diagram from acquiring database tables, deployment nodes, three kinds of arrow, and a mysterious purple cloud. The purple cloud may be accurate. It is still not invited unless it answers the question.

The two boundaries are the machinery behind this restraint. The scope boundary says what part of the system belongs in the view. The abstraction boundary says what kinds of things may appear there. A context view can show people, one software system, and its direct external systems. A container view opens that system to applications and data stores. A deployment view maps instances onto infrastructure in one named environment. They are neighbors, not ingredients for the same soup.

Arrows deserve the same courtesy. Give each one direction and a label that states the action. “Submits order via HTTPS” tells a reader who starts an interaction and how. “Uses” tells them that an author once knew something and has now declined to say what it was. Add a legend when shapes, colors, borders, or lines carry meaning; color alone is an unreliable translator.

The surprise is that omission is often more truthful than detail. You may leave out a private endpoint when the audience needs a system boundary. You may not invent a network placement to make the picture look complete. Mark proposals and assumptions. Keep current and target state apart. Diagrams are allowed to be incomplete; they are not allowed to be confidently fictional.

Next, use the Intro for the architecture vocabulary and view types. The Slides compress the sequence from landscape to focused view. The Cheatsheet gives you a brief, selector, relationship card, and review list. Then use the practice exercise to make one context view and ask another reader whether it says what you meant. That last step is where the boxes stop admiring themselves and start communicating.

Where this skill leads

Relevant careers

See how this topic contributes to broader role-level skill maps.

Sources

  • https://www.iso-architecture.org/ieee-1471/cm/
  • https://www.iso-architecture.org/ieee-1471/ads/
  • https://c4model.com/introduction
  • https://c4model.com/diagrams
  • https://c4model.com/diagrams/system-context
  • https://c4model.com/diagrams/container
  • https://c4model.com/diagrams/component
  • https://c4model.com/diagrams/dynamic
  • https://c4model.com/diagrams/deployment
  • https://c4model.com/diagrams/notation
  • https://c4model.com/diagrams/checklist
  • https://c4model.com/tooling
  • https://learn.microsoft.com/en-us/azure/well-architected/architect-role/design-diagrams
  • https://learn.microsoft.com/en-us/azure/architecture/icons/
  • https://www.omg.org/spec/UML
  • https://www.omg.org/spec/UML/2.0/
  • https://www.omg.org/uml/why-uml-is-important.htm
  • https://c4model.com/history
  • https://c4model.com/faq
  • https://docs.structurizr.com/
  • https://github.com/plantuml/plantuml/blob/master/LICENSES.md
  • https://www.diagrams.net/
  • https://www.lucidchart.com/
  • https://www.microsoft.com/microsoft-365/visio/flowchart-software
  • https://icepanel.io/