How to create a solution architecture diagram with Yantra Studio
Build a solution architecture diagram from an empty page: place the components, record how they connect, tidy the layout, and leave it in a state someone else can review.
When this is useful
- You are proposing a design and need something concrete to discuss.
- An existing system has never been drawn and you are the one who has to do it.
- You want the diagram to stay useful after the meeting, rather than becoming a screenshot in a slide deck.
Before you start
- A diagram open on a page. Use Page ▸ New page if you need a fresh one.
- A rough idea of the components involved. You do not need the whole picture — connectors can be added at any time.
Step 1: Place the components
Use the Page menu to insert shapes for the parts of the system — an application, a service, a store. Entity / Table is the shape for anything with structure worth recording; a text box or a note carries the commentary.
Do not lay them out yet. Getting the right set of boxes on the page matters more than where they sit, and the layout step later will rearrange them anyway.
Page ▸ Entity / TablePage ▸ Text boxPage ▸ Note
Step 2: Record how they connect
Add a connector between each pair of components that talk to each other.
This is the step that separates a modelled architecture from a picture. A connector here is a recorded relationship, which is what later lets impact analysis and lineage answer questions about the diagram instead of you tracing lines by eye.
Page ▸ Connector
Step 3: Arrange the diagram
Run auto-layout and pick an arrangement. Hierarchical is the default and suits most layered solution architectures; force-directed reads better for a mesh of services; orthogonal grid suits a diagram that will be printed.
Auto-layout is a starting point. Move anything it placed awkwardly afterwards — nothing re-runs it behind you.
Shape ▸ Auto-layoutShape ▸ Hierarchical (default)Shape ▸ Force-directedShape ▸ Orthogonal / Grid
Step 4: Make it reviewable
Share the diagram by link, or add the people who should see it to the team and collaborators list.
If the design needs formal sign-off rather than comments, put it through the approval workflow instead.
Diagram ▸ Share linkDiagram ▸ Team & collaboratorsDiagram ▸ Approval workflow
What happens next
You have a model, not just a drawing. The connectors you drew are available to impact analysis and lineage, so a later question about what a change would affect can be answered from this diagram.
The obvious next moves are to record the risks and non-functional requirements against the components while they are fresh, or to run the design through simulation before anyone builds it.
Example
A three-service design: a web front end, an orders API and a Postgres database, with a queue between the API and a fulfilment worker.
Five shapes, five connectors, hierarchical auto-layout, then share the link. About ten minutes, and the result answers "what breaks if the queue goes down?" rather than merely depicting it.
Tips
- Start with the components you are sure about. A diagram with four correct boxes is more useful than one with twelve speculative ones.
- If the design resembles something well known, start from a template instead and edit it down — the simulation architecture templates cover many common shapes.
- Notes are for the questions you have not resolved. Leaving them visible is more honest than drawing a component you are not sure exists.
Limitations
- Auto-layout arranges what is on the page; it does not infer missing connections.
- Sharing, collaboration and the approval workflow are each separately enabled, so which of the step-4 options you see depends on your organisation.