You’ve stepped up from senior developer to Solution Architect (or even an Enterprise Architect. You’ve seen a few TOGAF slides, skimmed ArchiMate, maybe drawn some UML. None of that tells you how to help an organisation own its architecture day to day. Here’s the shift: your job isn’t to be the hero problem-solver; it’s to make yourself unnecessary by making knowledge easy to find, easy to reuse, and easy to improve. Do that and you’ll help ten teams today and a hundred next quarter.
For years the Architects sat in their ivory towers. Work flowed past a stage gate, a big review, a thumbs-up or thumbs-down. That model belongs to waterfall. It doesn’t fit how we build today.
Modern architecture is a service. You’re a consultant and a thought leader. Your job is to enable and unblock. You pave a golden path that lets teams ship faster with fewer mistakes. And you do it by making yourself unnecessary in the day-to-day: knowledge lives in the open, patterns are reusable, and decisions are visible. You won’t be out of a job; you’ll be working at the right altitude–coaching, curating, and steering outcomes.
Also, a quick reminder: architecture isn’t just coding new in-house solutions. Sometimes the smartest move is not to build. Your value is optimising the organisation–spotting leverage, reducing friction, creating space for innovation and growth.
Old role vs new role (at a glance)
- Then: Gatekeeper, big reviews, hand-offs.
Now: Guide, lightweight guardrails, tight feedback loops.
- Then: Documents at the end.
Now: Playbook and patterns from the start.
- Then: “Come to me for answers.”
Now: “Here’s the toolkit. You’ve got this.”
Your first move: create the Architecture Repository
Don’t start with a wall of diagrams. Start with a home for the work.
Set up a Confluence space or Notion workspace called Architecture Repository. Make it easy to find from your team’s homepage. Seed it with a small set of pages that move readers from why to how to what.
1) Vision & Objectives
Why architecture exists here, what “good” looks like, and a short roadmap. This frames every choice that follows.
2) Architecture Approach & Governance
How we architect. Keep it simple and copyable:
- Steps from idea → review → published artefact
- A diagram checklist: title, legend, version, status watermark
- Naming and versioning rules (e.g. SAD-015, BB-EventFlow-v1)
- When to write an ADR and how to link it
3) Policies & Standards
Security baselines, API rules, performance and observability expectations. These are the rails.
4) State of the Architecture
Two layers to start:
- Business: value chain and key stakeholders
- Application/Technology: a C4 Level 1 system map with links to detail
5) Decision Records (ADRs)
Small pages that answer “why” while the context is fresh. Same fields every time: ID, date, context, decision, rationale, impacted artefacts.
6) Solution Building Blocks (SBBs)
Reusable patterns your teams can drop into designs:
- Foundational concepts: idempotency, EDA, relational vs NoSQL
- Common patterns: CDC, outbox, retries, caching
- Organisation-specific implementations: “Billing Pipeline v1.2”, “Payments Webhook v2”, “Customer Creation Service v1.5”
Each block explains when to use it, shows a clear diagram, offers implementation options, and lists the projects that use it.
7) Solution Architecture Documents (SADs)
Blueprints for initiatives. They assemble SBBs, tie them to requirements, and sketch the high-level design and phasing.
SADs could relate to a project or programme of work.
Add Meeting Notes & Governance Logs and Artifacts & Links when you’re ready.
How SBBs, SADs and ADRs fit together
- A SAD references the SBBs it uses.
- Each SBB lists the SADs that consume it.
- ADRs link to both and are linked back from both.
From any page you should reach the related pattern, the impacted project, and the decision behind it in two clicks.
Naming, status and versioning that don’t get in your way
- Codes: SAD-###, BB-Name-v, ADR-###
- Status: show it in the title and as a property — [Idea], [WIP], [Approved], [Deprecated]
- Versions: drafts as 0.1, 0.2… first approved is 1.0, then 1.1, 1.2 for minor changes
- Keep a short changelog on the root page so the story is obvious
Diagrams
Just enough structure
Use C4 Level 1-2 for most work. Every diagram should have a title, legend, version, and status. Limit the use of colors and maintain consistent line styles for the same meaning throughout the diagram.
Annotate the diagram, especially if it’s showing the flow of data.
The ultimate goal is to ensure that anyone can read the diagram without your presence.
Relationship choices: keep them consistent
Under Architecture Approach, don’t stop at a diagram checklist. Add a short Diagram Design Guidelines page that codifies which relationships to use and when (with examples, arrow direction, and “do not mix” rules). Link this guideline from your diagram templates so every view follows the same rules.
If you use ArchiMate (Archi) or UML, pick one relation per interaction type and stick to it. Mixing styles across diagrams confuses readers.
- UI → API (sync): choose Serving (provider → consumer) or Accesses (consumer → provider). Standardise on one.
- Async events/messages: use Triggering from producer to consumer.
- Data access: use Access for reads/writes. Add r, w, or rw if supported.
- Message movement: if you model the message as a thing that moves, use Flow. Don’t mix Flow and Triggering for the same pattern.
Arrow direction matters
- Serving: provider → consumer
- Access: consumer → provider
- Triggering: cause → effect
Always add a small legend with the relations you use. Avoid publishing two diagrams that show the same UI→API call with different relations. Consistency beats cleverness.
Architecture is not (only) code
You’re here to create outcomes, not just components. Ask:
- Can we buy or integrate and focus our effort on differentiators?
- What’s the simplest path that meets today’s need and keeps tomorrow open?
- Which guardrails unlock the most teams with the least ceremony?
Think platform, not project. Think leverage, not lines of code.
A realistic first week
- Mon–Tue: Create the Repository. Publish Vision & Objectives and How we architect.
- Wed: Add templates for SBB, SAD and ADR plus a one-page diagram checklist.
- Thu: Write one foundational SBB and one common pattern your teams need now.
- Fri: Create the next project’s SAD root page, add a [WIP] v0.1 child, start the changelog, and walk the team through the space in 30 minutes.
What’s next
Next post we’ll dig into Solution Building Blocks & Solution Building Blocks, how to keep them small, composable and trustworthy, and how to avoid version sprawl. After that: SADs that scale, ADRs that stick, and a diagram style people actually follow.