A system architecture diagram shows the parts of a system, the boundaries between them and the data that moves across each boundary. Its value depends on the legend and the level of detail, so each picture should answer one question, such as where customer records are stored. Draw the picture in a diagramming tool, then explain it in writing beside the image, so readers who cannot see the picture can still follow it.
A context view shows your system with the people and outside services around it. A container view shows the applications and data stores inside it. Choose one level per picture, because mixing them forces readers to guess which boxes are systems and which are parts of a system.
Each arrow should name the request or data it carries and its direction, such as 'order status, read-only'. An arrow with no label makes the reader guess what it means.
Export the picture at full width, with text large enough to read when zoomed in. Add the exported image to the page and place the legend directly below it, so the two are never separated.
Weak: Database
Strong: Orders database, which holds order records and customer addresses
A name that says what it holds tells the reader what a failure would affect.
Weak: API
Strong: Public booking API, which accepts requests from the website and checks each one at the gateway
Saying who can call the component and where the check happens shows a reviewer where the risk sits.
Weak: Sends data
Strong: Sends stock levels once a night as a CSV file, one way, from the warehouse system to the storefront
Frequency, direction and format are what a reviewer needs to judge timing and failure.
Weak: Legacy system
Strong: Billing ledger, owned by the finance systems team and read-only during the migration
Ownership and access tell a reviewer whom to ask and what the change may touch.
A picture with forty boxes hides the three that matter. Group related services into one box, and say in the text which group handles customer sign-in.
A diagram that mixes today's system with the target design makes readers assume the planned parts are live. Mark future components with a dashed outline and a status label, or move them to a separate picture.
When a public network, a partner's systems and your private network share one undifferentiated cloud, a reader cannot see where a request needs checking. Draw each boundary and name it.
A reader using a screen reader, or one whose connection cannot load the image, gets nothing from a picture alone. Repeat the components and the main flows in plain text beneath it.
A template is a starting layout: a boundary around your system, the main components inside it, the external systems outside it and a legend. Copy that layout into your diagramming tool, then fill it with your own components. Explaining the finished picture is a separate job, and this guide covers it.
Choose a diagramming tool when the picture has to change over time, and look for one with shapes, connectors and an editable canvas. Export the final image once the picture is agreed, then use a written page to explain it, because a drawing tool will not explain the reasoning for you.
Only the components that answer the picture's question, which is usually a handful rather than dozens. When the detail grows, split the system into a second picture with its own question, and link the two so the reader can move between them.
Yes, as an image added to the page, with the legend and a written description underneath. Attain OS Content Creator takes up to five images during setup, so keep the picture's text large enough to read at phone width.
Follow the eight-step wizard: type, assets and description, images, branding, contact and call to action, Atty Suggestions, blueprint, and generate. Atty generates one HTML page in the background. Review it, then publish and share the page link or download the HTML file.
