· 3 min read

Available in: Norsk

Platform Architecture Is About More Than Technology

Platform Architecture Is About More Than Technology

I've worked with platforms across different contexts over time, in different organizations, with different teams, and eventually across brands and companies as well. Some things have varied, a lot has changed, but one thing has held true every single time: technology is rarely the hardest part.

The real challenges show up once multiple teams, products, or brands need to share the same foundation, when the pace is fast, expectations are high, and the platform has to both deliver today and hold up to change over time.

Architecture as a Question of Decisions

That's when architecture becomes primarily a question of decisions, not just what we build, but:

  • who makes which decisions
  • when they get made
  • whether they're still understandable a year or two later

When Good Intentions Drift Toward Ambiguity

Most platform initiatives start off the right way, with good intentions around autonomy, speed, and reuse. Teams get ownership, room to act, and trust. Then what usually happens in practice happens.

Decisions get made locally, entirely reasonably, given the context at the time. But over time, it becomes unclear which choices were deliberate and which simply emerged along the way. Architectural intent becomes implicit, and assumptions replace shared understanding.

The result is rarely chaos. More often it's something subtler: ambiguity. Teams do what they believe is right, and the platform keeps working, but the whole gradually becomes harder to explain, and the direction less clear. Past a certain scale, tacit knowledge stops being enough.

Architecture Is Something You Decide, Not Just Design

Over time, it became clear to me that platform architecture, in practice, has far less to do with diagrams than with ownership. On a shared platform, architecture isn't primarily something you design. It's something you decide.

Which decisions are shared? Which belong entirely to the teams? And where's the actual boundary between autonomy and shared responsibility? When these questions aren't made explicit, the vacuum fills up fast, with local workarounds, good intentions, and, eventually, growing complexity.

Traceability Is Underrated

One of the most underrated things in platform architecture is traceability. Sooner or later, the questions arrive:

  • Why was this solved this way?
  • Who made this decision?
  • Was this a deliberate architectural choice, or just something that happened along the way?

If the answers depend on someone remembering, the architecture is fragile. People change roles. Teams get reorganized. Context disappears faster than you'd expect. Architecture that can't explain itself doesn't scale well, no matter how elegant it once was.

Autonomy and Ownership Aren't Opposites

I've also learned that autonomy and architectural ownership aren't opposites. Quite the opposite, in fact. Autonomy works best when the boundaries are clear, when teams know:

  • what they fully own
  • what counts as a shared decision
  • why those boundaries exist in the first place

That's when things move faster, not slower. Uncertainty goes down. Discussions get better. Architecture becomes a tool for progress instead of friction.

The Core of Platform Architecture

For me, this has become the core of platform architecture, whether the work happens within a single organization or across brands and companies: platform architecture only becomes real once decisions are deliberate, visible, and traceable. Not because architects want control, but because platforms don't scale on assumptions.

For me, this isn't about winning architecture debates or building perfect models. It's about contributing to platforms that actually work over time, across teams, and through change. I've become increasingly focused on architecture as something practical and traceable, something that can withstand people leaving, organizations shifting, and context fading.

When decisions can still be explained long after they were made, the architecture has done its job. That's at least the kind of architecture I try to contribute to, and keep learning more about in practice.

Share this article

LinkedIn
Hugo Moen

Hugo Moen

Lead Architect

Writes about platform architecture, enterprise architecture and the interplay between technology and organization.

Follow on LinkedIn

Related articles