title: "Kiến trúc sư doanh nghiệp (EA) vs. Kỹ sư giải pháp (SA): Phân định ranh giới và cách phối hợp"
series: "TOGAF Mastery: Kiến trúc sư Doanh nghiệp Chuyên sâu"
part: "Phần 1 — Tầng Triết lý & Chiến lược Kiến trúc (EA Foundations)"
order: 3
audience: "Enterprise Architect (EA) & Solutions Architect hướng EA"
reading_time: "12 phút"
tags: ["TOGAF", "Enterprise Architecture", "Solutions Architecture", "RACI", "Architecture Governance", "Guardrails"]

Kiến trúc sư doanh nghiệp (EA) vs. Kỹ sư giải pháp (SA): Phân định ranh giới và cách phối hợp

Một buổi chiều thứ Sáu, trưởng nhóm dự án gõ cửa phòng kiến trúc: "Anh ơi, dự án của em deadline tuần sau, em đã chốt dùng MongoDB cho module này rồi, anh ký duyệt giúp em cái architecture review nhé, chỉ là formality thôi." Đây là câu mở đầu quen thuộc với bất kỳ ai từng ngồi ghế Enterprise Architect (EA — kiến trúc sư doanh nghiệp). Và đây cũng là khoảnh khắc bộc lộ rõ nhất sự nhầm lẫn phổ biến nhất trong nghề: nhiều tổ chức coi EA là một Solutions Architect (SA — kỹ sư/kiến trúc sư giải pháp) "cấp cao hơn", người đóng dấu duyệt cho quyết định kỹ thuật của SA, thay vì hai vai trò có bản chất, phạm vi và đường thời gian hoàn toàn khác nhau.

Hậu quả của sự nhầm lẫn này không trừu tượng. Khi EA bị kéo vào vai trò "SA cấp cao", tổ chức nhận về hai thứ tệ nhất cùng lúc: dự án chậm vì chờ EA duyệt từng chi tiết kỹ thuật, và kiến trúc doanh nghiệp vẫn rời rạc vì EA không còn thời gian nhìn bức tranh tổng. Ngược lại, khi SA bị buộc "tự lo" luôn phần tương thích roadmap dài hạn, tổ chức có những giải pháp chạy tốt cục bộ nhưng tạo ra silo dữ liệu, trùng lặp năng lực, và nợ kiến trúc (architecture debt) tích lũy âm thầm cho đến khi bùng nổ thành chi phí tích hợp khổng lồ 2-3 năm sau.

Bài này không nói về việc ai "cao" hơn ai — đó là câu hỏi sai. Câu hỏi đúng là: hai vai trò này khác nhau ở đâu, giao nhau ở đâu, và làm sao thiết kế cơ chế phối hợp để cả hai cùng nhanh mà không cùng tạo hỗn loạn.

Bản chất

Khác biệt cốt lõi giữa EA và SA không nằm ở kỹ năng kỹ thuật — một EA giỏi vẫn cần hiểu sâu công nghệ, và một SA giỏi vẫn cần tư duy hệ thống. Khác biệt nằm ở ba trục: phạm vi (scope), đường thời gian (time horizon), và đơn vị chịu trách nhiệm (unit of accountability).

EA nhìn toàn doanh nghiệp (enterprise-wide), xuyên nhiều dự án, với tầm nhìn 3-5 năm. Đơn vị phân tích của EA không phải "hệ thống A cần gì" mà là "danh mục ứng dụng (Application Portfolio) của cả tổ chức đang chồng chéo ở đâu, năng lực nghiệp vụ (Business Capability) nào chưa được số hóa, và nền tảng công nghệ nào sẽ hết vòng đời trong 3 năm tới". EA làm việc với Architecture Vision, Target Architecture (kiến trúc mục tiêu) của toàn doanh nghiệp, và Roadmap chuyển đổi trải dài nhiều năm, nhiều chương trình (program), nhiều đơn vị kinh doanh.

SA nhìn một giải pháp/dự án cụ thể, với tầm nhìn thực thi ngay — thường là 3-12 tháng. Đơn vị phân tích của SA là "hệ thống này, dự án này, cần kiến trúc kỹ thuật nào để đáp ứng yêu cầu chức năng và phi chức năng (NFR) trong ngân sách, thời gian đã duyệt". SA chịu trách nhiệm về Solution Building Block cụ thể: chọn database nào, pattern tích hợp nào, framework nào, deploy trên hạ tầng nào — miễn là giải pháp chạy đúng, đủ nhanh, đủ an toàn, đúng hạn.

Điểm mấu chốt: cả hai đều đúng trong phạm vi của mình, và chính vì thế xung đột là tất yếu chứ không phải bất thường. SA tối ưu cho tốc độ và sự phù hợp cục bộ (local fitness) của dự án mình phụ trách — đó là KPI của họ. EA tối ưu cho sự phù hợp toàn cục (global fitness) của cả hệ sinh thái công nghệ — đó là KPI của EA. Một tổ chức trưởng thành không cố xóa bỏ xung đột này, mà thiết kế cơ chế để xung đột được xử lý nhanh, minh bạch, và không đổ trách nhiệm cá nhân.

Xung đột kinh điển nhất: SA muốn giải pháp nhanh nhất, quen thuộc nhất, rẻ nhất cho dự án đang cháy deadline. EA phải đảm bảo giải pháp đó — dù tối ưu cục bộ — không tạo ra một silo dữ liệu mới, không nhân bản một năng lực đã tồn tại ở nơi khác, không đưa vào một công nghệ nằm ngoài Technology Reference Model đã thống nhất, và không khóa tổ chức vào một vendor xung khắc với chiến lược trung hạn. Nói cách khác: SA tối ưu cho "xong việc", EA tối ưu cho "xong việc mà không phải trả giá về sau trên quy mô toàn doanh nghiệp".

Khung & Kỹ thuật áp dụng

Cách xử lý xung đột EA–SA hiệu quả nhất không phải bằng quyền lực cá nhân ("tôi là EA nên tôi có quyền veto"), mà bằng hai công cụ: ma trận RACI theo giai đoạn dự án, và nguyên tắc guardrail (lan can) thay vì micromanage.

1. Nguyên tắc Guardrail thay vì Micromanage

EA không duyệt từng dòng code, từng lựa chọn thư viện, từng chi tiết cấu hình — đó là việc của SA và đội kỹ thuật. Việc của EA là đặt ra guardrails: một tập hợp ràng buộc, tiêu chuẩn, và nguyên tắc đã được thống nhất trước (thường nằm trong Architecture Principles, Technology Reference Model, và Architecture Compliance criteria), để SA tự do ra quyết định kỹ thuật bên trong các ranh giới đó mà không cần xin phép từng bước.

Ví dụ guardrail cụ thể:

• "Mọi hệ thống lưu dữ liệu khách hàng phải đăng ký vào Master Data Management (MDM) trung tâm, không được tạo nguồn sự thật (source of truth) song song."
• "Danh sách database engine được duyệt sẵn: PostgreSQL, MySQL, Redis, DynamoDB. Muốn dùng engine ngoài danh sách phải qua Architecture Exception Request."
• "Mọi tích hợp liên hệ thống phải qua API Gateway hoặc message broker đã chuẩn hóa, không point-to-point trực tiếp."

Với guardrail rõ ràng, 90% quyết định của SA không cần EA can thiệp — SA tự quyết trong khung, tự chịu trách nhiệm thực thi. EA chỉ can thiệp ở 10% còn lại: khi quyết định của SA chạm ranh giới guardrail, hoặc khi guardrail chưa tồn tại cho tình huống mới.

2. Ma trận RACI EA–SA theo giai đoạn dự án

Cách đọc bảng: ở giai đoạn thiết kế chi tiết và vận hành, SA gần như toàn quyền (A/R) — đây chính là thực thi nguyên tắc guardrail. EA chỉ giữ vai trò Accountable ở những điểm chạm trực tiếp đến tính toàn vẹn kiến trúc doanh nghiệp: compliance review, tích hợp liên hệ thống, đăng ký repository, và tác động roadmap dài hạn. Bảng RACI này nên được thống nhất và công khai trước khi dự án bắt đầu, không phải khi xung đột đã xảy ra — nếu SA biết rõ điểm nào cần Consult EA từ đầu, tốc độ dự án không hề bị ảnh hưởng.

3. Cơ chế Escalation nhanh (Fast-track Exception)

Không phải mọi ngoại lệ đều cần một buổi Architecture Review Board (ARB) đầy đủ. Tổ chức trưởng thành có một kênh Fast-track Exception: SA gửi yêu cầu ngoại lệ ngắn gọn (1 trang, nêu rõ lý do, rủi ro, thời hạn tạm thời nếu có), EA phản hồi trong 24-48 giờ thay vì chờ lịch họp ARB hàng tuần/hàng tháng. Đây là cơ chế sống còn để EA không trở thành nút thắt cổ chai (bottleneck) trong mắt các đội dự án.

Case thực tế minh hoạ

(Đây là tình huống minh hoạ điển hình tổng hợp từ các mẫu hình thường gặp trong doanh nghiệp, không phải case của một công ty cụ thể nào, không có số liệu thật.)

Một công ty dịch vụ tài chính đang chạy dự án ra mắt tính năng "chấm điểm tín dụng nhanh" cho khách hàng cá nhân, deadline gấp do áp lực cạnh tranh. SA phụ trách dự án, dưới áp lực thời gian, chọn triển khai một cơ sở dữ liệu NoQuery chuyên biệt (một dòng NewSQL mới nổi) chạy hoàn toàn độc lập, vì đội ngũ đã có kinh nghiệm sẵn với công cụ này từ dự án cá nhân trước đó, và nhà cung cấp hứa hẹn thời gian triển khai nhanh nhất trong các phương án được khảo sát.

Về mặt cục bộ, quyết định của SA hoàn toàn hợp lý: đáp ứng đúng yêu cầu phi chức năng về độ trễ, đúng ngân sách, đúng deadline. Nhưng khi hồ sơ được đưa vào Architecture Compliance Review, EA phát hiện ba vấn đề tầm doanh nghiệp mà SA không có đủ tầm nhìn để thấy: (1) công nghệ NewSQL này không nằm trong Technology Reference Model đã duyệt, nghĩa là đội hạ tầng chưa có quy trình vận hành, sao lưu, giám sát chuẩn cho nó; (2) dữ liệu chấm điểm tín dụng cần đồng bộ với hệ thống quản lý rủi ro trung tâm đang trong roadmap hợp nhất Data Architecture của năm sau — nếu tạo thêm một nguồn dữ liệu độc lập bây giờ, sang năm sẽ phải xây thêm một luồng ETL/đồng bộ riêng, tốn công gấp đôi; (3) nhà cung cấp NewSQL này chưa qua đánh giá bảo mật và pháp lý theo chuẩn ngành tài chính, tạo rủi ro tuân thủ (compliance risk) khi kiểm toán.

Điểm quan trọng là cách EA can thiệp: không phủ quyết và bắt làm lại từ đầu (sẽ làm chậm dự án, phá vỡ niềm tin của đội dự án vào EA), mà đưa ra một phương án guardrail-compliant tương đương: dùng chính hệ quản trị cơ sở dữ liệu đã nằm trong danh mục duyệt sẵn (một dòng cơ sở dữ liệu NoSQL managed-service đã được đội hạ tầng vận hành cho các dự án khác), kèm theo cam kết hỗ trợ đội dự án tăng tốc thiết lập hạ tầng trong 3 ngày để không lệch deadline. Đổi lại, EA cấp một "kiến trúc tạm thời có điều kiện" (conditional interim architecture) — cho phép dự án đi tiếp ngay, nhưng ghi nhận rõ trong Architecture Repository rằng luồng đồng bộ với hệ thống quản lý rủi ro trung tâm là một khoản nợ kiến trúc (architecture debt) đã biết, có chủ sở hữu, có deadline xử lý gắn vào roadmap năm sau.

Kết quả: dự án vẫn về đích đúng hạn, nhưng doanh nghiệp không phải trả giá gấp đôi cho việc tích hợp dữ liệu một năm sau, và rủi ro tuân thủ được xử lý trước khi kiểm toán phát hiện.

📐 Template/Artifact áp dụng ngay

Bảng phân định trách nhiệm EA–SA kèm điểm chạm bắt buộc (Engagement Checkpoint Catalog) — dùng làm phụ lục đính kèm Project Charter cho mọi dự án có cấu phần công nghệ mới:

Cách dùng: đính kèm bảng này vào charter dự án ngay từ đầu, để SA biết trước checkpoint nào cần chủ động liên hệ EA thay vì đợi bị chặn ở review cuối. Với mỗi checkpoint vượt ngưỡng escalation, SA điền một "Architecture Exception Request" 1 trang (bối cảnh, lựa chọn đã cân nhắc, rủi ro, đề xuất) gửi qua kênh fast-track thay vì chờ lịch ARB định kỳ.

🎯 Góc nhìn Chief EA
Đội dự án có biết trước — từ ngày kickoff — checkpoint nào bắt buộc phải Consult kiến trúc doanh nghiệp, hay họ chỉ biết khi bị chặn ở review cuối cùng?
Guardrails của tôi có đang đủ rõ ràng để SA tự tin ra quyết định trong 90% trường hợp mà không cần hỏi, hay tôi đang vô tình biến mình thành nút thắt cổ chai cho mọi lựa chọn kỹ thuật?
Khi tôi từ chối một giải pháp của SA, tôi có luôn đi kèm một phương án thay thế khả thi trong cùng ràng buộc thời gian, hay chỉ nói "không được" rồi để họ tự xoay?
Nợ kiến trúc phát sinh từ các "ngoại lệ tạm thời" tôi đã duyệt có đang được theo dõi với chủ sở hữu và deadline rõ ràng, hay đang âm thầm tích lũy không ai chịu trách nhiệm?

🔗 Bài viết liên quan

• Giá trị của TOGAF
• Kỹ năng lãnh đạo của một Chief EA

Bài trước: Giá trị của TOGAF · Bài tiếp theo: Kỹ năng lãnh đạo của một Chief EA