Conway's Law là gì - và tại sao nó không phải lý thuyết
Năm 1967, Melvin Conway viết một paper với câu nổi tiếng:
"Any organization that designs a system (defined broadly) will produce a design whose structure is a copy of the organization's communication structure."
Dịch ra: Hệ thống mà bạn build sẽ phản chiếu cách các team của bạn communicate với nhau.
Không phải câu chuyện học thuật. Là quy luật thực tế.
Tại sao? Vì khi hai dev thuộc cùng một team, họ communicate daily - họ có thể thiết kế interface phức tạp, shared data model, tightly coupled components. Khi hai dev thuộc hai team khác nhau, họ communicate ít hơn - họ sẽ tự nhiên define API boundary, minimize coupling, tạo ra loose coupling giữa hai phần.
Kết quả: Ranh giới giữa các team = ranh giới giữa các service/module trong code.
Vì sao điều này quan trọng với architect
Đây là insight mà tôi mất nhiều năm mới thực sự hiểu: Nếu bạn muốn thay đổi architecture, đôi khi bạn phải thay đổi org chart trước.
Nghe có vẻ ngược. Nhưng hãy xem ví dụ thực tế:
Ví dụ 1: E-commerce monolith muốn migrate sang microservices
Tình huống: Một công ty e-commerce có 4 team: Frontend, Backend, QA, và DevOps. Monolith của họ được build bởi Backend team.
Họ quyết định: "Chúng ta sẽ tách monolith thành microservices."
Kết quả nếu không đổi org: Backend team sẽ tách monolith ra thành... nhiều services nhỏ hơn do cùng Backend team maintain. Vẫn coupling về shared database, về deployment. Frontend team vẫn gọi Backend team khi cần feature. QA team vẫn test toàn bộ như một khối.
Kết quả sau khi đổi org theo Inverse Conway Maneuver: Tổ chức thành product team - mỗi team own một product area (Order, Catalog, Customer). Mỗi team có full-stack dev, QA, DevOps của riêng mình. Sau đó, migrate architecture theo ranh giới team mới.
Lần này microservices thực sự có ý nghĩa.
Ví dụ 2: API gateway bị bottleneck
Tôi thấy một pattern ở nhiều công ty VN: họ có một team "Platform" hoặc "Infrastructure" riêng, và mọi API đều phải đi qua team đó để được approve và deploy vào API gateway.
Kết quả: API gateway trở thành single point of coupling - cả về technology lẫn về process. Mọi team đều bị blocked bởi Platform team. Release cycle chậm. Mọi người frustrated.
Đây không phải vấn đề kỹ thuật. Đây là Conway's Law đang chạy: communication structure (mọi thứ qua Platform team) dẫn đến system structure (mọi thứ qua API gateway).
Fix: Trao quyền ownership API gateway config cho từng product team. Platform team trở thành platform-as-a-product, cung cấp tooling, không phải bottleneck.
Inverse Conway Maneuver - đảo ngược quy luật để thiết kế tốt hơn
Nếu Conway's Law nói "org chart định hình architecture", thì Inverse Conway Maneuver nói: "Thiết kế org chart để bạn muốn có, và architecture sẽ theo đó."
Concept này được popularized bởi sách Team Topologies của Matthew Skelton và Manuel Pais - một trong những cuốn sách hay nhất tôi đọc về organizational design.
Cách tôi áp dụng:
Bước 1: Vẽ target architecture trước
Bạn muốn hệ thống cuối cùng trông như thế nào? Boundaries giữa các domain là gì? Đây là Domain-Driven Design territory - bạn cần identify bounded contexts.
Bước 2: Thiết kế team structure để match target architecture
Mỗi bounded context lý tưởng nên có một team own nó. Team đó có đầy đủ skills để build, test, deploy, và operate service của mình.
Bước 3: Đặt team ranh giới trước, migrate code theo
Đừng migrate code trước khi org structure rõ ràng. Ngược lại, một khi team structure đúng, migration sẽ tự nhiên hơn rất nhiều.
Kinh nghiệm dự án: Khi Conway's Law là friend, không phải enemy
Sau nhiều năm, tôi học cách leverage Conway's Law thay vì fight against it.
Ví dụ: Trong một dự án lớn cho một retail client, chúng tôi có một legacy system cần refactor. Thay vì plan một big bang migration, tôi suggest:
- Identify team boundaries first - Nhìn vào org chart của client, hiểu team nào own business area nào
- Map team boundaries to domain boundaries - Align domain boundaries với team ownership hiện tại, không phải ngược lại
- Migrate incrementally along team lines - Mỗi sprint, một team chịu trách nhiệm migrate phần code của domain họ own
Kết quả: Migration tự nhiên hơn, ít conflict về ownership hơn, team có motivation cao hơn vì đây là "code của họ".
Đây là Conway's Law làm việc cho bạn, không chống lại.
Những anti-pattern tôi thấy ở Việt Nam
Sau nhiều năm làm tư vấn và làm trong nhiều công ty, tôi thấy một số pattern phổ biến mà Conway's Law đang "ăn hại":
1. Shared database anti-pattern
Nhiều team, nhưng share một database. Team nào cũng có thể write vào bất kỳ bảng nào. Kết quả: schema lock, implicit dependencies, không ai dám thay đổi vì sợ break team khác. Conway's Law: org chart có team boundaries, nhưng data layer không có - dẫn đến coupling ngầm.
2. "Fullstack team" nhưng thực ra không fullstack
Team nói là fullstack, nhưng khi feature cần change database schema, phải báo DBA team riêng. Khi cần deploy, phải báo DevOps team riêng. Khi cần security review, phải báo Security team riêng. Kết quả: release cycle 2-3 tuần dù feature nhỏ. Conway's Law: org chart có silo teams, dẫn đến silo deployment pipeline.
3. Microservices nhưng communication qua shared library
Services "độc lập" nhưng cùng import một shared library chứa domain models. Khi shared library thay đổi, tất cả services phải update cùng lúc. Conway's Law: shared library team tạo ra hidden coupling giữa các service teams.
Triết lý của tôi: Architecture là hệ quả, không phải nguyên nhân
Sau 20 năm, tôi tin vào điều này: Bạn không thể fix architecture mà không fix organization.
Nhiều công ty VN tôi làm việc cùng đều muốn "better architecture" - microservices, clean code, SOLID principles. Nhưng họ không muốn thay đổi cách team được organize, cách communication hoạt động, cách incentive được set up.
Kết quả: Architecture tốt hơn trên bản vẽ, nhưng reality vẫn như cũ sau 6-12 tháng. Vì organization structure kéo code về hình dạng cũ.
Conway's Law không phải curse. Nó là force of nature. Bạn có thể học cách làm việc với nó.
Và bước đầu tiên là hiểu: org chart của bạn hôm nay đang nói lên architecture của bạn ngày mai.
Các bạn đã bao giờ nhìn org chart và nhận ra ngay architecture của codebase chưa? Hay ngược lại - nhìn code và đoán được team structure? Comment cho tôi nghe.
/Son Do - believe in basic
#1percentbetter #solutionarchitecture #conwayslaw #microservices #teamtopology