Mở đầu — vì sao bài này quan trọng
Trong suốt khóa học, bạn đã học cách viết SQL, đọc schema, thiết kế API spec, hiểu kiến trúc hệ thống. Nhưng có một sự thật mà ít ai nói thẳng với một Technical BA: bạn sẽ không bao giờ là người ra quyết định kỹ thuật cuối cùng. Người vẽ ra "bức tranh lớn" của hệ thống là Solution Architect. Người nắm quyền sinh sát với dữ liệu — từ cách đặt index, phân vùng bảng, đến quyết định query nào được phép chạy trên production — là DBA (Database Administrator). Technical BA giỏi đến mấy cũng phải làm việc qua và cùng hai vai trò này.
Đây chính là nơi rất nhiều BA — kể cả những người rất giỏi nghiệp vụ — bị mắc kẹt. Họ rơi vào một trong hai thái cực. Thái cực thứ nhất: quá rụt rè, coi Architect và DBA như "thần thánh", không dám đặt câu hỏi, gật đầu với mọi quyết định kỹ thuật rồi về viết lại spec một cách máy móc. Hệ quả là họ trở thành "người chép chính tả", mất hết giá trị. Thái cực thứ hai: học được vài thuật ngữ kỹ thuật rồi tưởng mình ngang hàng, lao vào tranh cãi về cách triển khai, "dạy" Architect cách thiết kế — và nhanh chóng đánh mất uy tín.
Bài này dạy bạn con đường ở giữa: làm thế nào để hợp tác hiệu quả với Architect và DBA, mang đúng giá trị mà chỉ BA mới mang được — business context và constraints — đồng thời tin tưởng chuyên môn của họ ở đúng chỗ. Khi bạn làm tốt việc này, bạn không chỉ viết spec đúng hơn, bạn trở thành chất keo gắn kết giữa nghiệp vụ và kỹ thuật — đúng vai trò mà một Technical BA tồn tại để làm.
Khái niệm cốt lõi
Solution Architect làm gì, và BA mang gì đến cho họ?
Solution Architect (SA) là người chịu trách nhiệm về thiết kế tổng thể của giải pháp: chọn kiến trúc (monolith hay microservices), chọn công nghệ, định nghĩa cách các thành phần giao tiếp, và quan trọng nhất — đảm bảo giải pháp đáp ứng được các yêu cầu phi chức năng (NFR) như hiệu năng, bảo mật, khả năng mở rộng. Họ tư duy bằng trade-off: không có thiết kế nào "đúng tuyệt đối", chỉ có thiết kế phù hợp nhất với các ràng buộc cho trước.
Và đây chính là điểm mấu chốt: chất lượng thiết kế của Architect phụ thuộc trực tiếp vào chất lượng ràng buộc mà bạn cung cấp. Architect không ngồi trong phòng kinh doanh. Họ không biết rằng "phòng kế toán cần chốt sổ trước 9 giờ sáng mùng 1 hàng tháng", hay "đợt sale 12/12 lưu lượng tăng gấp 8 lần ngày thường", hay "theo quy định của Ngân hàng Nhà nước, dữ liệu giao dịch phải lưu tối thiểu 10 năm". Đó là những thứ BA mang đến. Vai trò của bạn không phải là đề xuất giải pháp kỹ thuật — mà là làm rõ bài toán đến mức Architect có thể thiết kế đúng.
Cụ thể, BA mang đến cho Architect ba nhóm thông tin:
- Business context: tại sao tính năng này tồn tại, ai dùng, dùng để làm gì, giá trị kinh doanh là gì. Điều này giúp Architect biết đâu là phần "đắt giá" cần đầu tư kỹ, đâu là phần có thể làm đơn giản.
- Constraints (ràng buộc): ngân sách, deadline, quy định pháp lý, hệ thống legacy phải tích hợp, kỹ năng của team hiện có, SLA cam kết với khách hàng. Ràng buộc định hình không gian giải pháp.
- Volume & pattern dữ liệu thực tế: bao nhiêu user đồng thời, bao nhiêu giao dịch/giây vào giờ cao điểm, dữ liệu tăng trưởng ra sao. Đây là "nguyên liệu" để Architect tính toán capacity.
"Trust their judgment" — tin tưởng chuyên môn ở đúng chỗ
Ý tưởng cốt lõi thứ hai là ranh giới trách nhiệm. Có một quy tắc đơn giản đáng để khắc cốt ghi tâm:
> BA sở hữu câu hỏi "WHAT" và "WHY". Architect và DBA sở hữu câu hỏi "HOW".
Bạn có toàn quyền — và trách nhiệm — khẳng định cái gì cần đạt được và tại sao. "Hệ thống phải xử lý 5.000 đơn hàng/phút trong giờ cao điểm vì đó là lưu lượng đợt sale Tết năm ngoái." Đó là phát biểu của BA, và nó không thể thương lượng nếu nghiệp vụ yêu cầu vậy. Nhưng làm thế nào để đạt 5.000 đơn/phút — dùng message queue, sharding database, hay caching — đó là sân của Architect. Bạn có thể hỏi để hiểu, có thể chất vấn để làm rõ rủi ro, nhưng bạn không phủ quyết quyết định kỹ thuật của họ.
"Trust their judgment" không có nghĩa là gật đầu mù quáng. Nó có nghĩa là: bạn tin rằng họ giỏi hơn bạn ở phần "HOW", nên thay vì áp đặt giải pháp, bạn cung cấp cho họ thông tin tốt nhất rồi để họ quyết. Nếu bạn không đồng ý, bạn không tranh cãi về giải pháp — bạn quay lại làm rõ ràng buộc. Ví dụ thay vì nói "không nên dùng cache vì sợ dữ liệu cũ", bạn nói "ràng buộc nghiệp vụ là số dư tài khoản phải chính xác tuyệt đối tại thời điểm giao dịch, không được trễ dù chỉ 1 giây". Để Architect tự rút ra rằng phần đó không nên cache.
DBA — người gác cổng của dữ liệu
DBA khác Architect ở chỗ họ tập trung vào tầng dữ liệu và thường có quyền lực vận hành rất cụ thể. Ở nhiều ngân hàng và doanh nghiệp lớn tại Việt Nam, không một câu DDL/DML nào chạy lên production mà không qua DBA review. Họ quan tâm đến: index có hợp lý không, query có gây full table scan không, schema change có khóa bảng (lock) gây downtime không, dữ liệu có được backup không, và liệu thay đổi của bạn có làm sập hiệu năng của 50 ứng dụng khác đang dùng chung database không.
BA cần làm việc với DBA chủ yếu ở ba thời điểm: khi thiết kế schema mới, khi viết spec cho báo cáo/truy vấn nặng, và khi lên kế hoạch data migration. Giá trị bạn mang đến cho DBA là mẫu truy cập dữ liệu (data access pattern): bảng này được đọc nhiều hay ghi nhiều, query lọc theo cột nào, có sắp xếp theo cột nào, dữ liệu cũ có cần giữ không. DBA cần những thông tin này để tư vấn index, phân vùng (partitioning), và chiến lược lưu trữ. Nếu bạn chỉ đưa cho DBA một bảng schema khô khan mà không kèm access pattern, họ sẽ phải đoán — và đoán sai thì cả hệ thống trả giá.
Tình huống thực tế
Tình huống 1: BA mang sai "constraint" cho Architect — Sàn TMĐT giả định "ShopFast"
ShopFast là một sàn thương mại điện tử tại TP.HCM. BA tên Linh nhận yêu cầu: xây tính năng "flash sale" cho các đợt khuyến mãi giờ vàng. Khi viết spec, Linh ghi: "Hệ thống cần xử lý khoảng 500 đơn hàng/phút", lấy con số từ doanh số trung bình ngày thường.
Architect dựa vào con số đó, thiết kế một kiến trúc gọn nhẹ, đặt hàng trực tiếp xuống database, không dùng queue. Đúng đợt flash sale 12/12, lưu lượng thực tế lên tới 6.000 đơn/phút — gấp 12 lần. Database bị nghẽn, hệ thống treo 40 phút, ShopFast ước tính mất hơn 800 triệu đồng doanh thu và vô số khách hàng bực bội.
Diễn giải: Lỗi không nằm ở Architect. Architect thiết kế đúng với ràng buộc được cung cấp. Lỗi nằm ở chỗ Linh đã đưa con số "ngày thường" thay vì con số "giờ cao điểm của sự kiện cao điểm nhất". Đây là một thất bại điển hình của BA: không hiểu rằng với tính năng flash sale, con số quan trọng nhất chính là đỉnh tải (peak load), không phải trung bình.
Bài học: Khi cung cấp constraint về volume, luôn hỏi: "Đỉnh cao nhất trong năm là khi nào, và lúc đó con số là bao nhiêu?" Một câu hỏi với team marketing — "Tết và 12/12 năm ngoái lưu lượng tăng mấy lần?" — đã đủ để cứu cả tính năng. Architect tin tưởng vào con số của bạn; vì vậy con số của bạn phải đúng.
Tình huống 2: DBA chặn một spec báo cáo — Ngân hàng giả định "VietCredit Bank"
Tại một ngân hàng tầm trung, BA tên Đức viết spec cho một báo cáo mới: "Báo cáo tổng hợp giao dịch theo chi nhánh, lọc theo khoảng thời gian, cho phép xem tới 24 tháng dữ liệu." Đức gửi spec, lập trình viên viết query, và khi đưa lên môi trường staging, DBA chặn lại ngay.
DBA giải thích: bảng transactions có gần 2 tỷ dòng. Query của Đức lọc theo branch_id và transaction_date, nhưng index hiện tại chỉ có trên account_id. Chạy báo cáo này sẽ gây full table scan, khóa bảng và làm chậm toàn bộ hệ thống core banking trong giờ làm việc. DBA hỏi Đức một câu mà anh không trả lời được ngay: "Báo cáo này chạy lúc nào, tần suất ra sao, và người dùng thường lọc theo những cột nào nhất?"
Sau khi Đức về làm rõ với phòng nghiệp vụ — báo cáo chạy 1 lần/ngày vào cuối ngày, chủ yếu lọc theo chi nhánh và tháng — DBA đề xuất hai giải pháp: tạo một composite index trên (branch_id, transaction_date), và quan trọng hơn, đẩy báo cáo này sang chạy trên replica database vào ban đêm thay vì database chính trong giờ làm việc.
Diễn giải: Đức không sai khi muốn báo cáo đó. Cái thiếu là access pattern đi kèm spec. Nếu ngay từ đầu spec ghi rõ tần suất, thời điểm chạy và các cột lọc thường dùng, DBA đã có thể tư vấn ngay từ giai đoạn thiết kế thay vì chặn ở phút chót.
Bài học: Với mọi spec liên quan đến truy vấn dữ liệu lớn, hãy đính kèm bốn thông tin cho DBA: tần suất chạy, thời điểm chạy (giờ cao điểm hay ngoài giờ), các cột dùng để lọc/sắp xếp, và lượng dữ liệu dự kiến quét. Đây không phải việc bạn tự thiết kế index — đó là việc bạn cho DBA đủ dữ kiện để họ thiết kế. Tôn trọng vai trò gác cổng của họ; họ đang bảo vệ cả hệ thống.
Tình huống 3: BA "lấn sân" Architect và đánh mất uy tín — Công ty fintech giả định "PayViet"
Tại PayViet, BA tên Hương vừa học xong một khóa về microservices. Trong buổi họp thiết kế tính năng ví điện tử mới, Architect đề xuất giữ phần xử lý thanh toán trong monolith hiện có để đảm bảo tính nhất quán giao dịch (transaction consistency). Hương phản đối gay gắt: "Microservices mới là xu hướng, phải tách service thanh toán riêng chứ!"
Cuộc tranh luận kéo dài 30 phút, không ai nhường ai. Architect cuối cùng phải giải thích rằng việc tách service thanh toán ra sẽ tạo ra distributed transaction phức tạp, đòi hỏi pattern như Saga, làm tăng rủi ro mất nhất quán dữ liệu tiền — điều tối kỵ với fintech. Hương không có đủ chiều sâu kỹ thuật để phản biện, buổi họp mất thời gian vô ích, và từ đó các kỹ sư bắt đầu ngại mời Hương vào các buổi thiết kế.
Diễn giải: Hương đã vi phạm ranh giới WHAT/HOW. "Tách service hay không" là quyết định HOW thuần túy — sân của Architect. Điều Hương nên làm là phát biểu WHAT: "Nghiệp vụ yêu cầu mọi giao dịch chuyển tiền phải đảm bảo không bao giờ trừ tiền mà không cộng tiền, kể cả khi hệ thống lỗi giữa chừng." Đó là ràng buộc vàng. Để Architect tự suy ra rằng giữ trong monolith là an toàn hơn.
Bài học: Học kỹ thuật để hiểu và đối thoại, không phải để áp đặt giải pháp. Khi bạn thấy mình đang tranh cãi về cách triển khai, hãy dừng lại và tự hỏi: "Mình đang bảo vệ một yêu cầu nghiệp vụ, hay đang bảo vệ một giải pháp kỹ thuật mà mình thích?" Nếu là vế sau, hãy lùi lại. Uy tín của BA được xây bằng việc làm rõ bài toán xuất sắc, không phải bằng việc thắng tranh luận kỹ thuật.
Hướng dẫn từng bước
Đây là quy trình thực dụng để hợp tác với Architect và DBA trong một dự án điển hình:
Bước 1 — Chuẩn bị "gói ngữ cảnh" trước mọi buổi thiết kế. Trước khi gặp Architect, hãy chuẩn bị sẵn: mục tiêu kinh doanh của tính năng, các persona người dùng, đỉnh tải dự kiến và thời điểm xảy ra, các quy định pháp lý liên quan, hệ thống legacy phải tích hợp, và SLA cam kết. Đừng đến buổi họp tay không rồi để Architect phải "moi" thông tin từ bạn.
Bước 2 — Phát biểu bằng WHAT và WHY, không phải HOW. Trong buổi họp, mỗi yêu cầu hãy diễn đạt dưới dạng "Hệ thống cần đạt được X, vì lý do nghiệp vụ Y". Tránh các câu bắt đầu bằng "Nên dùng công nghệ Z". Nếu bạn có ý tưởng kỹ thuật, hãy nêu dưới dạng câu hỏi: "Liệu cách tiếp cận kiểu A có khả thi không, và đánh đổi là gì?"
Bước 3 — Lắng nghe trade-off và ghi lại lý do quyết định. Khi Architect chọn một hướng, hãy hỏi "Đánh đổi của lựa chọn này là gì?" và ghi lại. Những lý do này cực kỳ quý khi sau này có người chất vấn thiết kế — và là nguyên liệu cho tài liệu ADR (Architecture Decision Record) mà bạn đã học ở Bài 51.
Bước 4 — Với DBA, luôn đính kèm access pattern. Mỗi khi spec chạm tới database — bảng mới, cột mới, báo cáo, migration — hãy đính kèm bảng access pattern: thao tác (đọc/ghi), tần suất, cột lọc/sắp xếp, lượng dữ liệu, thời điểm chạy. Đưa DBA tham gia sớm, ở giai đoạn thiết kế, đừng để đến lúc deploy mới mời.
Bước 5 — Đóng vai phiên dịch hai chiều. Khi Architect/DBA nói điều gì đó kỹ thuật ảnh hưởng đến nghiệp vụ (ví dụ "báo cáo này chỉ chạy được ban đêm"), nhiệm vụ của bạn là dịch nó về tác động nghiệp vụ và xác nhận với phòng ban liên quan. Ngược lại, dịch yêu cầu nghiệp vụ thành ngôn ngữ ràng buộc mà kỹ thuật hiểu được.
Bước 6 — Chốt và viết lại spec phản ánh đúng quyết định kỹ thuật. Sau buổi họp, cập nhật spec để nó nhất quán với thiết kế đã chốt, và gửi lại cho cả Architect lẫn DBA xác nhận. Vòng lặp xác nhận này tránh hiểu lầm về sau.
Lỗi thường gặp & mẹo
Lỗi 1 — Coi Architect/DBA là "người làm theo yêu cầu". Họ là đối tác thiết kế, không phải thợ thực thi. Nếu bạn ném spec qua tường rồi chờ kết quả, bạn sẽ nhận về một giải pháp lệch nhu cầu. Mẹo: mời họ vào càng sớm càng tốt, ngay từ giai đoạn phân tích.
Lỗi 2 — Cung cấp constraint mơ hồ hoặc sai. "Hệ thống cần nhanh" là vô nghĩa. "95% request phải phản hồi dưới 300ms ở mức 2.000 request/giây" mới dùng được. Constraint sai (như tình huống ShopFast) còn nguy hiểm hơn không có constraint. Mẹo: luôn định lượng, và luôn truy về đỉnh tải.
Lỗi 3 — Lấn sân HOW. Như tình huống PayViet. Mẹo: khi muốn phản đối một giải pháp kỹ thuật, hãy chuyển nó thành một ràng buộc nghiệp vụ. Đừng nói "đừng dùng cache", hãy nói "dữ liệu này cần độ chính xác tuyệt đối tại mọi thời điểm".
Lỗi 4 — Bỏ qua DBA cho đến phút chót. Đưa schema và query cho DBA xem ở giai đoạn UAT là quá muộn. Mẹo: với mọi thay đổi dữ liệu, hỏi DBA "thay đổi này có gây lock không, có cần downtime không, có ảnh hưởng hệ thống khác không" ngay từ đầu.
Lỗi 5 — Gật đầu khi không hiểu. Khi Architect dùng một thuật ngữ bạn không nắm, im lặng gật đầu là tự đào hố cho mình. Mẹo: hỏi thẳng "Cho mình hiểu rõ hơn — quyết định này ảnh hưởng đến nghiệp vụ ở điểm nào?". Câu hỏi này vừa giúp bạn hiểu, vừa thể hiện bạn quan tâm đến tác động nghiệp vụ — đúng vai trò của bạn.
Mẹo vàng: Xây dựng quan hệ tin cậy trước khi cần. Mời Architect/DBA cà phê, hiểu cách họ làm việc, học từ họ. Khi đã có quan hệ tốt, mọi cuộc đàm phán kỹ thuật trở nên dễ dàng hơn nhiều, và họ sẽ chủ động cảnh báo bạn về rủi ro thay vì chỉ chặn ở phút chót.
Bài tập thực hành
Bài 1 — Viết lại constraint. Bạn nhận yêu cầu "Xây dựng tính năng tra cứu điểm thưởng cho khách hàng thành viên, hệ thống cần nhanh và ổn định." Hãy viết lại yêu cầu này thành ít nhất 5 constraint định lượng, cụ thể, mà một Architect có thể dùng để thiết kế. Gợi ý: nghĩ về số user, đỉnh tải, độ trễ chấp nhận được, độ chính xác dữ liệu, và quy định lưu trữ.
Bài 2 — Chuyển HOW thành WHAT. Cho ba phát biểu sau của một BA, hãy chỉ ra cái sai (lấn sân HOW) và viết lại thành phát biểu WHAT/WHY đúng vai trò BA: (a) "Phải dùng Redis để cache danh sách sản phẩm." (b) "Nên tách module thanh toán thành microservice riêng." (c) "Dùng NoSQL cho phần lưu log giao dịch đi."
Bài 3 — Lập bảng access pattern. Bạn đang viết spec cho một báo cáo "Doanh số theo cửa hàng theo ngày" trên một chuỗi bán lẻ có 300 cửa hàng, dữ liệu bán hàng 3 năm. Hãy lập bảng access pattern để gửi cho DBA, gồm tối thiểu: thao tác chính, các cột dùng để lọc và sắp xếp, tần suất chạy, thời điểm chạy, và ước lượng lượng dữ liệu quét. Sau đó tự đặt câu hỏi: dựa vào bảng này, DBA có thể tư vấn index nào?
Tóm tắt
Làm việc với Solution Architect và DBA là kỹ năng phân định ranh giới. Quy tắc cốt lõi đơn giản đến mức bạn nên dán lên màn hình: BA sở hữu WHAT và WHY; Architect và DBA sở hữu HOW.
Với Architect, giá trị của bạn là mang đến business context và constraints thật chính xác — đặc biệt là đỉnh tải và các ràng buộc pháp lý — rồi tin tưởng vào phán đoán kỹ thuật của họ thay vì áp đặt giải pháp. Tình huống ShopFast nhắc bạn rằng constraint sai còn nguy hiểm hơn không có constraint. Tình huống PayViet nhắc bạn rằng lấn sân HOW làm bạn mất uy tín.
Với DBA, hãy nhớ họ là người gác cổng dữ liệu, và thứ họ cần ở bạn là access pattern — tần suất, thời điểm, cột lọc, lượng dữ liệu. Đưa họ vào sớm, đừng để đến phút deploy như tình huống VietCredit. Cuối cùng, vai trò thực sự của Technical BA trong tam giác này không phải là người giỏi kỹ thuật nhất, mà là người phiên dịch hai chiều giúp nghiệp vụ và kỹ thuật hiểu nhau — và đó là giá trị không ai thay thế được bạn.