How Small Teams Do Enterprise Architecture (and What We Can Learn from Them)

When we talk about enterprise architecture, the mind almost automatically goes to large organizations. IT departments with hundreds of people, hundreds of applications in the catalog, five-year master plans, monthly architecture review boards.

And that makes sense: EA as a discipline was built in that context. TOGAF, ArchiMate, Zachman, all of it was designed for large-scale organizations with proportional complexity.

But there's a blind spot in that view. Because companies of 20, 50, or 200 people also have an IT landscape. They also have applications, data flows, dependencies, and technical decisions to make. And they do architecture, often without calling it that.

We got curious about how these smaller organizations approach the topic. And we found some things that are pretty inspiring, including for large enterprises.

EA Without the Title

In a 50-person company, there's usually no enterprise architect. There's no architecture review board either. Sometimes there isn't even a CIO in the traditional sense.

And yet, someone knows how the IT landscape is wired. It's often the CTO, sometimes a lead developer, sometimes the technical founder who built everything in the first place. That person carries a mental map of the system: which apps are connected to what, where the data lives, which workflow runs through which tool.

What's interesting is that this mental map is often pretty accurate. Not exhaustive, not formalized, but accurate. Because in a small team, the person who knows the system is also the one who uses it, evolves it, and fixes it when it breaks. The gap between the map and the territory is small, because both are held by the same hands.

The problem, of course, is that this map lives in one head. And when the team grows, when that person goes on vacation, changes roles, or leaves the company, the map goes with them.

Pragmatism by Default

What often strikes us about small teams is their very pragmatic relationship with architecture.

They don't start from a framework. They start from a problem. "We don't know which data is in which tool anymore." "We switched CRMs and broke three integrations we'd forgotten about." "The new developer is taking three weeks to understand how things are connected."

The response is rarely a formal mapping initiative. It's more like a sketch on a whiteboard, a Notion document listing tools and their connections, or a Draw.io diagram made on a Sunday evening by a CTO who was tired of explaining the same thing over and over.

It's incomplete. It's informal. And it's often enough for the stage the company is at.

There's a lesson in that for larger organizations: the most useful EA is the one that answers a concrete problem, not the one that fills the boxes of a framework. You can do a lot of useful things with an imperfect map that's pointed at a specific question.

Shared Knowledge, Naturally

In a 20-person team, everyone roughly knows what everyone else does. The salesperson knows which tool support uses. The developer knows which SaaS the marketing team subscribed to. Knowledge of the IT landscape is distributed naturally through proximity.

Architecture meetings don't exist as such, but their equivalents are everywhere: the morning standup, the Slack channel where someone asks "what's the link between Hubspot and our billing tool again?", the new hire onboarding where you walk through the tools.

What happens when the company grows is that this distributed knowledge fragments. At 50 people, the salesperson no longer knows what support uses. At 100 people, there are tools some people don't even know exist. At 200 people, nobody has the full picture.

That's usually when the need for EA makes itself felt, even if nobody phrases it that way. It's not "we need an enterprise architect." It's "we don't know how our IT landscape holds together anymore."

What Larger Organizations Can Take Away

We're not going to idealize small teams. They have their own problems: dependency on a single person, lack of documentation, technical debt quietly accumulating because everyone is too busy shipping.

But there are a few principles worth holding on to.

Start from the problem, not the framework. Small teams don't map for the sake of mapping. They do it because they have a problem to solve: a migration to prepare, an onboarding to simplify, an incident to understand. In large organizations, that logic sometimes gets lost. The framework becomes the goal, not the means.

Keep the map readable by everyone. When a startup CTO draws the IT landscape on a whiteboard, everyone in the room understands. Nobody asks "what does this symbol mean?" There's no three-page legend. Readability is natural because the audience is right there. That's a standard larger organizations could aim for more often: is my architecture map understandable by someone who isn't an architect?

Accept useful imperfection. A small team will never spend six months producing an exhaustive map. They'll produce something incomplete but useful, and improve it as they go. There's wisdom in that: a 70% map that lives and serves a purpose beats a 100% map that sits in a drive gathering dust.

Stay close to the ground. In a small team, the person who maps is also the person who operates. There's no gap between theory and practice. In large organizations, the architect is often removed from day-to-day operations. Finding ways to bring architecture closer to how teams actually work is probably one of the most important challenges in modern EA.

The Tipping Point

There's a moment in a growing company's life when informal practices aren't enough anymore. It's rarely a sharp moment. It's more of an accumulation: an incident that takes three days to diagnose because nobody knew about a dependency, a migration that goes off track because a flow was forgotten, a security audit that reveals tools nobody had a complete list of.

That's when informal EA needs a bit of structure. Not necessarily a heavy discipline with dedicated roles and monthly committees. Just a shift from the mental map to something shared, accessible, and maintainable.

This transition is tricky. A lot of growing companies make the mistake of jumping straight to enterprise-grade tools and processes. They buy a full EA platform, impose a framework, and end up with something too heavy for their size and culture.

The sweet spot is probably keeping the spirit of informal practices (pragmatism, readability, problem-orientation) while adding the minimum structure needed so the knowledge no longer depends on a single person.

This Is Kind of Our Thing at Boldo

This transition, between informal EA and structured EA, is something that really resonates with us. Because we think there's a gap between the whiteboard and the classic enterprise EA tool.

We're trying to build Boldo so it's useful from the very first steps: simple enough to replace the CTO's Notion diagram, structured enough to support growth, open enough for the whole team to contribute.

Simple to start. Begin with a few components and a few connections, like you would on a whiteboard. No training required, no framework imposed.

Structured when it matters. As the IT landscape gets more complex, add layers: business views, dependency analysis, connection to real data sources.

Shared by design. The map is readable and accessible to the whole team, not reserved for the person who created it.

EA doesn't need to be heavy to be useful. Sometimes the best thing you can do is keep the small-team spirit in a tool that grows with you.