Most organisations treat their design system as a design team deliverable. The design team creates components in Figma, documents the usage guidelines, hands them to engineering, and hopes for the best. Six months later, three teams have built their own date picker because the official one didn't handle their edge case, and the "single source of truth" is a source of truth that no one trusts.

The problem isn't the design team. The problem is that a design system at enterprise scale is infrastructure. It needs the same architectural thinking, governance, and ownership model that you'd apply to your API gateway, your CI pipeline, or your deployment platform. Treating it as anything less guarantees fragmentation.

Why design systems break at scale

A design system that works for 20 developers breaks for 200. The reasons are structural.

No clear ownership model. When a component needs to change, who decides? In small teams, the answer is obvious: someone walks over and talks to the person who built it. At scale, component changes affect dozens of teams. Without a governance model, changes either don't happen (because no one wants to risk breaking other teams) or they happen unilaterally (because the team that needs the change doesn't want to wait).

One-size-fits-all components. Enterprise platforms serve different user types, different markets, and different contexts. A button component that works for a consumer-facing checkout flow has different requirements than one in an industrial control interface. When the design system can't accommodate this variation, teams fork the components. Each fork diverges. The system fragments.

No versioning strategy. Breaking changes to a shared component ripple across every team that uses it. Without versioning, teams face a choice: update immediately and risk regressions, or pin to the old version and drift further from the system. Both options are bad. A proper versioning strategy, with clear deprecation timelines and migration support, is what makes a design system usable at scale.

I worked on Deutsche Telekom's Magenta View CRM where 200+ developers across European markets depended on a shared component library. The pattern library wasn't just a collection of UI components. It was a governance system that determined how quickly teams could ship and how consistent the product remained across markets.

Design systems as architecture decisions

A design system is a set of architectural decisions about how your UI is structured, composed, and maintained. Each decision has trade-offs that affect developer velocity, product consistency, and long-term maintainability.

Component boundaries. Where does one component end and another begin? This is the same question as module boundaries in backend modularisation. Draw the boundaries too wide and components become rigid monoliths that can't adapt. Draw them too narrow and teams spend their time composing dozens of primitives instead of building features.

Customisation vs. consistency. How much can teams modify a component before it stops being part of the system? This is a spectrum, not a binary. Some components (buttons, form inputs, typography) need strict consistency. Others (page layouts, data visualisation) need flexibility. The architecture should express this distinction, not leave it to convention.

State management. Where does component state live? Who manages it? In a form-heavy enterprise application, the answer to this question determines whether teams can build features independently or are constantly coordinating around shared state. On the Siemens SIMATIC AX platform, decoupling component state was a prerequisite for the microfrontend architecture that brought build times from 30 minutes to under five.

Composition model. How do components fit together? Slots, props, render functions, compound components. Each approach has implications for reusability, testability, and the learning curve for new developers. This is an architecture decision, not a style preference.

Governance that scales

Design system governance is the set of rules that determine how components are proposed, built, reviewed, versioned, and retired. Without governance, a design system is just a component library that happens to have documentation. With governance, it's infrastructure that the organisation can rely on.

A clear contribution model. Who can add components? Who reviews them? What criteria must a component meet before it's accepted into the system? The best contribution models I've seen treat design system components like internal open source: anyone can propose, a core team reviews, and acceptance requires documentation, tests, and accessibility compliance.

Semantic versioning with migration support. Every breaking change gets a major version bump, a migration guide, and a deprecation window. Teams need time to adopt changes. Forcing immediate updates on 200 developers is how you get teams that refuse to update at all.

Usage analytics. Know which components are used, which are forked, and which are ignored. If a component has low adoption, either the component doesn't meet real needs or teams don't know it exists. Both are problems worth solving. If a component is frequently forked, it means the API isn't flexible enough.

Cross-functional review. Component changes should be reviewed by both design and engineering. A component that looks right but performs badly is broken. A component that's technically elegant but doesn't match the design language is also broken. The review process needs both perspectives.

The bridge between design and engineering

Design systems sit exactly at the boundary between design and engineering, which is why they fail when only one side owns them.

Design teams focus on visual consistency, brand language, and user experience. Engineering teams focus on performance, maintainability, and developer experience. A design system that serves only one side will be rejected by the other. The design system team (whether it's a dedicated team or a virtual team with representatives from both sides) needs to speak both languages.

This is something I've seen repeatedly across engagements. The organisations where design systems actually work are the ones where the system is owned at the intersection of disciplines, not within a single one. The design system architect role, whether that's a formal title or an informal responsibility, needs someone who understands component APIs and visual hierarchy, performance budgets and spacing systems, developer ergonomics and accessibility requirements.

What to watch out for

The design system that's really a style guide. If your design system is a set of Figma files and a CSS framework, you have a style guide. A design system includes component logic, behaviour, state management, and interaction patterns. The visual layer is the most visible part, but it's not the most important part.

Building for completeness instead of usage. Don't build 80 components when your teams use 15. Start with the components that every team needs: typography, layout, buttons, form controls, navigation. Add complexity as teams request it. A small, reliable system is better than a comprehensive, unreliable one.

Ignoring the adoption problem. A design system that exists but isn't used is worse than no design system at all. It creates the illusion of consistency while teams build their own solutions. Adoption is a product problem: you need documentation, examples, migration tools, and a support channel. Treat your design system like an internal product with your developers as the users.

The best design systems I've worked with were treated as infrastructure from day one. They had dedicated ownership, version control, CI pipelines, release processes, and cross-functional governance. They were architecture decisions, not deliverables. When you treat a design system as something the design team hands off to engineering, it breaks. When you treat it as shared infrastructure that both sides own, it scales.