Services
Architecture and organizational design
— where the friction actually is
I help organizations where the work gets stuck — between strategy and delivery, between teams, between the business and its systems. As an independent enterprise and solution architect in Stockholm, I take on a defined piece of work or a role for a period.
I work at every level the problem needs. In the boardroom on direction, investment and organizational design, and down with the teams, in the details of the data, the integrations and the solution, when that is where the answer is. Architecture that only exists on slides helps nobody, and neither does detail nobody has connected to where the business is going.
I work in Swedish and English, on site in the Stockholm area and remotely. My background and past assignments are on About. Läs på svenska.
Enterprise architecture and strategy validation
Reviewing architecture and strategic direction against where the organization actually needs to go — before committing further investment to either.
Target architecture, capability maps, roadmaps and the decisions behind them, checked against the business they are meant to serve. Useful before a large programme, a platform choice, or a reorganization.
Solution architecture
Designing the systems and integrations that make a capability real — target architecture, data flows and the platform decisions underneath them.
Hands-on solution architecture in complex end-to-end flows: customer and CRM, subscriptions and checkout, payments, orders, billing and ERP, advertising, marketing automation and integrations.
Interim chief architect and senior advisor
Stepping into a chief architect or senior advisor role during a transformation, a leadership gap, or a period that needs an outside perspective leadership can trust.
Leading an architecture function, sitting with IT and business leadership, and connecting direction, organizational design and technology execution — for a defined period.
Capability and domain design
Mapping what the organization actually does, and drawing the boundaries that let teams own it.
Business capabilities, bounded contexts and the information that crosses between them — the structure team boundaries, ownership and systems are then built on. This is where team design and architecture meet.
Architecture enablement
Guardrails — principles, decision records and coaching — that let architects and teams decide faster and more safely without an architect in the room.
Setting up the few rules worth agreeing on, the decision records that keep them honest, and the practice that lets teams move within them. Architecture as a competence the organization holds, not a queue it waits in.
Friction diagnostic — where work gets stuck
Finding where the friction actually sits before recommending anything — which is rarely where the budget already is.
A short, structured look at ownership, handoffs, decision latency and learning in one part of the organization. The result is a map of where work waits and why, and the few changes most likely to move it.
Methods and measures
The working tools behind these assignments — architecture guardrails, decision records, a tech radar, deciding where domain logic belongs, and the measures that show whether flow is improving — are described on Architecture methods and measures.
When this is relevant
- Decisions wait for weeks, and nobody can say exactly where.
- Teams keep having to ask other teams before they can finish anything.
- A transformation or platform programme is about to commit serious money, and the direction has not been tested.
- Nobody can say, by name, who owns a capability the business depends on.
- An AI pilot works in the demo and then stalls on data ownership or on who may approve the output.
- The architecture function has become a queue rather than a competence the organization holds.
- An insurer, a media house or a subscription business is changing its core platforms — policy, claims, advertising, checkout or billing.
How I work
I start where the work actually gets stuck, not where the budget already is. Most of what slows an organization down sits between the teams: unclear ownership, context lost at every handoff, decisions that wait. Fixing the architecture without seeing that is expensive, and so is the reverse.
Part of that is what I call the work harness: what whoever does the work actually has to act with — a clear outcome, the right context, boundaries, the right to decide, tools, and feedback on what happened. People and AI agents need the same six things, whatever the organization's AI maturity, and getting them clear is often where an assignment pays off first.
The approach is written up openly as Organizational Flow, a working theory of organizational friction. The key concepts are a quicker way in, and the self-assessment gives us something concrete to talk about.