title: "Giai đoạn C (Application): Phân loại và quản trị danh mục ứng dụng (Application Portfolio)"
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: 16
audience: "Enterprise Architect (EA) & Solutions Architect hướng EA"
reading_time: "13 phút"
tags:

• TOGAF
• Enterprise Architecture
• Application Portfolio Management
• TIME Model
• Giai đoạn C
• Application Architecture

Giai đoạn C (Application): Phân loại và quản trị danh mục ứng dụng (Application Portfolio)

Hỏi CIO của bất kỳ doanh nghiệp nào đã vận hành trên 10 năm một câu đơn giản: "Công ty mình đang có bao nhiêu ứng dụng đang chạy?" Câu trả lời phổ biến nhất không phải một con số, mà là một khoảng im lặng, sau đó là "để em check lại với các team." Không ai biết chắc. Có ứng dụng do một phòng ban tự mua ngoài ngân sách IT chính thức (shadow IT), có hệ thống được một nhân viên đã nghỉ việc dựng lên bằng Excel macro rồi trở thành "hệ thống lõi" bất đắc dĩ, có phần mềm kế toán đời cũ chạy trên server vật lý mà không ai còn nhớ vì sao nó vẫn tồn tại.

Cái giá của sự mù mờ này không trừu tượng. Một doanh nghiệp trung bình chi phần lớn ngân sách IT vận hành hàng năm không phải cho đổi mới, mà cho "giữ đèn sáng" — bảo trì những hệ thống mà giá trị kinh doanh thực sự mang lại đã không còn tương xứng với chi phí bỏ ra. Vấn đề không phải là thiếu ứng dụng — mà là không ai từng ngồi xuống hỏi một cách hệ thống: ứng dụng này còn đáng để giữ không, và nếu giữ thì giữ ở mức nào?

Đây chính là khoảng trống mà Application Portfolio Management (quản trị danh mục ứng dụng) trong Giai đoạn C của ADM (Architecture Development Method — phương pháp phát triển kiến trúc theo chu trình của TOGAF) được thiết kế để lấp đầy. Không phải bằng cách vẽ thêm một biểu đồ đẹp, mà bằng một kỷ luật đánh giá định kỳ, có tiêu chí rõ ràng, buộc tổ chức phải trả lời câu hỏi khó: ứng dụng nào Tolerate, ứng dụng nào Invest, ứng dụng nào Migrate, ứng dụng nào Eliminate.

Bản chất

Trong TOGAF ADM, Giai đoạn C — Information Systems Architectures — được chia làm hai nhánh song song: Data Architecture (đã bàn ở Bài 15) và Application Architecture. Nhánh Application Architecture trả lời câu hỏi: doanh nghiệp cần những loại ứng dụng nào, và các ứng dụng đó tương tác với nhau ra sao, để hiện thực hoá các Business Capability (năng lực kinh doanh) đã xác định ở Giai đoạn B.

Application Portfolio Management (APM) là kỹ thuật cốt lõi để thực thi nhánh này ở cấp độ Baseline Architecture (kiến trúc hiện trạng). Về bản chất, APM là việc kiểm kê toàn diện (inventory) mọi ứng dụng doanh nghiệp đang thực sự sở hữu và vận hành — không chỉ những hệ thống "chính thức" nằm trong ngân sách IT, mà cả shadow IT, công cụ do phòng ban tự mua, script nội bộ đã trở thành phụ thuộc vận hành — rồi đánh giá từng ứng dụng theo hai trục độc lập:

1. Giá trị kinh doanh (Business Value) — ứng dụng này đóng góp bao nhiêu vào năng lực cạnh tranh, doanh thu, hoặc tuân thủ của tổ chức? Nó phục vụ Business Capability nào, và Capability đó có còn quan trọng chiến lược không?
2. Chất lượng kỹ thuật (Technical Quality/Fitness) — ứng dụng này có ổn định, dễ bảo trì, đáp ứng chuẩn bảo mật, có khả năng mở rộng không? Chi phí vận hành và rủi ro kỹ thuật (công nghệ lỗi thời, thiếu người hỗ trợ, không còn được vendor patch) ra sao?

Điểm khác biệt căn bản giữa APM và một bản kiểm kê tài sản CNTT thông thường: kiểm kê tài sản chỉ trả lời "chúng ta có gì", còn APM trả lời "chúng ta nên làm gì với từng thứ đang có." Đây là lý do APM luôn đi kèm một mô hình quyết định — phổ biến và được TOGAF cộng đồng thực hành rộng rãi nhất là mô hình TIME:

• Tolerate — giữ nguyên hiện trạng, không đầu tư thêm, chỉ vận hành tối thiểu để duy trì hoạt động.
• Invest — giá trị kinh doanh cao và còn tiềm năng tăng trưởng; tiếp tục đầu tư phát triển, mở rộng tính năng.
• Migrate — giá trị kinh doanh cao nhưng nền tảng kỹ thuật yếu, cần chuyển đổi sang nền tảng/kiến trúc mới để bảo toàn giá trị.
• Eliminate — giá trị kinh doanh thấp, chi phí/rủi ro kỹ thuật cao; lên kế hoạch loại bỏ hoặc hợp nhất vào hệ thống khác.

APM không phải là một hoạt động làm một lần rồi cất tủ. Vì mỗi lần ADM lặp lại một chu trình mới (quay lại Giai đoạn A sau Giai đoạn H), danh mục ứng dụng cũng cần được rà soát lại — công nghệ lỗi thời dần theo thời gian, và giá trị kinh doanh của một Capability có thể đổi chiều khi chiến lược doanh nghiệp thay đổi.

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

1. Ma trận đánh giá ứng dụng (Application Value/Quality Matrix)

Đây là artifact trung tâm của APM — một ma trận 2 trục, mỗi ứng dụng là một điểm dữ liệu, được đặt vào 1 trong 4 ô tương ứng với 4 hành động TIME:

Trục Giá trị kinh doanh thường được chấm điểm dựa trên các tiêu chí: mức độ hỗ trợ Business Capability cốt lõi/chiến lược, số người dùng và tần suất sử dụng, doanh thu/quy trình gắn liền, mức độ khác biệt hoá cạnh tranh (differentiator hay commodity).

Trục Chất lượng kỹ thuật thường chấm dựa trên: tuổi đời và mức độ end-of-life của công nghệ nền, chi phí vận hành/bảo trì hàng năm, mức độ nợ kỹ thuật, khả năng tích hợp (API-ready hay đóng kín), rủi ro bảo mật, và mức độ sẵn có nguồn lực hỗ trợ (còn ai biết sửa hệ thống này không).

Một điểm cần lưu ý về mặt phương pháp: điểm số trên hai trục nên được chấm bởi hai nhóm khác nhau — giá trị kinh doanh do đại diện Business (chủ sở hữu Capability) chấm, chất lượng kỹ thuật do đội kiến trúc/kỹ thuật chấm — rồi đối chiếu. Nếu để một nhóm tự chấm cả hai trục, kết quả dễ bị thiên lệch theo lợi ích cục bộ (ví dụ chủ sở hữu ứng dụng luôn có xu hướng đánh giá cao giá trị kinh doanh hệ thống của chính mình).

2. Ánh xạ ứng dụng vào Business Capability Model

Ma trận TIME cho biết nên làm gì với từng ứng dụng, nhưng để trả lời câu hỏi sâu hơn — tại sao tổ chức lại có nhiều ứng dụng trùng chức năng đến vậy, và có Capability nào đang thiếu hệ thống hỗ trợ — cần đặt danh mục ứng dụng lên trên Business Capability Model đã xây ở Giai đoạn B (Bài 14), tạo thành một Application-to-Capability Mapping (Catalog dạng ma trận, theo đúng tinh thần Catalog/Matrix của TOGAF — xem thêm Bài 24).

Cách đọc ma trận này để phát hiện vấn đề:

• Một Capability được nhiều ứng dụng cùng phục vụ → dấu hiệu trùng lặp chức năng (functional redundancy), là ứng viên hợp nhất (consolidation) — thường xảy ra sau M&A hoặc khi các phòng ban tự mua phần mềm độc lập nhiều năm.
• Một Capability quan trọng chiến lược nhưng không có ứng dụng nào phục vụ, hoặc chỉ được hỗ trợ thủ công (Excel, email) → khoảng trống (capability gap), là ứng viên đầu tư mới.
• Một ứng dụng phục vụ quá nhiều Capability không liên quan → dấu hiệu hệ thống "quái vật nguyên khối" (monolith sprawl), tăng rủi ro khi cần thay đổi hoặc tách hệ thống.

Ma trận Application-to-Capability chính là cầu nối kỹ thuật khiến quyết định TIME không còn là phán đoán cảm tính của riêng đội kiến trúc, mà có căn cứ trực tiếp từ bản đồ năng lực kinh doanh đã được thống nhất ở cấp chiến lược.

3. Chu kỳ rà soát định kỳ (Portfolio Review Cadence)

APM chỉ có giá trị khi được duy trì như một hoạt động sống, không phải một báo cáo một lần. Thực hành phổ biến: rà soát toàn diện danh mục theo chu kỳ 6-12 tháng (gắn với chu kỳ lặp ADM hoặc chu kỳ ngân sách), kết hợp rà soát nhẹ (light review) khi có sự kiện kích hoạt — sáp nhập, ra mắt sản phẩm mới, hoặc phát hiện shadow IT mới qua audit bảo mật.

Case thực tế minh hoạ

(Đây là minh hoạ điển hình tổng hợp từ các tình huống phổ biến trong thực hành APM, không phải case của một công ty cụ thể có thật — không nên coi bất kỳ số liệu nào trong phần này là thống kê chính xác.)

Một doanh nghiệp trong lĩnh vực phân phối, sau nhiều năm phát triển tổ chức mà không có phòng EA chính thức, lần đầu tiên thực hiện một đợt kiểm kê Application Portfolio đầy đủ theo yêu cầu của ban lãnh đạo mới nhằm cắt giảm chi phí vận hành CNTT. Đội kiến trúc kiểm kê ra một danh sách dài hơn dự kiến rất nhiều — bao gồm cả các hệ thống "chính thức" trong ngân sách IT lẫn một số công cụ nội bộ do các phòng ban tự triển khai từ nhiều năm trước.

Trong quá trình chấm điểm ma trận Value/Quality, nổi lên một trường hợp đáng chú ý: một hệ thống quản lý báo cáo nội bộ được xây dựng từ rất lâu, chạy trên nền tảng công nghệ đã ngừng được nhà cung cấp hỗ trợ chính thức, đòi hỏi một khoản chi phí bảo trì và vá lỗi bảo mật hàng năm không nhỏ — chủ yếu vì thiếu tài liệu kỹ thuật và phụ thuộc vào rất ít nhân sự còn hiểu rõ hệ thống. Khi đối chiếu với Business Capability Model, hệ thống này chỉ ánh xạ vào một Capability duy nhất — một dạng báo cáo tổng hợp nội bộ mà tổ chức xác định không còn nằm trong nhóm năng lực cốt lõi hay có tính khác biệt cạnh tranh, và trên thực tế phần lớn người dùng đã chuyển sang dùng công cụ báo cáo mới hơn cho phần lớn nhu cầu, chỉ còn một nhóm nhỏ vẫn dùng hệ thống cũ theo thói quen.

Đặt vào ma trận TIME, hệ thống này rơi thẳng vào ô Eliminate: giá trị kinh doanh thấp (Capability không còn quan trọng chiến lược, phần lớn nhu cầu đã có công cụ thay thế), chất lượng kỹ thuật thấp (nền tảng lỗi thời, chi phí bảo trì cao, rủi ro bảo mật). Quyết định được đưa ra là lập kế hoạch loại bỏ dần: di chuyển nhóm người dùng còn lại sang công cụ báo cáo hiện có, lưu trữ dữ liệu lịch sử cần thiết theo quy định, rồi ngừng vận hành hệ thống cũ theo lộ trình.

Kết quả không nằm ở một con số tiết kiệm cụ thể — điều đó khác nhau tuỳ tổ chức — mà ở việc tổ chức lần đầu tiên có căn cứ rõ ràng, dựa trên dữ liệu đối chiếu hai chiều (giá trị kinh doanh và chất lượng kỹ thuật), để đưa ra một quyết định loại bỏ mà trước đó không ai dám đề xuất chỉ vì "hệ thống vẫn đang chạy, thôi cứ để đó." Đây chính là giá trị cốt lõi mà APM mang lại: biến những quyết định vốn bị trì hoãn vô thời hạn vì thiếu căn cứ thành những quyết định có thể bảo vệ được trước ban lãnh đạo.

📐 Template/Artifact áp dụng ngay

Application Portfolio Assessment Catalog — dùng để kiểm kê và chấm điểm từng ứng dụng, là đầu vào trực tiếp cho ma trận TIME:

Quy tắc sử dụng:

• Điểm Giá trị và điểm Chất lượng phải được chấm độc lập bởi hai nhóm khác nhau (Business và Kiến trúc/Kỹ thuật) trước khi đối chiếu, tránh thiên lệch cục bộ.
• Ứng dụng rơi vào ô Eliminate hoặc Migrate cần một bản kế hoạch hành động riêng (migration path, timeline, rủi ro) trước khi trình phê duyệt ngân sách.
• Catalog này nên được đồng bộ định kỳ (6-12 tháng) và là đầu vào bắt buộc khi bước sang Giai đoạn D để xác định yêu cầu hạ tầng cho từng nhóm ứng dụng.

🎯 Góc nhìn Chief EA

Nếu phải cắt 20% ngân sách vận hành CNTT ngay tháng sau mà không được ảnh hưởng đến các Capability chiến lược, danh mục ứng dụng hiện tại có cho tôi đủ căn cứ để chỉ ra chính xác nên cắt ở đâu không?

Có bao nhiêu ứng dụng trong tổ chức tôi đang "Tolerate" chỉ vì không ai dám ký quyết định loại bỏ, chứ không phải vì nó thực sự còn giá trị?

Danh mục ứng dụng tôi đang có là một tài liệu sống được cập nhật định kỳ, hay là một bản kiểm kê làm một lần rồi không ai động vào nữa?

Khi một Capability kinh doanh thay đổi mức độ ưu tiên chiến lược, có cơ chế nào tự động cảnh báo tôi rằng các ứng dụng phục vụ Capability đó cũng cần được đánh giá lại vị trí trên ma trận TIME không?

🔄 Vị trí trong chu trình ADM

Application Portfolio Management diễn ra song song với Data Architecture trong Giai đoạn C của ADM. Hai nhánh này cùng thuộc Information Systems Architectures và bổ trợ lẫn nhau: trong khi Data Architecture (Bài 15) xác định luồng và mô hình dữ liệu, Application Architecture xác định các ứng dụng nào tạo ra, xử lý và tiêu thụ luồng dữ liệu đó.

• Nhận đầu vào từ: Business Capability Model (Bài 14) — danh mục ứng dụng chỉ có ý nghĩa chiến lược khi được ánh xạ vào các năng lực kinh doanh mà nó phục vụ; nếu không có Capability Model làm nền, việc chấm điểm "giá trị kinh doanh" của ứng dụng sẽ thiếu căn cứ khách quan.
• Cho đầu ra sang: Giai đoạn D (Bài 17) — danh mục ứng dụng đã phân loại theo TIME, cùng với quyết định Invest/Migrate/Eliminate cho từng ứng dụng, chính là căn cứ quyết định yêu cầu hạ tầng công nghệ cần thiết cho từng nhóm ứng dụng ở Giai đoạn Technology Architecture tiếp theo.

🔗 Bài viết liên quan

• Bài 14: Giai đoạn B (Business Capability Model)
• Bài 15: Giai đoạn C (Information Systems Architecture — Data)

Bài trước: Giai đoạn C (Information Systems Architecture) · Bài tiếp theo: Giai đoạn D (Technology)