콘웨이의 법칙 및 팀 구조

Have you ever noticed how software often looks like the organization that built it? That's the essence of Conway's Law!

Coined by Melvin Conway in 1968, it states that organizations design systems that mirror their own communication structures.

It's a powerful idea for understanding why certain architectures emerge in SaaS companies.

Imagine a company with two separate teams: one for the front-end and one for the back-end. What kind of system will they build?

• A front-end team communicates primarily with the back-end team.
• The resulting software will likely have a strong, distinct boundary between front-end and back-end.
• This often leads to a client-server architecture, reflecting the two teams.

The system's interfaces mirror the communication interfaces between teams.

Conway's Law deeply influences SaaS architectures:

• Monoliths: Often built by large, tightly coupled teams, leading to a single, interconnected codebase.
• Microservices: Tend to emerge from smaller, independent teams, each responsible for a distinct service.
• Modular design: If teams are structured around business domains, their services will naturally reflect those domains.

Understanding this helps us design better organizations for better software.

Communication isn't just about formal meetings. It includes:

• Team structure: Who reports to whom, team boundaries.
• Tools: Chat, project management, code repositories.
• Processes: Code reviews, deployment pipelines.
• Informal channels: Water cooler chats, social interactions.

All these factors influence how information flows and, consequently, how your SaaS system is structured.

Instead of letting organization structure dictate architecture, we can reverse it! This is the Reverse Conway Maneuver.

If you want a microservices architecture, you can proactively organize your teams into small, autonomous units, each owning a specific service or domain.

This strategic approach helps achieve desired architectural outcomes by influencing team interactions.

Building on Conway's Law, the 'Team Topologies' book by Matthew Skelton and Manuel Pais offers a practical approach to structuring teams.

It identifies four fundamental team types and interaction modes to optimize for rapid, safe software delivery.

The goal is to reduce cognitive load and improve flow for stream-aligned teams.

Stream-aligned teams are the core of the Team Topologies model. They are:

• Focused on a single, continuous stream of work.
• Aligned directly with a business domain or user journey.
• Empowered to deliver value end-to-end with minimal dependencies.

They should have low cognitive load, focusing on one thing well.

To support stream-aligned teams, we have:

• Enabling teams: Short-lived teams that help stream-aligned teams adopt new tech or overcome obstacles, then disband.
• Platform teams: Provide internal services, APIs, and tools that other teams can consume. Think of it as 'Software as a Service' for internal developers.

These teams reduce the burden on stream-aligned teams, allowing them to focus on business value.

The final team type is the Complicated Subsystem Team. These teams specialize in areas requiring deep, niche expertise.

• They handle complex algorithms, AI/ML models, or difficult integrations.
• Their goal is to reduce the cognitive load for stream-aligned teams by providing this complexity as a service.
• Interaction with them is typically through well-defined APIs.

They are less common but vital for specialized components.

Today, we explored Conway's Law and its profound impact on software architecture, especially in SaaS.

• We saw how organizational communication structures are reflected in system design.
• We learned about the Reverse Conway Maneuver to intentionally shape architecture.
• Finally, we introduced the four fundamental Team Topologies: Stream-Aligned, Enabling, Platform, and Complicated Subsystem teams, and how they optimize for flow and reduced cognitive load.

Understanding team dynamics is crucial for building scalable and maintainable SaaS products.