title: "Đo lường sự thành công của EA: Làm sao để định lượng giá trị của một bản vẽ kiến trúc?"
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: 9
audience: "Enterprise Architect (EA) & Solutions Architect hướng EA"
reading_time: "12 phút"
tags:

• TOGAF
• Enterprise Architecture
• EA Value Measurement
• Architecture Metrics
• Business Case
• Chief EA

Đo lường sự thành công của EA: Làm sao để định lượng giá trị của một bản vẽ kiến trúc?

Một buổi review ngân sách quý IV. CFO đặt câu hỏi thẳng: "Phòng Kiến trúc tiêu 4 tỷ đồng năm nay. Cho tôi biết nó tạo ra bao nhiêu giá trị." Chief EA mở slide, trình bày mười mấy sơ đồ ArchiMate được vẽ, ba Reference Architecture đã ban hành, một Technology Radar cập nhật hàng quý. CFO gật đầu lịch sự, rồi hỏi lại: "Đó là output. Tôi hỏi về outcome — nó tiết kiệm được bao nhiêu tiền, tránh được rủi ro gì, hay giúp doanh nghiệp kiếm thêm được gì?" Phòng họp im lặng. Ngân sách EA năm sau bị cắt 30%.

Đây không phải tình huống hiếm. Nó là kịch bản lặp lại ở hầu hết doanh nghiệp có phòng EA quá ba năm tuổi — cái ngưỡng mà "đầu tư xây nền" bắt đầu bị soi dưới lăng kính ROI. Vấn đề không nằm ở việc EA không tạo ra giá trị — phần lớn thời gian nó có. Vấn đề nằm ở chỗ EA đo lường thành công của chính mình bằng ngôn ngữ sai: số lượng artifact, mức độ tuân thủ framework, độ "đẹp" của sơ đồ. Đó là ngôn ngữ nội bộ của nghề kiến trúc, không phải ngôn ngữ mà Hội đồng quản trị hay CFO dùng để quyết định phân bổ ngân sách.

Bài này không bàn về cách vẽ kiến trúc đẹp hơn. Nó bàn về một kỹ năng sinh tồn của Chief EA: biến giá trị kiến trúc — vốn dĩ mang tính hệ thống, dài hạn, khó quy đổi trực tiếp — thành những con số mà một buổi review ngân sách chấp nhận được.

Bản chất

Có một hiểu lầm nền tảng cần đập bỏ trước: EA không sản xuất ra giá trị trực tiếp — nó sản xuất ra khả năng (capability) để tổ chức tạo giá trị nhanh hơn, rẻ hơn, an toàn hơn. Đây là lý do EA khó đo lường hơn một team sales hay một team product: giá trị của một Reference Architecture không nằm ở bản thân nó, mà nằm ở việc dự án số 5, số 6, số 7 dùng lại nó thay vì làm lại từ đầu.

Điều này tạo ra ba đặc điểm khiến việc đo lường EA khác biệt so với đo lường một sản phẩm hay một chiến dịch:

Giá trị là gián tiếp và trễ (lagging). EA thiết kế Target Architecture hôm nay, nhưng tiết kiệm chi phí thực sự chỉ xuất hiện sau 12-24 tháng khi các dự án migration hoàn tất. Nếu đo lường EA bằng KPI ngắn hạn kiểu sales, nó sẽ luôn thua.

Giá trị là có điều kiện (counterfactual). "Giảm thời gian tích hợp từ 6 tuần xuống 2 tuần" chỉ có ý nghĩa khi có baseline đáng tin — tức là phải biết trước khi có kiến trúc chuẩn thì mất bao lâu. Không có baseline, mọi con số đều là khẳng định miệng.

Giá trị là tập thể, không phải cá nhân. Một sản phẩm thành công có thể quy công cho một Product Manager. Một nền tảng API dùng chung thành công là công sức cộng gộp của EA, platform engineering, và kỷ luật tuân thủ của các đội dự án. EA phải học cách nói "chúng tôi là một phần nguyên nhân" thay vì "chúng tôi là nguyên nhân duy nhất" — điều này ảnh hưởng đến cách trình bày số liệu để không bị bác bỏ vì cường điệu.

Từ ba đặc điểm này, nguyên tắc cốt lõi của việc đo lường EA là: đo lường độ trễ giữa nhu cầu kinh doanh và năng lực đáp ứng, chứ không đo lường khối lượng công việc kiến trúc. Một EA làm ra ít tài liệu hơn nhưng rút ngắn được time-to-market của mọi dự án mới có giá trị gấp nhiều lần một EA sản xuất hàng trăm trang catalog không ai dùng lại.

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

TOGAF không quy định một bộ KPI cứng cho việc đo lường giá trị EA — điều này nằm ở phần thực hành Architecture Governance và Architecture Capability, nơi tổ chức tự thiết kế Balanced Scorecard riêng cho chức năng kiến trúc. Dưới đây là bốn nhóm chỉ số đã được kiểm chứng rộng rãi trong thực hành ngành, sắp theo mức độ "gần với ngôn ngữ tài chính" tăng dần.

Ba nguyên tắc khi chọn chỉ số cho scorecard này:

Nguyên tắc 1 — Luôn có baseline trước khi can thiệp. Không đo "chúng tôi đã cải thiện" mà đo "trước X, sau Y, chênh lệch Z". Nếu tổ chức chưa có baseline, nhiệm vụ đầu tiên của một sáng kiến EA mới không phải là thiết kế — mà là đo lường trạng thái hiện tại (baseline audit) trước khi động vào bất cứ thứ gì.

Nguyên tắc 2 — Mỗi chỉ số kỹ thuật phải có một "bản dịch" sang ngôn ngữ tài chính hoặc kinh doanh. "Giảm 40% số lượng middleware trùng lặp" là chỉ số kỹ thuật. "Tiết kiệm 2.5 tỷ đồng chi phí license và vận hành mỗi năm" là bản dịch mà CFO nghe được. Chief EA phải làm việc với FinOps hoặc Kế toán quản trị để có công thức quy đổi đáng tin, không tự ước lượng một mình.

Nguyên tắc 3 — Tách bạch chỉ số "sức khỏe nội bộ" (health metrics) khỏi chỉ số "trình bày ra ngoài" (value metrics). % hoàn thành Architecture Repository, số ADR (Architecture Decision Record) được ghi nhận, mức độ trưởng thành của Architecture Capability theo mô hình maturity — đây là các chỉ số vận hành nội bộ, hữu ích để Chief EA tự quản trị đội, nhưng không nên là nội dung chính khi trình bày trước Ban điều hành. Nhầm lẫn hai loại chỉ số này là nguyên nhân phổ biến nhất khiến các buổi báo cáo EA trước lãnh đạo trở nên khó hiểu và bị coi là "nói chuyện nội bộ".

Case thực tế minh hoạ

Lưu ý: đây là tình huống minh hoạ điển hình được 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 công ty cụ thể có thật, và các con số dưới đây chỉ mang tính minh hoạ cho phương pháp, không phải số liệu thống kê thực tế.

Một doanh nghiệp dịch vụ tài chính tiêu dùng vận hành khoảng 15 hệ thống nghiệp vụ, mỗi hệ thống tích hợp với nhau qua các kết nối point-to-point riêng lẻ được dựng thủ công cho từng dự án. Mỗi lần ra mắt sản phẩm mới cần kết nối với 3-4 hệ thống lõi (core banking, CRM, hệ thống chấm điểm tín dụng, hệ thống thanh toán), đội dự án phải tự đàm phán giao thức, tự xây connector, tự xử lý lỗi đồng bộ — trung bình mất 6-8 tuần chỉ riêng cho phần tích hợp, trước khi tính đến phát triển tính năng nghiệp vụ.

Phòng EA đề xuất và được phê duyệt xây dựng một API Gateway/nền tảng tích hợp dùng chung (shared integration platform), chuẩn hóa giao thức, xác thực, logging, và cung cấp bộ API đã kiểm thử cho các hệ thống lõi. Trước khi triển khai, Chief EA làm ba việc mà nhiều phòng EA bỏ qua:

Thứ nhất, đo baseline một cách có hệ thống: rà soát 12 dự án tích hợp gần nhất trong 18 tháng, ghi nhận thời gian tích hợp trung bình, số lỗi phát sinh sau go-live liên quan đến tích hợp, và chi phí nhân sự quy đổi cho công đoạn này.

Thứ hai, thống nhất trước với CFO và Trưởng phòng Sản phẩm về công thức quy đổi: mỗi tuần rút ngắn được trong giai đoạn tích hợp tương đương với X ngày-người tiết kiệm, và với sản phẩm mới thời gian ra mắt sớm hơn có thể quy đổi tương đối sang doanh thu sớm hơn dựa trên đường cong doanh thu trung bình của các sản phẩm tương tự.

Thứ ba, thiết lập cơ chế theo dõi liên tục — không phải báo cáo một lần khi dự án xong, mà đo lại sau mỗi 2 dự án tích hợp mới trong 12 tháng tiếp theo, để chứng minh xu hướng chứ không phải một điểm dữ liệu may mắn.

Sau khi nền tảng đi vào vận hành, thời gian tích hợp trung bình cho một hệ thống mới giảm rõ rệt xuống còn khoảng 2 tuần, tỷ lệ sự cố sau go-live liên quan đến tích hợp cũng giảm đáng kể nhờ bộ API đã được kiểm thử và chuẩn hóa sẵn. Khi trình bày trước Ban điều hành vào kỳ review ngân sách kế tiếp, Chief EA không mở đầu bằng sơ đồ kiến trúc — mà mở đầu bằng một biểu đồ xu hướng: trục hoành là các dự án theo thời gian, trục tung là số tuần tích hợp, với một đường gãy rõ rệt đi xuống ngay từ thời điểm nền tảng ra mắt, kèm theo con số quy đổi chi phí nhân sự tiết kiệm được và ước tính doanh thu ghi nhận sớm hơn nhờ rút ngắn thời gian ra mắt. Ngân sách EA năm sau không những được giữ nguyên mà còn được bổ sung để mở rộng nền tảng sang các domain khác.

Điểm mấu chốt của case này không phải là bản thân nền tảng API — công nghệ đó không có gì đặc biệt mới. Điểm mấu chốt là kỷ luật đo baseline trước, thống nhất công thức quy đổi tài chính trước khi triển khai, và theo dõi liên tục thay vì báo cáo một lần.

📐 Template/Artifact áp dụng ngay

EA Value Scorecard — mẫu bảng theo dõi giá trị theo quý

Hướng dẫn dùng bảng:

1. Điền cột "Baseline" trước khi bất kỳ sáng kiến kiến trúc nào bắt đầu — không có dòng này, đừng bắt đầu đo lường.
2. Cột "Quy đổi tài chính/kinh doanh" phải được thống nhất công thức với Kế toán quản trị/FinOps, không tự ước lượng.
3. Cột "Người xác nhận số liệu" bắt buộc có — số liệu do chính EA tự đo và tự báo cáo không có sức thuyết phục bằng số liệu được bên thứ ba (PMO, Ops, Finance) xác nhận.
4. Cập nhật theo quý, trình bày dưới dạng xu hướng (trend line) chứ không phải một điểm dữ liệu đơn lẻ khi báo cáo Ban điều hành.

🎯 Góc nhìn Chief EA

Nếu ngày mai ngân sách của tôi bị cắt, tôi có ba con số cụ thể — bằng VNĐ hoặc bằng tuần thời gian — để chứng minh phòng EA đã tiết kiệm hoặc tránh được cho công ty nhiều hơn số tiền đã chi không?

Những chỉ số tôi đang báo cáo lên Ban điều hành — chúng nói ngôn ngữ của kiến trúc sư, hay ngôn ngữ của CFO?
Tôi có baseline đáng tin cho từng sáng kiến kiến trúc lớn trước khi bắt tay vào làm, hay tôi đang cố suy ra baseline sau khi mọi việc đã xong?
Tôi có đang nhầm lẫn giữa "chúng tôi làm rất nhiều việc" (số artifact, số review) với "chúng tôi tạo ra rất nhiều giá trị" (thời gian, chi phí, rủi ro thực sự thay đổi) không?

🔗 Bài viết liên quan

• Văn hóa kiến trúc — vì một scorecard giá trị chỉ phát huy tác dụng khi văn hóa tổ chức thực sự tin và dùng số liệu đó để ra quyết định.
• Kỹ năng lãnh đạo của một Chief EA — kỹ năng trình bày giá trị kiến trúc bằng ngôn ngữ tài chính là một năng lực lãnh đạo, không phải năng lực kỹ thuật.

Bài trước: Văn hóa kiến trúc · Bài tiếp theo: Vai trò của EA trong chuyển đổi số (Digital Transformation)