Mở đầu
Các mô hình ngôn ngữ lớn (LLM) thế hệ mới đang thay đổi nhiều khâu trong vòng đời phát triển phần mềm (SDLC). AI đã có thể đọc tài liệu Basic Design, sinh code boilerplate và viết bản nháp Unit Test trong thời gian ngắn hơn nhiều so với trước.
Điều này đặt ra câu hỏi lớn cho Kỹ sư cầu nối (BrSE). Nếu công việc chính của BrSE chỉ là đứng giữa để dịch spec và review code cơ bản, thì phần lớn công việc đó AI đã làm được.
Hướng đi mà chúng tôi chọn là "Shift-Left": BrSE dịch chuyển lên giai đoạn thượng nguồn (Upstream), tập trung vào Phân tích nghiệp vụ (Business Analysis) và Kiến trúc hệ thống (System Architecture). Đây cũng là định hướng ARIS Vietnam đang xây dựng cho đội ngũ BrSE:
"Tận dụng AI. Con người đưa ra phán đoán và kiến tạo sự đồng thuận."
1. Bốn năng lực cốt lõi của BrSE trong thời đại AI
Thay vì làm "proxy" chuyển tiếp thông tin, BrSE hiện đại đóng vai trò gần với một Solution Architect, với bốn trọng tâm:
Define Business Context: nhìn thấu bản chất yêu cầu Không dịch tài liệu một cách cơ học. BrSE cần mapping được business logic của khách hàng sang technical logic, và làm rõ các yêu cầu phi chức năng (NFRs) như High Availability, Scalability hay Security ngay từ đầu.
System Architecture & Cost Optimization: phác họa giải pháp phù hợp Đánh giá trade-off giữa các lựa chọn công nghệ, ví dụ Monolithic hay Microservices, REST hay gRPC. Ước tính chi phí hạ tầng Cloud (AWS, Azure) để tư vấn ngược lại cho khách hàng thay vì chỉ làm theo spec.
API Contract & Bounded Context: xây dựng sự đồng thuận Chốt API specification, thiết kế luồng dữ liệu (data flow) và xử lý các điểm nghẽn (bottleneck), để đội Dev tại Việt Nam và PO phía Nhật Bản hiểu giống nhau về mặt kỹ thuật.
Ownership & System Resilience: kiến tạo niềm tin Thiết kế để hệ thống vận hành ổn định (giảm thiểu downtime, có khả năng chịu lỗi), và chịu trách nhiệm giải trình kỹ thuật trước CTO/CIO phía đối tác.
2. Ma trận chuyển đổi BrSE
| Khía cạnh | BrSE truyền thống | BrSE hiện đại (AI-Driven) |
|---|---|---|
| Workflow | Dịch spec → chia task → báo cáo tiến độ | Thu thập yêu cầu → thiết kế hệ thống → tech review |
| Công cụ chính | Excel, Word, công cụ dịch | AI assistant, công cụ thiết kế kiến trúc Cloud, UML/Draw.io |
| Xử lý issue | Báo bug, hỏi Dev cách fix rồi dịch lại cho khách | Phân tích root cause (log, trace), đề xuất 2–3 phương án xử lý |
| Tối ưu hóa | Làm đúng spec, ít quan tâm đến tải hệ thống | Tối ưu DB query, chiến lược caching, chi phí Cloud |
| Giá trị mang lại | Giảm rào cản ngôn ngữ | Giảm technical debt, tối ưu ROI cho dự án |
3. Use case thực tế: tư duy kiến trúc trong dự án WMS
Phỏng vấn nhanh anh Võ Ngọc Hoàng Nam, Senior BrSE / Solution Architect tại một dự án WMS (hệ thống quản lý kho) cho thương mại điện tử tại Nhật Bản. Thông tin khách hàng được ẩn theo thỏa thuận bảo mật.
Hỏi: Hệ thống WMS cho thương mại điện tử đòi hỏi xử lý đồng thời (concurrency) rất cao. Tư duy kỹ thuật của BrSE ảnh hưởng thế nào đến dự án?
Nam: Với hệ thống xử lý lượng giao dịch rất lớn, BrSE không thể chỉ cầm spec rồi "chạy bằng cơm". Mình dùng AI để đọc nhanh các tài liệu nghiệp vụ tiếng Nhật, sau đó dành thời gian cho phần kiến trúc. Khách hàng rất rành nghiệp vụ, nhưng rủi ro về tải hệ thống thì không phải lúc nào cũng được nhìn thấy sớm. Nhiệm vụ của mình là tìm ra các điểm Single Point of Failure (SPOF) và xử lý chúng trước khi Dev bắt tay vào code.
Hỏi: Anh có thể chia sẻ một ví dụ cụ thể về việc cùng khách hàng tối ưu kiến trúc không?
Nam: Có một đợt khách hàng gửi spec cho tính năng Flash Sale. Luồng thiết kế ban đầu là: user đặt hàng → gọi API → khóa bản ghi tồn kho trên Master DB → cập nhật tồn kho theo thời gian thực.
Với lượng người dùng truy cập đồng thời rất lớn trong các đợt cao điểm, luồng này có nguy cơ cao gây tranh chấp khóa (lock contention), deadlock và timeout ở database. Mình đề xuất không đi theo luồng đó, và thiết kế lại theo hướng xử lý bất đồng bộ (asynchronous):
- Đưa dữ liệu tồn kho của các sản phẩm Flash Sale lên Redis để xử lý in-memory với độ trễ thấp.
- Khi user đặt hàng, hệ thống trừ tồn kho trên Redis bằng thao tác atomic (ví dụ
DECRhoặc Lua script), nên không bán vượt số lượng (oversell). - Sau đó hệ thống đẩy event vào message queue (RabbitMQ/Kafka). Worker consume event và cập nhật dần vào Master DB, có xử lý idempotent để không ghi trùng.
- Một job đối soát định kỳ so sánh tồn kho giữa Redis và Master DB.
Mình họp với CTO phía Nhật, trình bày bảng ước tính TPS (Transactions Per Second) và chi phí AWS cho từng phương án. Phương án mới chịu được tải Flash Sale, tránh oversell, và không làm chi phí hạ tầng tăng theo mỗi đợt cao điểm. Khách hàng đồng ý chuyển sang phương án này. Đó là lúc kiến thức kỹ thuật giúp bảo vệ cả dự án.
Hỏi: Lời khuyên của anh cho các BrSE trong giai đoạn này?
Nam: Đừng chỉ dùng AI như một công cụ dịch thuật. Hãy để AI hỗ trợ những phần lặp lại như boilerplate code hay bản nháp tài liệu, còn bản thân mình thì nâng cấp lên làm người thiết kế kiến trúc tổng thể. AI không thể chịu trách nhiệm khi Master DB gặp sự cố, cũng không thể thay mình đàm phán với khách hàng. Giá trị của BrSE nằm ở tư duy hệ thống và tinh thần Ownership.
4. Cách ARIS Vietnam áp dụng định hướng này
Định hướng "AI hỗ trợ, con người phán đoán" cũng là nguyên tắc của Hybrid Delivery Model mà ARIS Vietnam công bố: phạm vi sử dụng AI được thống nhất với khách hàng cho từng dự án, và mọi thay đổi vào nhánh chính đều do kỹ sư review và phê duyệt.
Với đội BrSE, điều đó có nghĩa là thời gian tiết kiệm được nhờ AI được dành cho những việc AI không làm thay được: làm rõ yêu cầu, thiết kế kiến trúc, và xây dựng sự đồng thuận giữa đội Việt Nam với khách hàng Nhật Bản. Bạn có thể tìm hiểu thêm về phát triển phần mềm offshore tại Việt Nam cùng đội PM/BrSE của ARIS, hoặc đọc thêm về cách ngăn hiểu lầm trong giao tiếp dự án offshore.
Vượt xa ranh giới dịch thuật. Trở thành đối tác cùng kiến tạo.
BrSE thời nay: code ít đi, thiết kế kiến trúc nhiều hơn, giá trị mang lại cao hơn.
