TOGAF (The Open Group Architecture Framework) và Kiến trúc doanh nghiệp

1. Tổng quan

A. Định nghĩa

Kiến trúc doanh nghiệp (EA, Enterprise Architecture) là hệ thống thiết kế tổng hợp mô tả theo góc nhìn chuẩn hóa cấu trúc hiện tại (As-Is) và mục tiêu (To-Be) của nghiệp vụ·dữ liệu·ứng dụng·công nghệ nhằm gắn kết (alignment) chiến lược kinh doanh của tổ chức với nguồn lực IT, đồng thời quản lý lộ trình chuyển đổi giữa hai trạng thái đó. TOGAF là khung EA mở do The Open Group ban hành, cung cấp tổng thể phương pháp luận (ADM)·mô hình tham chiếu·hệ thống quản trị để phát triển·vận hành EA.

EA không phải bản thiết kế của một hệ thống cụ thể mà là "bản thiết kế tổng thể vẽ toàn bộ doanh nghiệp như một hệ thống". Ví với quy hoạch đô thị, nó không tương ứng với bản vẽ của từng tòa nhà (từng hệ thống thông tin) mà là quy hoạch tổng thể đô thị quy định đường sá·phân khu chức năng·cấp thoát nước. Do đó, giá trị cốt lõi của EA không nằm ở tối ưu cục bộ mà ở loại bỏ trùng lặp·chuẩn hóa·bảo đảm khả năng tương tác theo góc nhìn toàn doanh nghiệp.

TOGAF là phương pháp luận tiêu chuẩn ngành trên thực tế cho câu hỏi "xây dựng EA như thế nào". Nó mang tính mở, không phụ thuộc vào nhà cung cấp cụ thể, và có đặc điểm là phát triển kiến trúc từng bước xoay quanh quy trình lặp (iterative) ADM (Architecture Development Method).

B. Bối cảnh ra đời và sự cần thiết

Thứ nhất, do khoảng cách giữa IT và kinh doanh (business-IT gap). Khi các hệ thống được đặt hàng riêng lẻ theo từng phòng ban tích tụ lại, cùng một chức năng bị hiện thực trùng lặp ở nhiều hệ thống, định nghĩa dữ liệu mỗi nơi một kiểu khiến ngay cả thống kê toàn doanh nghiệp cũng lệch nhau, sinh ra cái gọi là 'silo'. Cần một tấm bản đồ để nắm bắt ở cấp toàn doanh nghiệp cái gì nằm ở đâu, và đây là động lực trực tiếp cho sự ra đời của EA.

Thứ hai là yêu cầu kiểm soát đầu tư và quản trị. Quy mô đầu tư IT càng lớn thì càng cần căn cứ để đánh giá "tại sao cần hệ thống này, có trùng lặp với tài sản hiện có không". EA cung cấp căn cứ đánh giá cho việc thẩm định đầu tư mới (Portfolio Management) bằng cách đưa ra danh mục tài sản hiện hành và cấu trúc mục tiêu. Hàn Quốc cũng từng bắt buộc các cơ quan công có quy mô nhất định trở lên phải áp dụng EA (chính phủ gọi là kiến trúc công nghệ thông tin, ITA) theo 「Luật Chính phủ điện tử」.

Thứ ba là tốc độ ứng phó với thay đổi. Khi các thay đổi toàn doanh nghiệp như chuyển đổi số·chuyển đổi cloud diễn ra thường xuyên, một tấm bản đồ cấu trúc giúp nhanh chóng xác định thay đổi lan tỏa đến nghiệp vụ·dữ liệu·hệ thống nào (phân tích tác động) đã trở nên thiết yếu. Khả năng truy vết (traceability) giữa các tầng của EA đáp ứng yêu cầu này.

2. Các góc nhìn cấu thành EA và so sánh các khung

EA thường gồm bốn miền kiến trúc (BDAT). Đây không phải phân loại đơn thuần mà tạo thành tầng nhân quả "kinh doanh làm gì → cần dữ liệu gì → ứng dụng nào xử lý dữ liệu đó → vận hành trên nền tảng công nghệ nào". Yêu cầu của tầng trên dẫn dắt thiết kế của tầng dưới, và nếu mắt xích này đứt thì sẽ sinh ra "hệ thống không ai dùng", "dữ liệu không có căn cứ".

graph TD
    B["Kiến trúc nghiệp vụ (BA)<br/>Chiến lược·Tổ chức·Quy trình·Chức năng"] --> D["Kiến trúc dữ liệu (DA)<br/>Mô hình dữ liệu·Tiêu chuẩn·Luồng"]
    D --> A["Kiến trúc ứng dụng (AA)<br/>Ứng dụng·Dịch vụ·Liên kết"]
    A --> T["Kiến trúc công nghệ (TA)<br/>Hạ tầng·Nền tảng·Mạng"]
    G["Quản trị EA (nguyên tắc·tiêu chuẩn·thẩm định)"] -.Quản lý·kiểm soát.-> B
    G -.Quản lý·kiểm soát.-> D
    G -.Quản lý·kiểm soát.-> A
    G -.Quản lý·kiểm soát.-> T

Kiến trúc nghiệp vụ (BA) định nghĩa chiến lược·mục tiêu·chức năng nghiệp vụ·quy trình của tổ chức. Đây là điểm khởi đầu của EA và là tầng trao tính chính danh cho mọi tầng khác; nếu không có mục đích "để thực hiện chức năng nghiệp vụ này" thì cả dữ liệu lẫn ứng dụng đều không có lý do tồn tại. Kiến trúc dữ liệu (DA) quy định mô hình dữ liệu logic·vật lý cần để hỗ trợ nghiệp vụ và tiêu chuẩn dữ liệu toàn doanh nghiệp, loại bỏ trùng lặp dữ liệu và bất nhất định nghĩa. Kiến trúc ứng dụng (AA) định nghĩa danh mục ứng dụng xử lý dữ liệu và quan hệ liên kết giữa chúng, là căn cứ để nhận diện các hệ thống trùng chức năng. Kiến trúc công nghệ (TA) xử lý các tiêu chuẩn phần cứng·phần mềm·mạng mà tất cả những thứ trên vận hành trên đó.

Có nhiều loại khung, mỗi loại có trọng tâm khác nhau. Điều quan trọng trong so sánh dưới đây không phải là "cái nào ưu việt hơn" mà là lựa chọn·kết hợp tùy theo mức độ trưởng thành và mục đích của tổ chức.

Nếu Zachman là khung phân loại "tài liệu hóa cái gì", thì TOGAF cung cấp quy trình "xây dựng như thế nào", nên hai khung bổ trợ cho nhau. Trong thực tiễn, cách kết hợp phổ biến là dùng Zachman để thiết lập hệ thống sản phẩm và vận hành quy trình phát triển bằng TOGAF ADM.

3. TOGAF ADM (Phương pháp phát triển kiến trúc)

Cốt lõi của TOGAF là quy trình phát triển dạng vòng lặp gọi là ADM. Nó không kết thúc một lần như mô hình thác nước mà đặt quản lý yêu cầu ở trung tâm, lặp lại từng giai đoạn để làm kiến trúc trưởng thành dần. Chính tính lặp này là yêu cầu cốt lõi của EA hiện đại, vốn phải ứng phó với thay đổi thường xuyên.

graph LR
    P["Giai đoạn sơ bộ<br/>Preliminary"] --> A["A. Tầm nhìn kiến trúc"]
    A --> B["B. Kiến trúc nghiệp vụ"]
    B --> C["C. Kiến trúc hệ thống thông tin<br/>(dữ liệu·ứng dụng)"]
    C --> D["D. Kiến trúc công nghệ"]
    D --> E["E. Cơ hội và giải pháp"]
    E --> F["F. Kế hoạch chuyển đổi"]
    F --> G["G. Quản trị triển khai"]
    G --> H["H. Quản lý thay đổi"]
    H --> A
    RM["Quản lý yêu cầu<br/>(vòng trung tâm)"] -.- A
    RM -.- B
    RM -.- C
    RM -.- D

Ở giai đoạn sơ bộ, chuẩn bị tổ chức·nguyên tắc·hệ thống quản trị để thực hiện EA. Ở giai đoạn A (tầm nhìn), thống nhất phạm vi·mục tiêu với các bên liên quan; ở giai đoạn B~D, định nghĩa As-Is và To-Be của từng miền nghiệp vụ·dữ liệu·ứng dụng·công nghệ và phân tích khoảng cách (gap) giữa chúng. Phân tích khoảng cách này là căn cứ cho việc sau đó sẽ xây mới hay loại bỏ cái gì.

Ở giai đoạn E (cơ hội và giải pháp), xác định các ứng viên triển khai để lấp khoảng cách, và ở giai đoạn F (kế hoạch chuyển đổi), sắp xếp chúng thành lộ trình theo mức ưu tiên·chi phí·rủi ro. Giai đoạn G (quản trị triển khai) kiểm soát việc các dự án triển khai thực tế có tuân thủ tiêu chuẩn kiến trúc hay không, còn giai đoạn H (quản lý thay đổi) đánh giá các yêu cầu thay đổi phát sinh trong vận hành rồi đưa vòng trở lại giai đoạn A. Ở trung tâm của toàn bộ quá trình là quản lý yêu cầu, liên kết hai chiều với mọi giai đoạn, nghĩa là yêu cầu phát sinh ở bất kỳ giai đoạn nào cũng được phản ánh·truy vết ngay lập tức.

Các tài sản thúc đẩy tái sử dụng ở đây là ACF (Architecture Content Framework) và chuỗi liên tục doanh nghiệp (Enterprise Continuum). Cái sau định nghĩa một phổ cụ thể hóa từ kiến trúc nền tảng (Foundation) mang tính tổng quát, qua kiến trúc chung của ngành, đến kiến trúc riêng của tổ chức, thúc đẩy việc tái sử dụng các kiến trúc tham chiếu đã được kiểm chứng.

4. Ví dụ áp dụng và mức độ trưởng thành EA

Một ví dụ áp dụng thực tế là tình huống một tổ chức tài chính vận hành khoảng 30 hệ thống core·thông tin·kênh được đặt hàng riêng lẻ theo từng phòng ban, khiến thông tin khách hàng được lưu khác nhau ở mỗi hệ thống và không thể tạo được góc nhìn khách hàng hợp nhất (Single View). Khi áp dụng EA để định nghĩa tiêu chuẩn dữ liệu toàn doanh nghiệp (định danh khách hàng·hệ thống mã) và nhận diện trùng lặp chức năng trong danh mục ứng dụng, tổ chức có thể giảm chi phí bảo trì nhờ hợp nhất các hệ thống trùng lặp và kìm hãm silo tái phát nhờ thẩm định tuân thủ tiêu chuẩn khi phát triển hệ thống mới. Điểm quan trọng ở đây không phải bản thân công nghệ mà là phải kết hợp tiêu chuẩn với quản trị thì hiệu quả mới bền vững.

Trong khu vực công của Hàn Quốc, theo 「Luật Chính phủ điện tử」 và 「Hướng dẫn kỹ thuật xây dựng·vận hành hệ thống thông tin」, một hệ thống đã được vận hành để quản lý tích hợp hiện trạng hệ thống thông tin giữa các bộ ngành và thẩm định trước đầu tư trùng lặp thông qua EA toàn chính phủ (như GEAP). Tuy nhiên, bài học chung là nếu tiếp cận EA chỉ như việc soạn sản phẩm tài liệu thì rất dễ trở thành "EA làm xong rồi để đó không dùng (shelf-ware)".

Tính hiệu quả thực tế của EA được quản lý bằng mức độ trưởng thành. Nó phát triển đại khái qua các bậc (1) ban đầu (có các sản phẩm riêng lẻ) → (2) quản lý (xây dựng tiêu chuẩn·kho lưu trữ toàn doanh nghiệp) → (3) định nghĩa (EA gắn với quy trình thẩm định đầu tư) → (4) tối ưu (tự cải tiến qua quản lý thay đổi·đo lường hiệu quả), và chỉ khi mức độ trưởng thành đạt từ bậc 3 trở lên và sản phẩm EA được dùng cho các quyết định thực tế thì hiệu quả so với đầu tư mới phát sinh.

5. Lưu ý và hàm ý

Từ góc nhìn của Kỹ sư chuyên nghiệp (Professional Engineer), việc áp dụng EA/TOGAF cần xem xét tổng hợp các điểm sau.

• Mục đích là quản trị chứ không phải tài liệu: Thành bại của EA không phụ thuộc vào mức hoàn thiện của sản phẩm mà vào việc nó có thực sự gắn với quy trình thẩm định đầu tư IT·quản lý thay đổi hay không. Nếu không có kho EA (Repository) và quy trình thẩm định thì EA sẽ trở thành văn bản chết. Ngay từ đầu phải thiết kế với mục tiêu "sử dụng cho ra quyết định" chứ không phải "soạn sản phẩm".

• Triển khai từng bước phù hợp mức độ trưởng thành (đánh đổi): Cách tiếp cận big-bang muốn hoàn thiện mọi miền trong một lần có rủi ro thất bại lớn. Thực tế hơn là tận dụng tính lặp của ADM để hoàn thiện mỏng (thin-slice) từ các lĩnh vực nghiệp vụ ưu tiên cao rồi mở rộng. Cân bằng giữa tính đầy đủ và tốc độ thực thi là mấu chốt.

• Gắn kết với các trào lưu kiến trúc mới nhất: Các xu hướng nhấn mạnh phân tán·tự chủ như cloud·MSA·data mesh có thể xung đột với việc chuẩn hóa tập trung của EA. Gần đây có xu hướng diễn giải lại EA không phải như kiểm soát từ trên xuống mà như quản trị tinh gọn chỉ đưa ra rào chắn (nguyên tắc·tiêu chuẩn) và bảo đảm quyền tự chủ của các đội, đồng thời duy trì tính cập nhật của sản phẩm kiến trúc bằng dạng mã (Architecture-as-Code)·thu thập tự động.

• Chuyển trọng tâm sang kiến trúc nghiệp vụ và năng lực (capability): EA gần đây đang dịch chuyển trọng tâm vượt ra khỏi việc lập danh mục tài sản công nghệ, hướng tới kết nối chiến lược-đầu tư dựa trên bản đồ năng lực kinh doanh. EA đang được nhìn nhận lại như công cụ chuyển dịch chiến lược chuyển đổi số·AX thành lộ trình thực thi, và Kỹ sư chuyên nghiệp cần góc nhìn định vị EA như hạ tầng thực thi chiến lược.

• Quan hệ với các chủ đề liên kết: EA gắn chặt với quản trị IT (COBIT), phân tích đầu tư IT·IT-ROI, ISP/ISMP và chuyển đổi số. Khi làm bài, nêu rõ quan hệ với các chủ đề này sẽ thể hiện được sự hiểu biết tích hợp.

Tóm tắt một câu: EA là hệ thống vẽ bản thiết kế IT toàn doanh nghiệp theo các tầng nghiệp vụ·dữ liệu·ứng dụng·công nghệ (BDAT) để loại bỏ trùng lặp và đạt được sự gắn kết, còn TOGAF là phương pháp luận tiêu chuẩn mở hiện thực hóa điều đó bằng quy trình lặp (ADM) và quản trị; thành bại được quyết định bởi việc sử dụng cho ra quyết định và gắn với quản trị chứ không phải tài liệu hóa.