The Swedish Enforcement Authority: one architecture, mandatory for 50+ applications
01 OCT, 2026 · 7 min read
Picture seven systems standing side by side. Each one runs from its own backend down to its own screens, and each screen belongs to exactly one system. Now draw the business processes across them: deciding a debt restructuring case, ruling in a summary process, distributing payments, enforcing a claim. Every one of those processes cuts through several of the pipes.
That was Kronofogden, the Swedish Enforcement Authority, after a decade of department-led digitalisation. Each department of the national agency had solved its own problems well, but independently. The estate was organised around applications. The work was organised around processes. Nobody could see the whole picture, and the knowledge of how it fit together lived in a few people.
Several attempts at a reference architecture had already been made. None had been approved. They sat in a drawer, each one reasonable on its own, none of them adopted.
What leadership asked for
The brief was not "give us a modern architecture". It was six outcomes, written down before any design work started:
- Fewer people, less time to build a new solution
- No hard dependency on any single vendor, product or framework, so future changes stay cheap
- A lifecycle perspective built in from day one
- High testability, at unit level and across system integrations
- Shared components built, used and maintained in common, so one-off parts shrink
- Step-by-step adoption in existing systems, not just new ones
That last point mattered most. A reference architecture that only works for greenfield projects is a drawer document waiting to happen.
What we did
Our founder, Andrew Saka, led the work from the initial mapping, through approval in the architecture board and on into the pilot adoptions in existing systems. He was lead author and content owner of the reference architecture, and supported team after team as they adopted it across departments. We started with what was actually running, not with the documentation. Mapping the estate as it actually ran showed the true dependencies and where complexity had accumulated. That made it possible to leave redundant complexity behind instead of carrying it into the new design.
From that map we wrote a reference architecture the organisation owns, with every pattern and principle documented and justified. Alongside it we built a working reference application, so the architecture council could approve running software, not slides. And because most of the estate already existed, we defined a migration approach that lets existing systems adopt the architecture in small steps, with new functionality built the new way alongside the old.
Delivery was phased and done alongside Kronofogden's own teams across several departments. The goal was not just a good design but the capability to sustain and evolve it without us.
The outcome
Gartner reviewed the architecture.
“During our document review, I was impressed at the thoroughness of your document. I found all the recommendations in your document to be good.”
The architecture was also presented to other Swedish government authorities, the Swedish Tax Agency and the Swedish Companies Registration Office among them, before being approved by Kronofogden's IT architecture council and IT director. It was made mandatory for every web based application, more than 50 of them, and designed to hold for at least a decade.
What changed underneath: a new system starts from a shared foundation instead of a blank page. Pages and components built by one team become available to others. Developers move between systems and recognise the patterns. Build versus buy and integration decisions happen against a shared standard instead of a conversation with the two people who know. Security requirements are met once by the architecture, not solved again by every system.
The pipes are still there. The work no longer has to fight them.
Why this case shaped how we work
The approach we took at Kronofogden is what we later codified as CLEAR. The lesson was not that the architecture was clever. It was that the order of work mattered: see the estate as it really is, remove before you add, then establish something owned and prove it in phases. That is the pattern we bring to every engagement.
Where to start
If your organisation has its own row of stovepipes, or its own drawer of unapproved attempts, the Architecture Signal assessment gives you a scored picture of where the estate stands and where the real risks sit. It takes about ten minutes. If the picture raises questions you would rather discuss, the next step is a free 30-minute Architecture Diagnostic. That is how every tDigital engagement starts.