title: "Cloud-Native EA: Điều chỉnh TOGAF cho môi trường Cloud (AWS, Azure, GCP)"
series: "TOGAF Mastery: Kiến trúc sư Doanh nghiệp Chuyên sâu"
part: "Phần 4 — Vận hành kiến trúc cấp chuyên gia (Expert Ops)"
order: 33
audience: "Enterprise Architect (EA) & Solutions Architect hướng EA"
reading_time: "13 phút"
tags:

• TOGAF
• Cloud-Native
• TRM
• Multi-Cloud
• Vendor Lock-in
• Enterprise Architecture

Cloud-Native EA: Điều chỉnh TOGAF cho môi trường Cloud (AWS, Azure, GCP)

Có một buổi review kiến trúc mà tôi nhớ mãi. Team hạ tầng trình bày một Technology Reference Model (TRM — mô hình tham chiếu công nghệ, artifact chuẩn hoá các lớp công nghệ nền tảng của TOGAF) dày 40 trang, vẽ rất đẹp, phân lớp rõ ràng theo đúng khung TOGAF cổ điển: hạ tầng vật lý, hệ điều hành, middleware, tầng ứng dụng. Vấn đề là mọi ô trong bản vẽ đó đều ghi tên dịch vụ cụ thể của một nhà cung cấp cloud — không phải "message queue capability" mà là tên thương hiệu chính xác của dịch vụ, không phải "managed relational database" mà là tên sản phẩm cụ thể kèm số phiên bản engine. Khi CFO yêu cầu đánh giá lại chi phí hạ tầng sau ba năm, câu trả lời từ đội kiến trúc là: "Về mặt kỹ thuật có thể, nhưng sẽ mất 8-12 tháng và rủi ro rất cao vì toàn bộ pipeline CI/CD, IAM, observability đều viết theo API riêng của nhà cung cấp đó."

Đây không phải lỗi của TOGAF. TOGAF ra đời và trưởng thành trong giai đoạn hạ tầng doanh nghiệp còn là data center tự vận hành, máy chủ vật lý, SAN storage, network switch — thế giới nơi "Technology Architecture" nghĩa là bạn sở hữu và cấu hình từng lớp. Cloud không phá vỡ tư duy đó, nhưng nó thay đổi bản chất của cái mà TRM cần mô tả: từ "chúng ta vận hành cái gì" sang "chúng ta cần khả năng gì, và ai cung cấp khả năng đó theo mô hình gì". Một EA không hiểu sự khác biệt này sẽ tiếp tục vẽ TRM như thể đang mua server, trong khi thực tế đang mua capability theo hợp đồng dịch vụ.

Bài này không dạy lại AWS/Azure/GCP là gì — đó là kiến thức Solutions Architect đã có. Trọng tâm là: EA cần điều chỉnh cách viết artifact TOGAF (đặc biệt là TRM ở Giai đoạn D và chiến lược Migration Planning ở Giai đoạn E) để kiến trúc vẫn đúng tinh thần "công nghệ phục vụ chiến lược", chứ không bị khoá cứng vào một nhà cung cấp ngay từ khâu tài liệu.

Bản chất

TOGAF nguyên bản coi Technology Architecture là một trong bốn miền kiến trúc (Business, Data, Application, Technology), với TRM là artifact mô tả các "building block" công nghệ theo kiến trúc phân lớp — compute, storage, network, platform services, tất cả được giả định là tài sản doanh nghiệp sở hữu hoặc thuê dài hạn và tự cấu hình.

Cloud-native đảo ngược giả định nền tảng đó theo ba cách mà EA phải nắm rõ:

Một, ranh giới "chúng ta kiểm soát" co lại. Trong mô hình on-premise, EA kiểm soát từ tầng vật lý trở lên. Trong cloud, tuỳ mô hình dịch vụ (IaaS/PaaS/SaaS/FaaS), một phần lớn của TRM truyền thống — từ hypervisor trở xuống, đôi khi cả hệ điều hành, runtime, hay toàn bộ ứng dụng — nằm ngoài phạm vi kiến trúc mà tổ chức tự thiết kế. Đây không phải mất kiểm soát, mà là đánh đổi kiểm soát lấy tốc độ và giảm gánh vận hành — nhưng EA phải vẽ rõ ranh giới đó trong TRM, không được bỏ qua.

Hai, "managed service" trở thành một loại building block mới mà TOGAF cổ điển không có tên gọi chuẩn. Một hàng đợi tin nhắn được quản lý hoàn toàn bởi nhà cung cấp cloud không giống một middleware bạn cài trên VM — nó có SLA riêng, mô hình giá riêng, giới hạn kỹ thuật riêng, và quan trọng nhất: nó là một "khả năng thuê" (rented capability), không phải tài sản. TRM cloud-aware phải phân loại rõ đâu là khả năng tự vận hành, đâu là khả năng thuê theo managed service, vì rủi ro và chiến lược thoát (exit strategy) của hai loại này khác hẳn nhau.

Ba, migration không còn là "thay máy chủ" mà là một quyết định kiến trúc có phổ (spectrum), không phải nhị phân. Giai đoạn E (Migration Planning) trong TOGAF cổ điển thường coi migration là chuyển đổi baseline sang target theo một lộ trình tuyến tính. Với cloud, câu hỏi đầu tiên không phải "làm sao chuyển" mà là "chuyển theo chiến lược nào" — và mỗi lựa chọn kéo theo effort, rủi ro, và mức độ khoá nhà cung cấp khác nhau.

Điểm mấu chốt xuyên suốt cả ba thay đổi: nguyên tắc kiến trúc tham chiếu công nghệ trong thời cloud nên được viết ở mức capability (khả năng cần có), không phải ở mức sản phẩm cụ thể của một nhà cung cấp. Đây là kỷ luật quan trọng nhất mà bài này muốn nhấn mạnh, và nó sẽ được khai triển sâu hơn về chiến lược đa-cloud và tránh khoá nhà cung cấp ở bài kế tiếp thuộc mảng vendor management.

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

1. Tái cấu trúc TRM theo ba lớp: Capability — Pattern — Implementation

Thay vì TRM một lớp liệt kê thẳng tên dịch vụ, viết TRM theo ba lớp tách biệt:

Kỷ luật quan trọng: Architecture Principles và Architecture Vision chỉ nên tham chiếu đến lớp Capability. Lớp Implementation là chi tiết vận hành, thuộc phạm vi Solutions Architecture, có thể và nên thay đổi mà không cần review lại toàn bộ TRM cấp doanh nghiệp. Đây chính là cách một tổ chức tránh được tình huống "khoá cứng vào tài liệu" — vấn đề không nằm ở việc dùng dịch vụ của một nhà cung cấp (điều đó hoàn toàn hợp lý về mặt thương mại), mà ở việc tài liệu kiến trúc tham chiếu viết chết tên dịch vụ đó ở lớp nguyên tắc, khiến mọi quyết định sau này phải "giải thích ngoại lệ" thay vì tuân thủ tự nhiên.

2. Bổ sung "Cloud Fitness Criteria" vào Technology Portfolio Catalog

Với mỗi building block công nghệ trong catalog (artifact chuẩn của Giai đoạn D), thêm các thuộc tính đánh giá mức độ phù hợp cloud:

• Mức độ khoá nhà cung cấp (Lock-in Score): thấp (dùng API/giao thức mở, có thể thay thế), trung bình (dùng managed service nhưng có phần tương đương ở nhà cung cấp khác), cao (dùng tính năng độc quyền không có phần tương đương).
• Chiến lược thoát (Exit Strategy): nếu phải rời khỏi dịch vụ này trong 12 tháng, effort ước tính là gì — chỉ export data, hay viết lại toàn bộ tầng tích hợp.
• Mô hình chi phí: cố định, theo mức sử dụng (consumption-based), hay hỗn hợp — điều này ảnh hưởng trực tiếp tới Business Architecture (dự báo ngân sách) nên phải nằm trong catalog, không chỉ ở hợp đồng tài chính.
• Ranh giới trách nhiệm chia sẻ (Shared Responsibility Boundary): phần nào nhà cung cấp chịu trách nhiệm bảo mật/vận hành, phần nào tổ chức tự chịu — bắt buộc phải rõ ràng để Security Architecture (bài 28) không có lỗ hổng giả định.

3. Migration Planning: chọn chiến lược theo từng ứng dụng, không áp một công thức cho toàn danh mục

Giai đoạn E cổ điển tập trung vào lập kế hoạch chuyển đổi theo work package. Với cloud migration, bước đầu tiên là phân loại từng ứng dụng trong Application Portfolio (bài 16) theo một trong các chiến lược phổ biến, thường gọi tắt là các chữ R:

Việc gắn từng ứng dụng với một chiến lược không phải quyết định kỹ thuật đơn thuần — nó phải xuất phát từ Business Value và mức độ chiến lược của ứng dụng đó trong Business Capability Model (bài 14). Một EA giỏi sẽ từ chối áp một chiến lược duy nhất (ví dụ "refactor tất cả sang serverless") cho toàn bộ danh mục, vì đó là lãng phí effort cho những ứng dụng không cần tốc độ scale cao.

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 ngành — không phải case của một tổ chức cụ thể có thật, không có số liệu thực tế nào được sử dụng.)

Một tổ chức dịch vụ tài chính quy mô trung bình quyết định "cloud-first" và giao cho một đội kiến trúc nhỏ soạn TRM trong thời gian ngắn để kịp trình bày với ban điều hành. Vì áp lực thời gian, đội này lấy luôn kiến trúc tham chiếu chính thức do một nhà cung cấp cloud xuất bản, đổi logo, và đưa vào làm TRM chính thức của doanh nghiệp. Toàn bộ nguyên tắc kiến trúc, từ chọn cơ sở dữ liệu đến chọn cơ chế nhắn tin, đều viết thẳng tên dịch vụ của nhà cung cấp đó — không có lớp Capability trung gian nào.

Ba năm sau, hai điều xảy ra cùng lúc. Một, chi phí cloud tăng vượt dự báo do mô hình tiêu dùng (consumption-based) của một số dịch vụ lõi tăng phi tuyến theo tải, và bộ phận tài chính muốn đàm phán lại hoặc tìm phương án thay thế cho phần chi phí lớn nhất. Hai, một mảng kinh doanh mới của tổ chức có yêu cầu tuân thủ dữ liệu (data residency) mà nhà cung cấp cloud hiện tại không đáp ứng đầy đủ tại khu vực cần triển khai.

Khi đội kiến trúc mở TRM ra để đánh giá phương án đa-cloud hoặc chuyển một phần khối lượng công việc, họ phát hiện: không chỉ hạ tầng, mà cả script CI/CD, cấu hình IAM, logic xử lý lỗi trong tầng tích hợp, và thậm chí một số logic nghiệp vụ đều viết dựa trên đặc thù API của nhà cung cấp đó — không có lớp trừu tượng nào ở giữa. Đánh giá exit strategy cho thấy effort chuyển đổi tương đương với việc viết lại một phần đáng kể hệ thống lõi, khiến phương án đàm phán lại hợp đồng gần như mất hết đòn bẩy — nhà cung cấp biết rõ tổ chức không có lựa chọn thực tế nào khác trong ngắn hạn.

Bài học không phải là "đừng dùng managed service" — managed service vẫn là lựa chọn đúng cho phần lớn khối lượng công việc không mang tính khác biệt cạnh tranh. Bài học là: TRM đã thất bại trong vai trò của một artifact TOGAF đúng nghĩa — nó chỉ chụp lại một giải pháp tại một thời điểm, thay vì mô tả các khả năng và ràng buộc mà tổ chức cần quản lý lâu dài. Nếu TRM ban đầu được viết theo ba lớp Capability — Pattern — Implementation, đội kiến trúc đã có sẵn bức tranh rõ ràng về lock-in score của từng building block, và có thể đưa ra khuyến nghị exit strategy trong vài tuần thay vì phát hiện ra vấn đề khi đã quá muộn.

📐 Template/Artifact áp dụng ngay

Cloud-Aware Technology Reference Model — Capability Catalog (điền cho mỗi building block công nghệ trọng yếu trong danh mục)

Nguyên tắc dùng bảng này: Architecture Principles và Architecture Vision chỉ được trích dẫn cột "Capability Name". Mọi ADR (Architecture Decision Record) hay thiết kế giải pháp cụ thể mới được trích dẫn cột "Current Implementation". Nếu một kiến trúc sư viết nguyên tắc kiến trúc mà trích thẳng tên dịch vụ cụ thể của một nhà cung cấp, đó là dấu hiệu cần đưa ra Architecture Review Board (bài 31) để hiệu chỉnh.

🎯 Góc nhìn Chief EA

• Nếu ngày mai ban điều hành yêu cầu đàm phán lại hợp đồng với nhà cung cấp cloud chính, TRM hiện tại có cho tôi biết ngay building block nào là điểm nghẽn, và effort chuyển đổi ước tính bao nhiêu — hay tôi phải mất nhiều tuần điều tra lại từ đầu?
• Trong các Architecture Principles đang có hiệu lực, có bao nhiêu nguyên tắc trích dẫn thẳng tên một dịch vụ cụ thể của một nhà cung cấp thay vì mô tả ở mức khả năng?
• Đội giải pháp có đang chọn Rehost cho mọi thứ vì đó là con đường ít kháng cự nhất, trong khi những ứng dụng mang tính chiến lược thực sự cần Refactor để tạo lợi thế cạnh tranh?
• Nếu phải làm việc với một nhà cung cấp cloud thứ hai cho một yêu cầu tuân thủ mới xuất hiện đột ngột, tôi có sẵn bản đồ nào cho biết phần nào trong kiến trúc hiện tại portable, phần nào không?

🔗 Bài viết liên quan

• Giai đoạn D — Technology Reference Model — nền tảng TRM cổ điển mà bài này điều chỉnh cho bối cảnh cloud.
• Giai đoạn E — Migration Planning — khung lập kế hoạch chuyển đổi mà chiến lược Rehost/Replatform/Refactor bổ sung vào.

Bài trước: Architecture Debt · Bài tiếp theo: Agile Architecture