Architecture Maturity Assessment: a practical architecture maturity model for 10 to 100 engineers

Architecture Maturity Assessment: a practical architecture maturity model for 10 to 100 engineers

In a 10 to 100 engineer org, architecture problems don’t show up as “bad architecture.” They show up as cycle time spikes, incident load, and “only Alex knows that service.” Most teams end up in the messy middle where decisions happen fast, don’t get written down, and the system drifts quarter by quarter. The Architecture Maturity Assessment is a software architecture assessment that scores your practices against industry norms, then turns that score into a plan you can actually run in 30 to 90 days.

This matters because architecture maturity isn’t about prettier diagrams. It’s about shipping features with fewer surprises, and onboarding engineers in weeks, not quarters.

What is an architecture maturity model, and what this assessment measures

An architecture maturity model describes how consistently an organization makes, records, and enforces architecture decisions as it grows. It only works if it covers both code and the social system around the code.

The Art of CTO Architecture Maturity Assessment evaluates architecture practices against industry standards across governance, documentation, modularity, observability, and evolution capability. It’s not a “microservices score.” It’s a read on whether you can keep architecture coherent while still shipping.

The assessment looks at five dimensions:

• Governance: how decisions get made, recorded, and reviewed.
• Documentation: how easy it is to find, trust, and update architecture docs.
• Modularity: how clean service boundaries are, and how coupling shows up.
• Observability: how fast teams can detect, triage, and explain failures.
• Evolution capability: how safely teams adopt new tech without rewrites.

Most Series A and early Series B companies sit around level 2 to level 3. That’s normal. The goal isn’t level 5. The goal is “mature enough for the next 12 months of growth.”

A useful working definition for leaders:

Architecture maturity is the ability to make trade-offs explicit, keep them visible, and keep the running system aligned with them as teams scale.

That framing matches what a lot of architecture leaders are pushing for in 2025: architects reduce bottlenecks by helping teams make decisions, not by owning every decision themselves. InfoQ’s 2025 trends report calls out this shift toward facilitation and away from centralized decision making as a way teams move faster with better context fit (InfoQ Architecture Trends 2025).

Software architecture assessment: how to run it in a Series A or B org

A software architecture assessment fails when it turns into a slide deck and a blame hunt. It works when it produces a short backlog, clear owners, and a cadence you can stick to.

Here’s a field-tested way to run this assessment with 10 to 100 engineers.

The 60 minute assessment workshop format

Invite 6 to 10 people:

• CTO or VP Eng
• Staff engineer or architect (if you have one)
• Two tech leads from different domains
• SRE or platform lead (even part-time)
• Product lead for a core area

Run it like this:

• 10 minutes: align on the next 12 months. Headcount plan, product bets, and risk.
• 25 minutes: score each dimension. Capture one example per score.
• 15 minutes: pick the two lowest dimensions. Write 3 actions each.
• 10 minutes: assign owners and a date for a re-score.

The catch is the examples. A score without evidence turns into politics fast.

Use evidence prompts:

• Governance: “Show the last 3 architecture decisions and where they live.”
• Documentation: “Find the system context diagram in 2 minutes.”
• Modularity: “Name 2 services that can deploy without coordinating.”
• Observability: “Pull a trace for a slow request path.”
• Evolution: “List 2 tech choices you can change without a rewrite.”

This pairs well with our internal guide to architecture review without slowing teams down, and our playbook on writing ADRs that engineers will read.

The Architecture Maturity Flywheel (a simple model that sticks)

Most maturity models feel like something you’d see in a consulting deck. This one fits a startup cadence.

• Decide: make a trade-off and write it down.
• Publish: make it easy to find and hard to ignore.
• Verify: add checks in CI and runtime.
• Learn: revisit decisions after incidents and big product shifts.

This flywheel maps to evolutionary architecture ideas. Rebecca Parsons describes fitness functions as a way to encode governance into tests, so teams don’t need constant review meetings (Tech Lead Journal episode 201).

A quick decision matrix: where to invest first

Use this matrix after you score the dimensions.

Pick one primary dimension for the next 90 days. Teams that try to fix all five ship a lot of process and not much change.

Architecture practices evaluation: what “good” looks like at levels 2 to 4

For Series A and B, the sweet spot is often level 3 with a few level 4 behaviors in the riskiest areas. Level 5 is overkill for most teams.

Governance: from “who shouted loudest” to recorded decisions

At level 2, decisions happen in Slack and disappear. At level 3, decisions get recorded, and teams can find them later without asking around.

Concrete level 3 behaviors:

• ADRs exist for cross-cutting choices like data stores, API versioning, and auth.
• Decision owners are named, even if the owner rotates.
• Review triggers are clear, like “new service,” “new data store,” or “PII flow.”

Martin Fowler describes ADRs as a lightweight way to keep a decision log, popularized by Michael Nygard in 2011 (Martin Fowler on ADRs). Thoughtworks also pushes “decisions are recorded and shared through artifacts” as a core execution and governance practice, and calls out lightweight ADR tooling as enough for many orgs (Thoughtworks Enterprise Architecture Playbook PDF).

A practical metric:

• ADR coverage: 1 ADR per 2 to 4 months per product area is a healthy pace.

If the org writes 30 ADRs in a quarter, it’s writing essays, not decisions.

Documentation: the “freshness” problem, not the “no docs” problem

Most startups have docs. The problem is trust. Engineers stop reading docs once they get burned a couple times.

Level 3 documentation looks like:

• One system map that shows domains, data stores, and key flows.
• Service ownership and on-call rotation listed per service.
• Docs live with code and change in the same PR.

A practical metric:

• Doc findability: a new engineer finds the system map in under 2 minutes.

This ties to our internal guide on architecture diagrams that stay current, and our post on onboarding senior engineers without tribal knowledge.

Modularity: boundaries you can feel in deploys

Modularity isn’t a diagram. You feel it in deploys, incidents, and how often teams have to coordinate.

Level 3 modularity looks like:

• Clear service boundaries tied to business capabilities.
• Stable contracts for APIs and events.
• Limited shared databases, with a plan to unwind them.

A practical metric:

• Coordination cost: most services can deploy without a cross-team meeting.

InfoQ’s 2025 architecture discussions also highlight resilience patterns like cell-based architecture, which pushes teams toward stronger isolation boundaries (InfoQ 2025 trends podcast). You don’t need full cells at Series A, but the direction matters: isolate failure and isolate change.

Observability: the fastest way to buy back engineering time

At level 2, teams have dashboards. At level 3, teams can answer “why is this slow” with traces, not guesswork.

Level 3 observability looks like:

• Distributed tracing on critical request paths.
• Structured logs with request IDs and user IDs (hashed if needed).
• SLOs for the top 3 user journeys.

A practical metric:

• MTTR: median time to restore drops below 30 to 60 minutes for common incidents.

This connects to our incident postmortem guide and the Incident Postmortem tool for turning outages into architecture work.

Evolution capability: change without rewrites

Evolution capability is the difference between “we can migrate in 6 weeks” and “we need a rewrite.”

Level 3 evolution looks like:

• Tech radar decisions recorded and revisited quarterly.
• Deprecation policy for APIs and libraries.
• Migration playbooks for data stores and messaging.

A practical metric:

• Migration lead time: a standard library upgrade lands across 60 percent of services in 30 days.

The broader trend pressure is real. ICSE’s SATrends 2025 workshop points to AI, sustainability goals, and DevOps specializations as forces that keep pushing architecture change (SATrends 2025). Startups feel this as vendor churn, model changes, and new compliance asks.

Architecture governance tool: how to add governance without becoming a gate

An architecture governance tool should cut meetings, not create new ones. Good governance in a startup feels like a paved road, not a checkpoint.

The “Two Loops” governance pattern

Run governance in two loops.

• Fast loop: team-level decisions, recorded as ADRs, reviewed async.
• Slow loop: cross-cutting review once per sprint or per month.

Fast loop rules:

• ADRs are required for decisions that change constraints.
• Review is time-boxed to 24 to 72 hours.
• Disagree and commit is explicit, and the ADR records dissent.

Slow loop agenda:

• Top 3 risks from incidents and near-misses.
• Top 3 upcoming changes that cross domains.
• Deprecations and migrations that need coordination.

This matches what Thoughtworks calls “aligned autonomy,” where teams move fast inside clear constraints (Thoughtworks Enterprise Architecture Playbook PDF).

Operationalize ADRs with fitness functions

ADRs fail when they turn into a wiki graveyard. The fix is to connect them to checks that run every day.

Rebecca Parsons makes the case that automated fitness functions turn governance into tests that fail builds, so teams don’t need constant architecture review (Tech Lead Journal episode 201).

A practical pattern:

• Write ADRs in the repo.
• Add a CI check that enforces one constraint from the ADR.
• Add a runtime check for one system behavior, like latency budgets.

Platform Toolsmith describes a concrete method: let an agent read ADRs directly, then flag violations in PRs based on the ADR’s decision and consequences sections (Operationalizing ADRs with fitness functions). The key idea isn’t the agent. It’s the workflow: ADRs become living constraints.

A simple starter set of fitness functions for startups:

• Dependency rules: service A cannot import package B.
• API rules: public APIs must be versioned.
• Data rules: PII fields must be encrypted at rest.
• Resilience rules: timeouts and retries must be set on outbound calls.

This pairs well with our internal post on platform teams as internal products, since platform work often carries these checks.

Enterprise architecture maturity: why this still matters before you feel “enterprise”

“Enterprise architecture maturity” sounds like a 1,000 person problem. It’s also a 50 engineer problem, just with fewer layers and less patience for ceremony.

Here are the ways it hits Series A and B CTOs.

1. Fundraising and diligence: Buyers and investors ask about security, reliability, and change control. A maturity score and a 90-day plan answers that with evidence.
2. Customer trust: A single outage can stall a $200k to $1M deal. Better observability and clearer ownership reduces repeat incidents.
3. Hiring and onboarding: Senior hires leave when they can’t understand the system. Clear decisions and docs cut ramp time.
4. AI and platform shifts: 2025 architecture trends push architects to work closer with platform engineering and AI tooling (InfoQ 2025 trends podcast). Teams need a way to adopt new tools without chaos.

One question comes up in almost every scaling org: should architecture be centralized or embedded? Embedded wins for speed, but only if governance and documentation keep teams aligned.

CTO recommendations: a 90 day plan after the assessment

Immediate actions

1. Baseline score: run the assessment workshop and capture evidence for each score.
2. Pick one dimension: choose the lowest score that also blocks delivery today.
3. Create 5 ADRs: write ADRs for the top cross-cutting decisions already made.
4. Add one fitness function: enforce one ADR constraint in CI within 2 weeks.
5. Set one SLO: pick one user journey and define an error budget.

Policy framework

1. Decision policy: define what requires an ADR and what does not.
2. Review policy: define triggers for cross-team review and a 72 hour SLA.
3. Deprecation policy: define how APIs and libraries get retired, with dates.

Architecture principles

1. Constraints over opinions: write constraints teams can test, not preferences.
2. Docs near code: keep diagrams and ADRs in repos, not slide decks.
3. Boundaries match ownership: align services to teams, and teams to domains.

For tracking, pair the assessment with Command Center for a single view of risks, migrations, incidents, and capacity. For documenting target state, pair it with ArchiMate Modeler to keep architecture views consistent across teams.

Bigger picture: maturity is a growth strategy, not a compliance exercise

Architecture maturity is a compounding bet. Each recorded decision cuts future debate. Each automated constraint cuts drift. Each clear boundary cuts coordination.

The trend lines point the same way. Architects spend less time acting like gatekeepers and more time building decision systems that scale across teams (InfoQ Architecture Trends 2025). AI and platform tooling will keep changing the surface area of architecture work, but the core stays stable: clear decisions, visible constraints, and feedback from the running system.

The question is simple: when the org doubles from 30 to 60 engineers, will architecture get clearer or noisier?

Use the tool: Architecture Maturity Assessment

Sources

1. InfoQ Software Architecture and Design Trends Report 2025
2. InfoQ Architecture and Design Trends in 2025 podcast
3. SATrends 2025 at ICSE 2025
4. Thoughtworks Enterprise Architecture Playbook (PDF)
5. Architecture Decision Record, Martin Fowler
6. Stop Architecture Drift: Operationalizing ADRs with Automated Fitness Functions
7. Building Evolutionary Architectures: Automated Software Governance, Tech Lead Journal #201