title: "Visualizing Complex Systems (Cho EA): Cách diễn giải hệ thống phức tạp qua sơ đồ đơn giản"
series: "Thư viện Kỹ năng BA·PO·EA: 45 Bài học Thực chiến"
part: "Phần 2 — Kỹ năng Thực chiến"
skill_number: 26
audience: "BA, PO, EA & vai trò làm việc trực tiếp với khách hàng"
reading_time: "10 phút"
tags:

Enterprise Architecture
C4 Model
Visual Thinking
Trình bày kiến trúc
Stakeholder Communication

Visualizing Complex Systems (Cho EA): Cách diễn giải hệ thống phức tạp qua sơ đồ đơn giản

Bạn có bao giờ đứng trước một hội đồng điều hành, tay cầm sơ đồ kiến trúc chi chít hộp và mũi tên, rồi nhận ra sau 5 phút không ai còn nhìn màn hình nữa chưa? Với Enterprise Architect (EA — kiến trúc sư doanh nghiệp), đây không phải là câu hỏi tu từ. Khi hệ thống càng phức tạp, khả năng "zoom" đúng lớp cho đúng người nghe càng quyết định việc khách hàng có dám ký ngân sách hay không.

🎯 Kỹ thuật cốt lõi: Mô hình phân tầng C4 (C4 Model)

C4 Model là cách trình bày kiến trúc phần mềm theo 4 lớp zoom, mỗi lớp phục vụ một đối tượng nghe khác nhau — giống như bản đồ Google Maps: bạn không đưa người xem bản đồ chi tiết từng con hẻm khi họ chỉ cần biết đường đi từ Hà Nội vào Sài Gòn.

Bốn lớp, từ xa đến gần:

Context (Bối cảnh hệ thống) — Một bức tranh tổng thể: hệ thống của bạn là MỘT hộp duy nhất, xung quanh là các nhóm người dùng (actor) và các hệ thống bên ngoài nó kết nối tới (ngân hàng, cổng thanh toán, hệ thống kế toán...). Không có công nghệ, không có tên bảng dữ liệu. Đây là lớp dành cho ban điều hành, khách hàng không có nền tảng kỹ thuật — họ cần hiểu "hệ thống này làm gì, phục vụ ai, kết nối với cái gì", không cần hiểu "nó chạy bằng gì".
Container (Khối vận hành) — Bóc hộp lớn ở lớp 1 ra thành các khối lớn: ứng dụng web, ứng dụng mobile, API backend, cơ sở dữ liệu, hàng đợi tin nhắn... Mỗi khối là một thứ có thể triển khai (deploy) độc lập. Lớp này dành cho quản lý dự án, trưởng nhóm kỹ thuật của khách hàng — người cần hiểu hệ thống gồm những mảnh nào, mảnh nào rủi ro, mảnh nào tốn tiền vận hành.
Component (Thành phần) — Bóc tiếp một container ra thành các thành phần logic bên trong nó (module xác thực, module xử lý đơn hàng, module gửi thông báo...). Lớp này dành cho kiến trúc sư, tech lead phía khách hàng — người cần đánh giá tính mở rộng, khả năng bảo trì.
Code — Lớp chi tiết nhất: class, function, sequence diagram. Chỉ dành cho lập trình viên trực tiếp code, gần như không bao giờ đưa ra ngoài đội kỹ thuật.

Nguyên tắc vàng khi dùng C4: chọn lớp theo người nghe, không phải theo thứ mình đang có sẵn. Sai lầm phổ biến nhất của EA là mang nguyên sơ đồ Component hoặc Code đi trình bày cho ban điều hành — vì đó là thứ mình vẽ ra khi thiết kế, tiện tay dùng lại. Kỹ thuật đúng là luôn hỏi trước "người ngồi trước mặt mình ra quyết định gì, và họ cần thấy lớp nào để ra quyết định đó" — rồi mới chọn hoặc vẽ lại sơ đồ tương ứng.

Bối cảnh (Situation)

Tình huống dưới đây là minh hoạ tổng hợp từ các dự án tư vấn CNTT tại Việt Nam, không phải case cụ thể của một công ty có thật.

Anh T. là Enterprise Architect của một công ty tư vấn công nghệ, được thuê để thiết kế lại kiến trúc hệ thống quản lý chuỗi cung ứng cho một doanh nghiệp phân phối bán lẻ đang mở rộng ra nhiều tỉnh thành. Hệ thống hiện tại là một khối monolith (ứng dụng đơn khối) 8 năm tuổi, chạy trên một server vật lý, không tách được module nào ra để scale riêng. Mỗi lần cao điểm khuyến mãi, hệ thống sập ít nhất một lần.

Đội của anh T. đề xuất kiến trúc microservices mới: tách thành 12 service độc lập, thêm message queue, thêm cache layer, tách riêng service tồn kho khỏi service đơn hàng. Về mặt kỹ thuật, đây là phương án đúng. Vấn đề là khoản đầu tư không nhỏ — ước tính bằng khoảng 40% ngân sách CNTT cả năm của công ty khách hàng.

Để duyệt khoản đầu tư này, hội đồng điều hành (Ban Giám đốc) phải họp và quyết định — và trong phòng họp đó có Tổng Giám đốc, Giám đốc Tài chính, Giám đốc Vận hành. Không ai trong số họ có nền tảng kỹ thuật. Người duy nhất hiểu sâu về hệ thống hiện tại — Giám đốc CNTT — lại đang nghỉ phép dài hạn vì lý do sức khỏe.

Thách thức (Task)

Anh T. có 45 phút trong buổi họp hội đồng để thuyết phục họ duyệt ngân sách. Thách thức nằm ở ba lớp:

Thứ nhất, khoảng cách ngôn ngữ. Bản vẽ kiến trúc gốc của đội kỹ thuật có hơn 30 hộp: API Gateway, Kafka broker, Redis cluster, service mesh, các container Kubernetes... Đưa nguyên bản vẽ này ra, phản ứng gần như chắc chắn là im lặng lịch sự hoặc câu hỏi lạc đề kiểu "cái Kafka này có phải phần mềm nước ngoài không, mua ở đâu".

Thứ hai, rủi ro "mất niềm tin vì làm phức tạp hoá vấn đề đơn giản". Với ban điều hành, câu hỏi thật sự không phải "kiến trúc kỹ thuật ra sao" mà là "tại sao hệ thống hay sập, bỏ tiền ra thì hết sập không, và nếu không làm thì hậu quả gì". Nếu anh T. trình bày sai lớp — quá sâu về kỹ thuật — ban điều hành sẽ không đánh giá được rủi ro kinh doanh, dễ dẫn đến quyết định trì hoãn "để nghiên cứu thêm", trong khi mùa cao điểm bán hàng cuối năm đang đến gần.

Thứ ba, nếu xử lý sai sẽ có hậu quả kép. Nếu ban điều hành không duyệt, hệ thống tiếp tục sập vào đúng mùa cao điểm — thiệt hại doanh thu trực tiếp. Nhưng nếu anh T. "đơn giản hoá quá tay" để dễ thuyết phục, ẩn đi rủi ro và chi phí vận hành thật sự của kiến trúc mới, hội đồng sẽ duyệt dựa trên thông tin không đầy đủ — và khi phát sinh chi phí ngoài dự kiến ở giai đoạn triển khai, uy tín của anh T. và cả công ty tư vấn sẽ bị tổn hại nghiêm trọng hơn nhiều so với việc bị từ chối ngay từ đầu.

Hành động (Action)

Anh T. áp dụng mô hình C4 theo trình tự ngược — không mang cả 4 lớp vào phòng họp, mà thiết kế lại toàn bộ buổi trình bày xoay quanh đúng một lớp Context, và chuẩn bị các lớp sâu hơn chỉ để dự phòng nếu có câu hỏi đòi hỏi.

Bước 1 — Xác định người ra quyết định cần thấy gì. Trước buổi họp một tuần, anh T. hỏi thẳng người mời họp (Giám đốc Vận hành, người bảo trợ dự án): "Ba anh chị trong hội đồng, khi rời phòng họp, cần trả lời được câu hỏi gì để ký duyệt?". Câu trả lời: (1) hệ thống hiện tại rủi ro tới mức nào, (2) phương án mới giải quyết rủi ro đó ra sao, (3) tiền bỏ ra tương ứng với lợi ích gì mà đo được. Đây chính là bộ ba quyết định — không phải bộ ba kỹ thuật.

Bước 2 — Vẽ lại sơ đồ Context, bỏ hết thuật ngữ kỹ thuật. Anh T. dựng lại sơ đồ Context chỉ với 5 hộp: "Hệ thống Quản lý Chuỗi cung ứng" ở giữa, xung quanh là "Nhân viên kho", "Nhân viên bán hàng tại cửa hàng", "Khách hàng đặt online", "Đối tác vận chuyển", "Hệ thống kế toán". Mỗi mũi tên ghi một câu hành động bằng tiếng Việt thường ngày: "kiểm tra tồn kho", "xác nhận đơn hàng" — không có tên bảng, không có giao thức kỹ thuật.

Bước 3 — Dùng đúng MỘT ẩn dụ xuyên suốt để giữ mạch câu chuyện. Anh T. chọn ẩn dụ "một con đường cao tốc một làn xe" cho hệ thống cũ và "nhiều làn xe có thể mở rộng độc lập" cho hệ thống mới. Mỗi khi cần giải thích vì sao tách service tồn kho ra khỏi service đơn hàng, anh quay lại ẩn dụ: "hiện tại xe chở khách và xe chở hàng đi chung một làn, một xe hàng bị kẹt là cả đoàn khách cũng kẹt theo — mùa cao điểm chính là lúc kẹt nhiều xe nhất cùng lúc."

Bước 4 — Gắn mỗi "hộp" trong sơ đồ Context với một con số kinh doanh. Thay vì nói "tách microservices giúp tăng khả năng chịu tải", anh T. gắn trực tiếp vào sơ đồ Context: cạnh mũi tên "khách hàng đặt online", ghi chú "Black Friday năm ngoái: sập 47 phút, ước tính mất khoảng X đơn hàng". Cạnh hộp trung tâm, ghi chú "chi phí đầu tư ~ 40% ngân sách CNTT năm, hoàn vốn ước tính trong Y tháng nếu giảm được số lần sập". Con số biến sơ đồ kỹ thuật thành một bảng cân đối rủi ro — đầu tư.

Bước 5 — Chuẩn bị lớp Container như "phòng sau" chứ không trình chiếu mặc định. Anh T. vẫn mang theo sơ đồ Container (12 service, message queue, cache) nhưng để trong phần phụ lục, chỉ mở ra nếu có câu hỏi kiểu "vậy cụ thể tiền đi vào đâu". Khi Giám đốc Tài chính hỏi đúng câu đó, anh T. mới lật sang lớp Container, và giải thích y như đang chỉ vào bản vẽ mặt bằng nhà xưởng: "đây là 3 khu vực chính chúng ta đầu tư, mỗi khu vực tương ứng với một hạng mục chi phí trong bảng dự toán". Anh không bao giờ chủ động đưa lớp Component hay Code vào phòng họp đó.

Bước 6 — Kết thúc bằng một câu hỏi quyết định, không phải một sơ đồ. Thay vì để hội đồng tự suy luận, anh T. chốt lại: "Câu hỏi hôm nay không phải là kiến trúc nào tốt hơn về mặt kỹ thuật, mà là công ty có chấp nhận rủi ro sập hệ thống mùa cao điểm năm nay để tiết kiệm khoản đầu tư này hay không." Câu này buộc buổi họp quay về đúng bản chất — một quyết định đầu tư, không phải một buổi học kỹ thuật.

Kết quả (Result)

Hội đồng duyệt ngân sách ngay trong buổi họp đó, với một điều kiện bổ sung: chia làm 2 giai đoạn triển khai để giảm rủi ro dòng tiền — giai đoạn 1 ưu tiên tách service tồn kho và đơn hàng (nguồn gốc chính gây sập), giai đoạn 2 mới làm các phần còn lại. Đây là một điều chỉnh hợp lý mà bản thân anh T. cũng đồng tình, dù ban đầu đội kỹ thuật muốn làm trọn gói một lần.

Điểm chưa hoàn hảo: trong buổi họp, khi Giám đốc Tài chính hỏi sâu về chi phí vận hành Kafka và Redis hàng tháng (chi phí hạ tầng cloud phát sinh liên tục, không phải chi phí đầu tư một lần), anh T. chưa chuẩn bị sẵn con số ở lớp Container cho phần vận hành — chỉ có số liệu đầu tư ban đầu. Anh phải hẹn gửi bổ sung trong 2 ngày. Đây là bài học anh T. rút ra: sơ đồ Context giải quyết được câu hỏi "có nên đầu tư", nhưng câu hỏi "chi phí vận hành dài hạn" đòi hỏi một lớp thông tin tài chính gắn với Container mà lẽ ra phải chuẩn bị sẵn từ đầu, không đợi được hỏi mới làm.

📋 Áp dụng ngay

Trước khi vẽo bất kỳ sơ đồ nào, viết ra một câu: "Người nghe cần ra quyết định gì sau khi xem sơ đồ này" — câu trả lời quyết định bạn dùng lớp Context, Container, Component hay Code.
Với đối tượng không có nền tảng kỹ thuật, giới hạn sơ đồ Context ở 5-7 hộp, không quá — quá số đó là dấu hiệu bạn đang lẫn sang lớp Container.
Gắn mỗi hộp/mũi tên trong sơ đồ với một con số hoặc hậu quả kinh doanh cụ thể (chi phí, thời gian sập, số đơn hàng) — sơ đồ không có con số chỉ là hình minh hoạ, không phải công cụ ra quyết định.
Luôn chuẩn bị lớp sâu hơn (Container) như tài liệu phụ lục dự phòng cho câu hỏi "đi sâu", nhưng không chủ động trình chiếu mặc định.
Chọn một ẩn dụ đời thường duy nhất và dùng xuyên suốt buổi trình bày — đừng đổi ẩn dụ giữa chừng, người nghe sẽ mất mạch.

💡 Bài học đúc rút (Key Takeaway)

Sơ đồ kiến trúc không phải để chứng minh bạn hiểu hệ thống sâu đến đâu — nó phải làm cho người không hiểu kỹ thuật cũng ra quyết định đúng. Chọn sai lớp zoom, dù nội dung kỹ thuật có đúng tuyệt đối, vẫn là một bản trình bày thất bại.

🔗 Kỹ năng liên quan

Bài trước: Kỹ năng đàm phán hợp đồng/phát sinh · Bài tiếp theo: Cách tổ chức các buổi Review/Demo