title: "Giai đoạn A (Vision): Xây dựng Architecture Vision thuyết phục"
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: 11
audience: "Enterprise Architect (EA) & Solutions Architect hướng EA"
reading_time: "13 phút"
tags:

• TOGAF
• ADM
• Architecture Vision
• Giai đoạn A
• Statement of Architecture Work
• Business Scenario

Giai đoạn A (Vision): Xây dựng Architecture Vision thuyết phục

Tôi từng ngồi trong một buổi trình bày Architecture Vision kéo dài 45 phút, do một kiến trúc sư giỏi kỹ thuật nhưng lần đầu đứng trước ban điều hành. Slide đầu tiên là sơ đồ target architecture với microservices, event-driven messaging, API gateway, container orchestration — mọi từ khóa công nghệ mới nhất đều có mặt. Slide thứ hai liệt kê thêm mười công nghệ nữa. Đến phút thứ hai mươi, CFO đặt một câu hỏi duy nhất: "Vậy cái này giúp công ty tiết kiệm được bao nhiêu, hay bán được nhanh hơn bao nhiêu?" Phòng họp im lặng. Vision bị gác lại "chờ làm rõ thêm", và dự án kiến trúc mất ba tháng để xin phê duyệt lại.

Đây không phải là câu chuyện hiếm. Nó là kịch bản lặp đi lặp lại ở hầu hết tổ chức lần đầu chạy ADM (Architecture Development Method — phương pháp phát triển kiến trúc theo chu trình của TOGAF) một cách nghiêm túc. Giai đoạn A — Architecture Vision — bị hiểu nhầm phổ biến nhất trong toàn bộ tám giai đoạn ADM: nhiều người nghĩ đây là nơi "vẽ bức tranh công nghệ tương lai", trong khi bản chất của nó là một bài toán thuyết phục kinh doanh, không phải một bài toán kỹ thuật.

Bài này mổ xẻ Giai đoạn A đúng với vai trò thật của nó: trạm khởi động của cả chu trình ADM, nơi một Chief EA phải trả lời được câu hỏi "tại sao dự án kiến trúc này đáng để tổ chức đầu tư thời gian, tiền bạc, và sự chú ý của ban lãnh đạo" — trước khi bất kỳ ai được phép nói đến công nghệ cụ thể.

Bản chất

Giai đoạn A trong ADM có một mục tiêu duy nhất, dễ bị lãng quên giữa hàng loạt artifact và template: xin được sự phê duyệt (approval) để tiếp tục đầu tư vào công việc kiến trúc. Đây không phải là giai đoạn thiết kế chi tiết — đó là việc của Giai đoạn B, C, D. Giai đoạn A là giai đoạn "bán ý tưởng" (dù không ai thích dùng từ "bán" trong ngữ cảnh kiến trúc, nhưng đó chính xác là bản chất): thuyết phục stakeholder cấp cao rằng có một khoảng cách đủ lớn giữa hiện trạng và mục tiêu kinh doanh, và đầu tư vào kiến trúc là con đường đúng để lấp khoảng cách đó.

Ba sai lầm phổ biến nhất khi tổ chức chạy Giai đoạn A:

Sai lầm 1 — Vision là danh sách công nghệ. Đây là lỗi kinh điển trong ví dụ mở bài. Một Architecture Vision liệt kê "chúng ta sẽ dùng Kubernetes, event streaming, microservices" không trả lời được câu hỏi tối quan trọng của bất kỳ nhà tài trợ (sponsor) nào: "Vậy thì sao?" (So what?). Công nghệ là phương tiện, không phải là giá trị. Ban lãnh đạo không phê duyệt ngân sách cho Kubernetes — họ phê duyệt ngân sách cho việc rút ngắn thời gian ra mắt sản phẩm mới từ 6 tháng xuống 6 tuần, hay giảm 30% chi phí vận hành hạ tầng.

Sai lầm 2 — Vision đi thẳng vào chi tiết Target Architecture. Đây là giai đoạn "high-level" — TOGAF cố tình dùng từ này. Architecture Vision không phải là bản thiết kế đầy đủ, nó là bản phác thảo đủ rõ để mọi người hình dung được điểm đến, nhưng đủ mở để các giai đoạn B/C/D sau này có không gian thiết kế chi tiết. Vẽ target architecture ở mức chi tiết ngay từ Giai đoạn A vừa lãng phí công sức (vì stakeholder có thể bác bỏ toàn bộ hướng đi), vừa làm chậm quá trình phê duyệt.

Sai lầm 3 — Bỏ qua Business Scenario, nhảy thẳng vào tài liệu Vision. Business Scenario là kỹ thuật TOGAF khuyến nghị dùng ngay từ đầu Giai đoạn A để "chưng cất" yêu cầu kinh doanh thành driver kiến trúc cụ thể. Bỏ qua bước này khiến Vision trở thành một tài liệu do kiến trúc sư tự suy diễn thay vì một tài liệu bắt nguồn trực tiếp từ nỗi đau kinh doanh thật.

Cốt lõi cần nhớ: Architecture Vision phải trả lời được một câu hỏi kinh doanh cụ thể, đo lường được — không phải mô tả một trạng thái công nghệ mong muốn.

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

Một Architecture Vision đạt chuẩn TOGAF, đủ sức thuyết phục ban lãnh đạo, cần ba thành phần cốt lõi phối hợp với nhau:

Kỹ thuật Business Scenario đáng nói kỹ hơn vì đây là công cụ hay bị bỏ qua nhất. Cấu trúc chuẩn của một Business Scenario gồm:

1. Problem — vấn đề kinh doanh cụ thể (không phải vấn đề công nghệ).
2. Business & technology environment — bối cảnh hiện tại nơi vấn đề xảy ra.
3. Objectives — mục tiêu kinh doanh, tốt nhất là có chỉ số đo lường được.
4. Human actors & their roles — ai tham gia, vai trò gì.
5. Computer actors & their roles — hệ thống/ứng dụng nào tham gia (chỉ ở mức khái quát).
6. Desired outcome — kết quả mong muốn, mô tả bằng ngôn ngữ kinh doanh.

Nguyên tắc vàng khi soạn Business Scenario: luôn viết Objectives bằng đơn vị đo kinh doanh (%, thời gian, tiền), không bao giờ bằng đơn vị công nghệ. "Giảm 30% chi phí vận hành hạ tầng trong 18 tháng" là một Objective đúng chuẩn. "Chuyển sang kiến trúc cloud-native" không phải — đó là một giải pháp giả định trước khi vấn đề được xác nhận.

Nguyên tắc kiểm tra chất lượng Vision mà tôi luôn áp dụng trước khi trình bày cho ban lãnh đạo — bài kiểm tra "So what?": đọc lại từng câu trong Vision, nếu câu đó có thể bị hỏi ngược "vậy thì sao, ảnh hưởng gì đến kết quả kinh doanh?" mà không có câu trả lời rõ ràng, câu đó chưa đủ chín để đưa vào tài liệu chính thức.

Case thực tế minh hoạ

(Minh hoạ điển hình tổng hợp — không phải case của một doanh nghiệp cụ thể có thật, không phản ánh số liệu hay tên gọi thực tế nào.)

Một công ty bán lẻ đa kênh đang vận hành hệ thống quản lý đơn hàng (order management) cũ, được xây từ nhiều năm trước, gây khó khăn khi mở rộng sang kênh bán hàng mới. Đội kiến trúc soạn một Architecture Vision đầu tiên với nội dung chính: "Xây dựng lại hệ thống order management theo kiến trúc microservices, sử dụng event-driven architecture, triển khai trên nền tảng container, tích hợp API gateway hiện đại." Kèm theo là sơ đồ kỹ thuật chi tiết với hơn mười thành phần công nghệ.

Vision này được trình lên ban điều hành và bị từ chối. Lý do từ chối, ghi lại nguyên văn trong biên bản họp: "Không rõ khoản đầu tư này giải quyết vấn đề kinh doanh cụ thể nào, và không có cách nào đo được liệu nó có thành công hay không." Ban điều hành không phản đối công nghệ — họ phản đối việc không thấy được mối liên hệ giữa công nghệ và kết quả kinh doanh.

Đội kiến trúc quay lại, áp dụng đúng kỹ thuật Business Scenario trước khi viết lại Vision. Qua các buổi phỏng vấn với đội vận hành và đội kinh doanh, họ xác định được hai nỗi đau cụ thể: (1) mỗi lần mở kênh bán hàng mới mất trung bình nhiều tháng để tích hợp với hệ thống order management cũ, trực tiếp làm chậm việc ra mắt sản phẩm/kênh mới; (2) chi phí vận hành hạ tầng cho hệ thống cũ tăng đều đặn do kiến trúc monolithic không co giãn được theo tải, trong khi tải lại tăng mạnh vào các đợt cao điểm bán hàng.

Architecture Vision phiên bản hai được viết lại với Objectives cụ thể: rút ngắn đáng kể thời gian tích hợp kênh bán hàng mới, và giảm chi phí vận hành hạ tầng theo tỷ lệ phần trăm cụ thể trong một khung thời gian xác định. Phần công nghệ (microservices, event-driven, container) vẫn xuất hiện — nhưng chỉ ở mức "đây là hướng tiếp cận kỹ thuật cấp cao để đạt được hai mục tiêu trên", đặt sau phần mục tiêu kinh doanh, không đặt trước. High-level Target Architecture cũng được vẽ lại đơn giản hơn nhiều — chỉ đủ để minh họa "hệ thống sẽ tách rời thành các thành phần độc lập, có thể mở rộng riêng lẻ theo kênh bán hàng" mà không đi vào chi tiết công nghệ cụ thể sẽ chọn.

Vision phiên bản hai được phê duyệt trong buổi họp đầu tiên trình bày. Bài học rút ra không nằm ở việc thay đổi công nghệ đề xuất — công nghệ gần như giữ nguyên — mà nằm ở việc đảo ngược thứ tự trình bày: mục tiêu kinh doanh đo lường được đứng trước, công nghệ đứng sau và chỉ đóng vai trò phương tiện.

📐 Template/Artifact áp dụng ngay

Bảng kiểm Architecture Vision — dùng trước khi trình bày cho stakeholder cấp cao:

Mẫu khung Business Scenario rút gọn (điền trực tiếp):

1. Problem (vấn đề kinh doanh):
2. Bối cảnh hiện tại (business & technology environment):
3. Objectives (đo lường được, đơn vị kinh doanh):
4. Human actors & vai trò:
5. Computer actors & vai trò (chỉ mức khái quát):
6. Desired outcome (mô tả bằng ngôn ngữ kinh doanh):

🎯 Góc nhìn Chief EA

• Nếu tôi xóa hết tên công nghệ khỏi bản Vision này, nó có còn thuyết phục được ban lãnh đạo không — hay toàn bộ sức nặng đang dựa vào sự hào nhoáng của công nghệ?
• Objectives trong Vision có đo lường được không, hay chỉ là những tính từ đẹp như "nhanh hơn", "linh hoạt hơn", "hiện đại hơn"?
• Tôi đã thật sự phỏng vấn actor kinh doanh chịu ảnh hưởng, hay tôi đang tự suy diễn nỗi đau của họ từ góc nhìn kỹ thuật?
• Nếu dự án kiến trúc này thất bại hoàn toàn, người phê duyệt ngân sách sẽ mất gì cụ thể — và tôi đã nói rõ điều đó chưa?

🔄 Vị trí trong chu trình ADM

Giai đoạn A là TRẠM ĐẦU TIÊN của chu trình ADM. Nó nhận đầu vào từ Preliminary Phase — giai đoạn thiết lập Architecture Capability đã bàn ở Phần 1, Bài 5 — cùng với yêu cầu kinh doanh ban đầu do stakeholder hoặc sự kiện kích hoạt (ví dụ: chiến lược kinh doanh mới, yêu cầu M&A, sức ép cạnh tranh) đưa ra.

Đầu ra của Giai đoạn A — Architecture Vision đã được phê duyệt, cùng Statement of Architecture Work — chảy sang Giai đoạn B (Business Architecture), được mổ xẻ ở Bài 13-14. Architecture Vision đóng vai trò kim chỉ nam: mọi giai đoạn sau trong vòng lặp ADM — từ Business Architecture, Information Systems Architecture, Technology Architecture, cho đến Migration Planning — đều phải bám sát và không được đi lệch khỏi mục tiêu kinh doanh đã cam kết ở Giai đoạn A. Nếu phát hiện lệch hướng ở bất kỳ giai đoạn nào sau này, đó là tín hiệu cần quay lại xem xét lại chính Vision, chứ không phải âm thầm điều chỉnh giai đoạn hiện tại cho khớp.

🔗 Bài viết liên quan

• Thiết lập Architecture Capability — nền tảng tổ chức và năng lực phải có trước khi bước vào Giai đoạn A.
• Giai đoạn A (Stakeholder Management) — kỹ thuật quản lý các bên liên quan song hành với việc xây dựng Vision, giúp Vision không chỉ đúng mà còn được chấp nhận.

Bài trước: Vai trò của EA trong chuyển đổi số (Digital Transformation) · Bài tiếp theo: Giai đoạn A (Stakeholder Management)