Architecture & System Design: SFIA levels and developer seniority
Fennec team · 4 May 2026 · 4 min read
Architecture is the set of decisions that are expensive to change later: how services talk to each other, where the boundaries sit, what happens when something fails. Good architecture is often judged by what doesn't go wrong, which makes it a harder discipline to show evidence for than shipping a feature.
SFIA levels here move from following an existing pattern, to designing systems yourself, to setting technology strategy across an entire organisation.
1
Level 1: Follow
“I understand basic design concepts and can follow established patterns in my codebase.”
Evidence here is about deliberate practice: pull requests where you followed an existing architectural pattern on purpose, notes from a design walkthrough you sat in on, or a diagram you drew of an existing system just to understand it better.
Study your codebase's existing architecture and draw a diagram of it if one doesn't already exist, that exercise teaches you more than reading about patterns in the abstract. Ask why a pattern was chosen, not just how to use it, and deliberately follow one pattern in your next feature rather than improvising.
2
Level 2: Assist
“I contribute to design discussions, follow architectural patterns, and can articulate the trade-offs of simple decisions.”
The evidence shifts toward participation: contributions you made to a design discussion, a trade-off you articulated for a simple decision, or a diagram you produced for something you built without being asked to document it.
Speak up in one design discussion with a real trade-off rather than just a preference, and draw a diagram for something you built even if nobody requested one. Reading up on one architecture pattern relevant to your codebase gives you the vocabulary the next level depends on.
3
Level 3: Apply
“I design systems and services making well-reasoned trade-off decisions. I can draw a clear architecture diagram, explain why I made each choice, and spot the weaknesses in my own designs.”
Here the evidence is authorship: a system or service design you wrote up with a diagram and rationale, a weakness in your own design that you identified and addressed before anyone else pointed it out, or a design review where you defended your choices under real questioning.
Design a service and write down the trade-offs, including the ones you didn't pick, that written reasoning is often more valuable than the diagram itself. Get your design reviewed and defend it, and go looking for a weakness in an existing design rather than waiting for it to become an incident.
4
Level 4: Enable
“I own architectural decisions across multiple systems. I lead design reviews, define how services integrate, and make sure non-functional requirements (performance, reliability, security) are actually met, not just aspirations.”
By now the evidence spans systems: an architectural decision record covering more than one system, a design review you led, or a non-functional requirement, performance or reliability, that you made sure was actually met in production, not just written down as an aspiration.
Lead a design review for a cross-system change, and write an ADR for a decision more than one team depends on. Following a non-functional requirement through to production, not just the design doc, is usually what separates architects who are trusted from architects who are merely consulted.
5
Level 5: Ensure & Advise
“I define architectural standards and technology strategy across programmes or the organisation. I lead the architecture function and set the long-term direction.”
The evidence reaches across programmes now: architectural standards or a technology strategy you defined that spans more than one programme, and an architecture function you helped lead rather than simply participated in.
Write a technology strategy document that spans programmes, and build an architecture review process that outlives any single decision. Mentoring other architects tends to matter as much here as any individual design, since your judgement is now expected to scale beyond what you can personally review.
6
Level 6: Initiate & Influence
“I define enterprise architecture strategy and governance at an organisational level.”
At the top, the evidence is enterprise-wide: architecture strategy and governance you set, external recognition through talks or writing, and a technology bet at the organisation level that visibly paid off.
From here, publish your architecture thinking externally, set enterprise architecture direction, and expect most of your impact to come from the standards and reviews you put in place rather than any diagram you draw yourself.
Go deeper
A reference point for architecture patterns and trade-offs.
Architecture and engineering practice articles and talks.
System design explained through diagrams and real examples.
Knowing where you sit is one thing, proving it later is another. Fennec lets you log architecture & system design evidence as you go, a shipped feature, a decision, a review, tagged to the level it demonstrates, so the case for your next step is already made when you need it.