Interview: Inside the Mind of a System Architect

We sat down with Lena Ortega, a seasoned system architect at a rapidly scaling fintech, to discuss the role of diagrams in decision making, onboarding, and incident response. Below are edited excerpts from our conversation.

Why do diagrams matter to you?

Lena: Diagrams do three things for me. They clarify boundaries, assign responsibility, and surface assumptions. When I see a diagram I immediately start scanning for ownership gaps, data flow bottlenecks, and unclear handoffs. If those things are obvious in a diagram, you save dozens of follow-up questions in meetings.

"A good diagram reveals questions you did not know to ask."

How do you approach creating a diagram?

Lena: Start with a story. I sketch the primary flow or user journey by hand, then refine with collaborators. I keep shapes minimal and label aggressively. Ownership and SLAs are essential metadata for me. Every diagram has an owner and a review cadence. That prevents drift.

Can you share a time a diagram prevented a costly mistake?

Lena: We once proposed a change that moved an authorization check from the gateway to a microservice. The diagram highlighted a critical path where synchronous calls would increase latency across several services. Because the diagram made the bottleneck obvious, we explored an event-driven alternative and avoided a major performance regression in production.

What tools and techniques do you rely on?

Lena: I use combination of a structured diagramming tool and plain text. For quick alignment I sketch in a shared whiteboard. For durable artifacts I prefer a diagram editor where elements carry metadata and you can attach runbooks. Automation matters: even simple scripts that validate naming conventions and required metadata fields save time later.

How do you keep diagrams up to date?

Lena: Ownership is key. Each diagram must have a listed owner and a calendar reminder for review. We also tie diagrams to release PRs so a change in architecture triggers a PR that must update the corresponding diagrams. That keeps the artifact part of the change workflow.

What are the biggest anti-patterns you see?

Lena: First, diagrams that are too pretty and not truthful. Second, diagrams that try to be all things to all people. Third, diagrams without ownership. Finally, diagrams that lack metadata — no owner, no SLA, no link to code or runbook. Those are the ones that become stale fast.

Advice for teams adopting diagram-driven workflows

Lena: Start with high-value diagrams such as the critical path for payments or the main data pipeline. Add minimal metadata and attach an owner. Automate checks for naming conventions and required fields. And build a habit: review diagrams as part of release checklists and incident postmortems.

Closing thoughts

Lena: Diagrams are infrastructure for knowledge. Invest in their quality and make them part of your engineering hygiene. With the right practices, diagrams reduce meetings, speed onboarding, and make incident response more precise.