This text was generated using AI and might contain mistakes. Found a mistake? Edit at GitHub

How Architecture and Organization Shape Each Other: Understanding Conway’s Law and Team Topologies

Software architecture fundamentally revolves around creating modules — a concept that dates back to the 1970s. The seminal paper by Parnas established a crucial insight: software architecture is ultimately about controlling information flow, which is inherently a social problem. This principle of information hiding — limiting what other modules can access — enables teams to work independently and change implementations without affecting dependent systems or other teams.

However, architecture doesn’t exist in isolation. The relationship between software structure and organizational composition is bidirectional and powerful. Conway’s Law states that system architectures mirror the communication structures of the organizations that build them. This isn’t a belief — it’s a natural law like gravity.

The inverse application, Inverse Conway, suggests deliberately structuring organizations around desired architecture. Assign teams to business domains, and they’ll naturally create corresponding modules. While theoretically elegant, this approach overlooks real-world complexity. Organizations must consider location, time zones, technical skills, and varying workload priorities. A UI team is not aligned to a specific business domain but it might make sense due to technical skills or location.

Team Topologies offers a more nuanced framework. It recognizes that teams serve different purposes: stream-aligned teams handle the implementation of business capabilities end-to-end, enabling teams provide specialized support, platform teams offer infrastructure services, and complicated subsystem teams manage complexity e.g. complex algorithms. The interactions between these teams vary — some communicate through APIs (X as a Service), others through facilitation and collaborating i.e. working very closely together for a limited time period.

Critically, Team Topologies acknowledges informal communication, which often supersedes formal organizational charts. This is often where real problems emerge and get solved.

For architects lacking formal authority, influence comes through communication and soft skills, not authority. Techniques like post-it exercises in meetings, event-storming, and collaborative modeling create parallel, inclusive environments where introverts and domain experts alike contribute. The key is understanding that software development is fundamentally a social and technical activity — treat people problems seriously.

Conclusion

The intersection of architecture and organization reveals that most software problems are actually people problems. Rather than imposing architectural decisions, architects should engage stakeholders, understand goals, measure outcomes, and remain alert to warning signals. Success comes from balancing technical vision with organizational reality, always remembering that effective collaboration precedes effective code.