title: "Giai đoạn D (Technology): Thiết kế Technology Reference Model (TRM)"
series: "TOGAF Mastery: Kiến trúc sư Doanh nghiệp Chuyên sâu"
part: "Phần 2 — Giải phẫu ADM (Mastering the ADM Cycle)"
order: 17
audience: "Enterprise Architect (EA) & Solutions Architect hướng EA"
reading_time: "12 phút"
tags:

• togaf
• adm
• technology-architecture
• trm
• technology-reference-model
• enterprise-architecture

Giai đoạn D (Technology): Thiết kế Technology Reference Model (TRM)

Một CTO từng kể với tôi về buổi review ngân sách hạ tầng hàng năm: 47 dự án đang chạy, và khi liệt kê ra công nghệ dùng cho riêng chức năng "gửi thông báo" (notification), team phát hiện có 6 giải pháp khác nhau — hai hàng đợi message queue, ba thư viện push notification, một dịch vụ email tự viết song song với một dịch vụ email thuê ngoài. Không ai chủ ý làm vậy. Mỗi đội chỉ đơn giản là chọn thứ họ quen, thứ có sẵn tutorial, thứ deploy nhanh nhất cho deadline của mình.

Đây là hệ quả tất yếu của việc thiếu một tầng kiến trúc mà nhiều tổ chức bỏ qua hoặc làm hời hợt: Giai đoạn D — Technology Architecture — trong chu trình ADM (Architecture Development Method, phương pháp phát triển kiến trúc lõi của TOGAF). Nhiều người nhầm giai đoạn này với việc "chọn stack công nghệ" thuần túy kỹ thuật, giao hẳn cho platform team làm mà không cần EA can thiệp. Sai lầm ở đây không phải là thiếu năng lực kỹ thuật — các kỹ sư platform hoàn toàn đủ giỏi để chọn Kafka hay RabbitMQ. Vấn đề là thiếu một cơ chế ra quyết định có tính hệ thống, xuyên suốt toàn tổ chức, để những lựa chọn cục bộ không tích lũy thành phân mảnh (fragmentation) ở quy mô doanh nghiệp.

Giai đoạn D không phải là danh sách công nghệ khô cứng áp đặt từ trên xuống. Nó là bản đồ tham chiếu (reference model) xác định các tầng công nghệ chuẩn hóa mà mọi ứng dụng, mọi dự án phải map vào — vừa đủ chặt để tránh hỗn loạn, vừa đủ mở để không bóp nghẹt đổi mới.

Bản chất

Trong ADM, Giai đoạn D — Technology Architecture — là bước phát triển kiến trúc công nghệ mục tiêu (Target Technology Architecture) hỗ trợ cho Business Architecture (Giai đoạn B) và Information Systems Architecture (Data + Application, Giai đoạn C) đã được xác định trước đó. Nó trả lời câu hỏi: "Nền tảng compute, network, platform, và công cụ (tooling) nào sẽ chạy các ứng dụng và luồng dữ liệu mà tổ chức cần?"

Artifact trung tâm của giai đoạn này là Technology Reference Model (TRM) — một mô hình phân tầng chuẩn hóa các dịch vụ và nền tảng công nghệ, độc lập với sản phẩm/vendor cụ thể ở tầng khái niệm, nhưng đi kèm danh mục sản phẩm được phê duyệt (approved technology catalog) ở tầng thực thi. TRM khác với một "danh sách công nghệ được duyệt" đơn thuần ở chỗ: nó tổ chức công nghệ theo chức năng kiến trúc (application platform, integration, security, network, management), không theo tên vendor. Nhờ vậy khi công nghệ cụ thể thay đổi (ví dụ chuyển từ Kafka sang Pulsar), cấu trúc TRM không cần viết lại — chỉ cần cập nhật danh mục sản phẩm ở tầng dưới.

Điểm dễ hiểu lầm nhất: TRM không được thiết kế để "khóa cứng" công nghệ. Bản chất của nó là quản trị mức độ đa dạng (managed diversity) — chấp nhận rằng các bối cảnh khác nhau (real-time analytics vs. batch reporting, ví dụ) có thể cần công nghệ khác nhau, nhưng số lượng lựa chọn đó phải nằm trong một danh mục đã được thẩm định, có lý do rõ ràng, và có chủ sở hữu (owner) chịu trách nhiệm vòng đời.

Một điểm nữa cần làm rõ: TRM của TOGAF là một mô hình khái niệm tham chiếu (do TOGAF cung cấp sẵn một TRM chuẩn dưới dạng foundation architecture, thuộc Architecture Continuum), không phải là kiến trúc cụ thể của một tổ chức. Công việc của EA trong Giai đoạn D là tailor — điều chỉnh — mô hình tham chiếu chuẩn đó cho phù hợp ngành nghề, quy mô, và mức độ trưởng thành công nghệ của tổ chức mình, chứ không phải chép nguyên bản.

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

Cấu trúc phân tầng của một TRM thực dụng

TRM chuẩn của TOGAF khá trừu tượng (Foundation Architecture với các building block như Business Application, Application Platform, Communications Infrastructure...). Trong thực hành ở doanh nghiệp vừa và công nghệ, tôi thường cụ thể hóa thành 6 tầng dễ áp dụng hơn:

Mỗi tầng cần ba cột thông tin đi kèm khi cụ thể hóa thành artifact: (1) Standard — công nghệ mặc định nên dùng, (2) Approved alternatives — công nghệ được chấp nhận trong tình huống đặc thù có lý do, (3) Retire/Discouraged — công nghệ đang trong lộ trình loại bỏ, không được dùng cho dự án mới.

Nguyên tắc cân bằng: đủ chặt nhưng không kìm hãm

Đây là phần khó nhất của Giai đoạn D, và cũng là nơi phân biệt một EA giỏi với một người chỉ biết áp đặt chuẩn. Ba nguyên tắc tôi dùng để giữ cân bằng:

1. Chuẩn hóa theo tầng có rủi ro tập trung cao, linh hoạt ở tầng có rủi ro thấp. Ví dụ: IAM và secrets management gần như phải là một chuẩn duy nhất toàn tổ chức (rủi ro bảo mật nếu phân mảnh là nghiêm trọng), trong khi lựa chọn thư viện xử lý ảnh trong một service cụ thể có thể để linh hoạt cho team.

2. Cơ chế ngoại lệ có kiểm soát (Architecture Exception Process), không phải cấm tuyệt đối. TRM tốt luôn có đường để một team đề xuất dùng công nghệ ngoài danh mục, đi kèm lý do kỹ thuật/kinh doanh cụ thể, được Architecture Review Board (ARB — sẽ nói kỹ ở bài 31) xét duyệt trong thời gian ngắn (ví dụ 5 ngày làm việc), không phải một quy trình quan liêu kéo dài hàng tháng làm nản lòng đổi mới.

3. TRM là tài liệu sống, review định kỳ (6-12 tháng), không phải văn bản đóng băng. Công nghệ được đưa vào danh mục "Approved" cần review lại theo chu kỳ để không biến TRM thành một danh sách lỗi thời chặn cả những cải tiến hợp lý.

Liên kết TRM với Gap Analysis

TRM không tồn tại độc lập — nó là đầu vào trực tiếp cho Gap Analysis giữa Baseline Technology Architecture (hiện trạng công nghệ đang chạy) và Target Technology Architecture (TRM mục tiêu). Kỹ thuật chuẩn của TOGAF ở đây là dùng ma trận (matrix) liệt kê từng thành phần công nghệ hiện có, đối chiếu với tầng TRM mục tiêu tương ứng, đánh dấu trạng thái: Giữ nguyên (Retain), Thay thế (Replace), Loại bỏ (Retire), hoặc Bổ sung mới (New). Ma trận này chính là cầu nối trực tiếp sang việc lập lộ trình di trú ở giai đoạn kế tiếp.

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ô hình tổ chức phổ biến, không phải case của một công ty cụ thể có thật, không có số liệu định lượng chính xác.)

Một tổ chức dịch vụ tài chính quy mô trung bình, sau vài năm tăng trưởng qua nhiều đợt tuyển dụng đội ngũ kỹ thuật độc lập theo từng dự án, phát hiện ra bức tranh sau khi EA team làm một cuộc kiểm kê công nghệ (technology inventory) lần đầu tiên: có nhiều hơn một giải pháp cho cùng một chức năng cốt lõi ở hầu hết các tầng — nhiều ngôn ngữ backend khác nhau cho các service cùng loại nghiệp vụ, nhiều giải pháp message queue song song không có lý do kỹ thuật rõ ràng, nhiều nền tảng CI/CD khác nhau giữa các team, và nhiều công cụ quan sát hệ thống (observability) không liên thông với nhau khiến việc điều tra sự cố xuyên hệ thống trở nên cực kỳ chậm.

Hệ quả vận hành cụ thể mà tổ chức này gặp phải:

• Tuyển dụng khó khăn hơn: mỗi vị trí kỹ sư cần một tổ hợp kỹ năng riêng biệt, JD không thể chuẩn hóa, thời gian tuyển kéo dài.
• Chi phí license và hạ tầng bị nhân đôi cho các chức năng tương đương nhau, không tận dụng được lợi thế quy mô khi đàm phán với vendor.
• Onboarding kỹ sư mới chậm: mỗi team có stack riêng, kiến thức không chuyển giao được giữa các nhóm, không ai có thể "nhảy" hỗ trợ team khác khi cần.
• Sự cố bảo mật khó kiểm soát tập trung: mỗi giải pháp IAM/secrets riêng biệt nghĩa là patch bảo mật phải làm N lần thay vì một lần.

EA team khởi động một sáng kiến chuẩn hóa theo đúng tinh thần TRM: không cấm đoán ngay lập tức, mà (1) kiểm kê toàn bộ công nghệ đang chạy theo 6 tầng nêu trên, (2) với mỗi tầng, chọn ra 1-2 chuẩn dựa trên tiêu chí năng lực đội ngũ hiện có + độ trưởng thành hệ sinh thái + chi phí vận hành dài hạn, (3) phân loại từng công nghệ hiện hữu vào Retain/Replace/Retire theo ma trận Gap Analysis, (4) lập lộ trình di trú theo mức độ rủi ro và chi phí — ưu tiên chuẩn hóa tầng Security & Identity trước vì rủi ro tập trung cao nhất, các tầng ít rủi ro hơn di trú dần theo vòng đời tự nhiên của dự án (không ép buộc big-bang rewrite).

Kết quả sau khi triển khai TRM và lộ trình di trú kéo dài qua nhiều quý: độ phức tạp vận hành giảm đáng kể — số lượng "biến thể công nghệ" cho mỗi chức năng giảm mạnh, thời gian onboarding kỹ sư mới rút ngắn vì stack đã chuẩn hóa, và ARB có một cơ sở rõ ràng để đánh giá đề xuất công nghệ mới thay vì mỗi lần tranh luận lại từ đầu.

📐 Template/Artifact áp dụng ngay

Technology Reference Model Catalog — bảng chuẩn dùng để công bố nội bộ và làm cơ sở review ARB:

Checklist khi một team đề xuất công nghệ mới (Architecture Exception Request):

1. Chức năng này đã có công nghệ "Standard" hoặc "Approved" đáp ứng chưa? Nếu có, lý do cụ thể không dùng được là gì?
2. Công nghệ mới có đội ngũ đủ năng lực vận hành lâu dài (không chỉ triển khai ban đầu) không?
3. Tổng chi phí sở hữu (license + vận hành + đào tạo) so với phương án chuẩn đã có là bao nhiêu?
4. Nếu được duyệt, công nghệ này gia nhập danh mục "Approved" cho toàn tổ chức, hay chỉ là ngoại lệ riêng cho dự án này (time-boxed exception)?
5. Ai là owner chịu trách nhiệm vòng đời (bảo trì, vá lỗi, nâng cấp) nếu công nghệ này được chấp thuận?

🎯 Góc nhìn Chief EA

Nếu hôm nay tôi yêu cầu liệt kê toàn bộ công nghệ đang chạy cho từng chức năng cốt lõi (queue, cache, auth, CI/CD...), danh sách đó có bao nhiêu dòng trùng chức năng nhưng khác vendor — và mỗi dòng trùng đó có lý do kỹ thuật thật sự hay chỉ là quán tính lựa chọn cá nhân?
Quy trình duyệt ngoại lệ công nghệ (exception process) của tổ chức mất bao lâu — nếu quá chậm, engineer sẽ âm thầm lách qua nó; nếu quá lỏng, TRM chỉ còn là văn bản trang trí?
TRM hiện tại được review lần cuối khi nào — nó còn phản ánh đúng năng lực đội ngũ và bối cảnh công nghệ hôm nay, hay đang chặn những cải tiến hợp lý vì lỗi thời?
Ai thực sự là owner của từng tầng TRM — nếu không ai chịu trách nhiệm rõ ràng, ai sẽ là người nói "không" khi cần?

🔄 Vị trí trong chu trình ADM

Giai đoạn D nhận đầu vào trực tiếp từ Data Architecture và Application Portfolio đã xác định ở Giai đoạn C (xem Giai đoạn C – Kiến trúc dữ liệu tập trung và Giai đoạn C – Application Portfolio) — TRM phải được thiết kế để phục vụ đúng nhu cầu lưu trữ, xử lý, và giao tiếp mà các ứng dụng và luồng dữ liệu mục tiêu đòi hỏi, không phải chọn công nghệ trước rồi ép ứng dụng thích nghi sau.

Đầu ra của Giai đoạn D — Target Technology Architecture cùng Gap Analysis giữa hiện trạng và TRM mục tiêu — là cơ sở trực tiếp cho Giai đoạn E – Migration Planning: TRM xác định "đích đến" về công nghệ, để từ đó Giai đoạn E tính toán khoảng cách (gap) cụ thể và lập lộ trình chuyển đổi (migration roadmap) theo thứ tự ưu tiên, chi phí và rủi ro.

🔗 Bài viết liên quan

• Giai đoạn C (Application): Application Portfolio — nguồn đầu vào trực tiếp để xác định TRM cần phục vụ những gì.
• Catalog, Matrix, Diagram — kỹ thuật trình bày artifact dạng bảng/ma trận mà TRM và Gap Analysis sử dụng xuyên suốt.

Bài trước: Giai đoạn C (Application) · Bài tiếp theo: Giai đoạn E (Migration Planning)