What a solution architect actually delivers in the enterprise: a field guide for your first 90 days

Congratulations — you're a solution architect now. If your title came with a vague mandate to "own the architecture" and not much else, you're in good company. The role is one of the most misunderstood in the enterprise: people think the job is drawing diagrams or choosing technologies. It isn't. Your job is to make good technical decisions legible, durable, and trusted across an organization that is spending real money and real engineering hours based on them.

Put differently: your output is not a diagram. Your output is the artifacts that let a business commit to a direction with its eyes open — and the alignment that makes those artifacts stick. This guide is the deliverables list nobody handed you, plus how the role is actually judged and the traps that quietly end careers.

What you're really there to produce

Strip away the org chart and a solution architect exists to reduce the cost of being wrong. Big technical bets — a platform migration, a new system, a vendor choice — are expensive to reverse. You de-risk them: surface the options, make the trade-offs explicit, write the decision down, and get the right people to agree before the money is spent. Everything below serves that.

The core deliverables, ranked by leverage

• Architecture Decision Records (ADRs) — the single highest-leverage thing you produce. Each ADR captures one decision: the context, the options considered, the choice, and the consequences. Six months later, when someone asks "why did we do it this way?", the ADR is the answer — and it's why the decision survives reorgs and your own memory. If you do nothing else well, write ADRs.
• A system context diagram — one picture that shows the system, its users, and the external systems it touches. Not the 200-box everything-diagram; the boundary. It's the artifact that gets a room of people who think they agree to discover they don't.
• Non-functional requirements (NFRs) — the targets nobody else owns: performance, availability, scalability, security, recoverability, compliance. "Fast" and "reliable" are not requirements; "p95 < 300ms" and "99.9% monthly" are. Making NFRs explicit and testable is squarely your job, and it's where most projects quietly fail.
• The Solution Architecture Document (SAD) — the consolidated artifact that ties context, decisions, NFRs, and risks together so a reviewer (or auditor, or the next architect) can understand the whole solution without a meeting.
• A threat model — the obvious attack surfaces and what mitigates them. You don't need to be the security team; you need to have thought about it before they ask, and to partner with them early rather than getting blocked at the end.
• A cost / TCO model — cloud spend, licensing, and the operational cost to run the thing. Architects who hand finance a surprise lose credibility instantly. Architects who bring the cost conversation unprompted get trusted with bigger decisions.
• A RAID log — risks, assumptions, issues, dependencies. Unglamorous, and the first place a delivery lead looks when things wobble. Keeping it current is cheap insurance.
• A roadmap and migration / phasing plan — how you get from today's state to the target without a big-bang rewrite. The target architecture is the easy part; the credible path to it is the deliverable that earns sign-off.
• Reference architectures and guardrails — once you're established, the patterns and paved roads that let delivery teams move fast without re-litigating the same decisions. This is how one architect scales to many teams.

Your first 90 days: earn the right to change things

The fastest way to fail as a new architect is to arrive with opinions. You don't have the context yet, and the org can smell it. Spend the first weeks listening: map the system landscape, find who actually makes decisions (rarely the org chart), learn the history of why things are the way they are, and identify the one or two real pain points everyone already agrees on.

Then pick a single, visible deliverable and do it credibly — a context diagram that finally aligns a contested scope, or an ADR that resolves a decision that's been stuck for months. One artifact that demonstrably reduces confusion or unblocks delivery buys you more authority than a six-month grand strategy nobody asked for. Architecture is influence without authority; trust is the currency, and you earn it with small, correct, useful outputs.

How the role is actually measured

Not by diagrams produced. You're judged on decisions that were made and stuck, risk that was surfaced before it became an incident, delivery that was unblocked, and stakeholders who stayed aligned. The best architects are often invisible in the success — the project just went smoothly — and very visible in their absence.

• Did the big decisions get made, written down, and not relitigated every quarter?
• Were the expensive risks (security, cost, scale, vendor lock-in) raised early enough to act on?
• Could teams build against your artifacts without booking a meeting with you?
• Did the architecture survive contact with reality — or was it fiction by the second sprint?

The traps that sink new architects

• Ivory-tower architecture — designs that are elegant on a slide and unbuildable by the team. If you're not close to the code and the constraints, you're guessing.
• Tech for tech's sake — choosing the interesting option over the boring one that fits. Your job is outcomes, not your résumé.
• Boiling the ocean — trying to fix everything at once. Pick the decisions that matter most and sequence the rest.
• Not writing decisions down — the most common and most damaging. A decision that lives only in a meeting didn't happen; it'll be remade, badly, in three months.
• Ignoring cost, security, and operability until the end — these are not someone else's problem you bolt on later; they're constraints you design within from day one.
• Over-documentation — a 90-page SAD nobody reads is as useless as none. Write the smallest artifact that makes the decision clear and durable.

Keep your artifacts honest (or they become fiction)

Here's the dirty secret of architecture documentation: it's accurate the day you write it and wrong by the next deploy. A diagram on a wiki that no longer matches production is worse than no diagram — it actively misleads. The discipline that separates good architects from frustrated ones is treating these artifacts as living, versioned, and tied to the real system, not one-time deliverables you produce for a gate review and abandon.

This is also the part of the job that's the most tedious and the easiest to skip under delivery pressure — which is exactly why so much enterprise architecture documentation rots. Tooling that generates the diagram, the decisions, the NFRs, and the threat model from your actual infrastructure-as-code — so the document is derived from reality instead of redrawn from memory — is how you keep the blank-page and the keeping-current work from eating your week. (It's the problem we built Architext to solve, but the principle holds whatever you use: derive your docs from the source of truth, and review them, don't redraw them.)

The throughline

Everything in this guide reduces to one job: make good decisions, make them legible, and make them durable. The diagrams, the SAD, the ADRs, the NFRs — they're all instruments for getting an organization to commit to a sound direction and stay aligned as reality changes. Master that, and the title takes care of itself.