title: "Interoperability: Thiết kế sự kết nối giữa các hệ thống không cùng nền tảng"
series: "TOGAF Mastery: Kiến trúc sư Doanh nghiệp Chuyên sâu"
part: "Phần 3 — Kỹ thuật thiết kế & Mô hình hóa (Modeling & Artifacts)"
order: 29
audience: "Enterprise Architect (EA) & Solutions Architect hướng EA"
reading_time: "12 phút"
tags:

• TOGAF
• Interoperability
• Integration Architecture
• API Gateway
• Enterprise Service Bus
• Enterprise Architecture

Interoperability: Thiết kế sự kết nối giữa các hệ thống không cùng nền tảng

Có một câu hỏi tưởng đơn giản mà rất nhiều EA lúng túng khi CIO hỏi thẳng: "Nếu tôi thay hệ thống CRM tuần sau, có bao nhiêu hệ thống khác bị ảnh hưởng?" Câu trả lời thành thật ở phần lớn doanh nghiệp là: không ai biết chắc. Có một file Excel liệt kê "các API đang dùng", nhưng nó lỗi thời từ hai năm trước. Đội ngũ vận hành thì nhớ mang máng "hình như ERP có gọi sang, hình như có một job Cron kéo dữ liệu mỗi đêm, hình như bên kế toán còn export CSV thủ công". Không ai vẽ được bức tranh đầy đủ.

Đây không phải là vấn đề công nghệ. Đây là hậu quả của việc tích hợp được xây theo kiểu phản ứng — hệ thống A cần dữ liệu từ hệ thống B, đội dev viết một API call trực tiếp, xong. Sáu tháng sau, hệ thống C cũng cần dữ liệu tương tự, một API call khác ra đời. Ba năm sau, doanh nghiệp có hàng chục, hàng trăm kết nối điểm-tới-điểm (point-to-point) chồng chéo, không tài liệu, không chuẩn hoá, không ai dám đụng vào vì sợ đứt một sợi dây nào đó. Giới kiến trúc gọi hiện tượng này bằng một cái tên rất hình tượng: "spaghetti integration" — một bát mì Ý mà mỗi sợi là một tích hợp, quấn vào nhau đến mức không còn phân biệt được đâu là đầu, đâu là cuối.

Interoperability — năng lực để các hệ thống khác nền tảng, khác công nghệ, khác thời kỳ ra đời vẫn giao tiếp được với nhau một cách có kiểm soát — không phải là một tính năng kỹ thuật đơn lẻ. Nó là một năng lực kiến trúc (architectural capability) mà một Chief EA phải chủ động thiết kế, quản trị và bảo vệ, vì nếu để nó phát triển tự nhiên, kết quả gần như luôn luôn là spaghetti integration.

Bản chất

Trong TOGAF, interoperability xuất hiện xuyên suốt các giai đoạn C (Information Systems Architecture) và D (Technology Architecture) của ADM (Architecture Development Method — phương pháp phát triển kiến trúc theo chu trình lặp của TOGAF), nhưng bản chất của nó vượt ra khỏi phạm vi một giai đoạn — nó là một thuộc tính xuyên suốt (cross-cutting concern) của toàn bộ landscape doanh nghiệp.

Nhầm lẫn phổ biến nhất: coi interoperability đơn thuần là "có API là xong". Thực tế, khả năng kết nối được về mặt kỹ thuật chỉ là điều kiện cần, hoàn toàn chưa đủ. TOGAF (thường được đối chiếu với các mô hình interoperability như LISI — Levels of Information Systems Interoperability, hay khung của European Interoperability Framework) phân interoperability thành ba tầng, và một EA giỏi phải đánh giá được cả ba, không dừng ở tầng đầu tiên:

Tầng kỹ thuật (Technical Interoperability) — hai hệ thống có thể kết nối, trao đổi gói tin, giao thức khớp nhau (REST/JSON, SOAP/XML, gRPC, message queue...). Đây là tầng dễ đo nhất và cũng là tầng mà đa số đội kỹ thuật dừng lại: "API gọi được, trả về 200 OK, xong việc."

Tầng ngữ nghĩa (Semantic Interoperability) — dữ liệu trao đổi được hiểu đúng nghĩa như nhau ở cả hai đầu. Đây là tầng gây ra phần lớn lỗi âm thầm và tốn kém nhất trong thực tế. Ví dụ kinh điển: hệ thống CRM định nghĩa "khách hàng active" là có giao dịch trong 90 ngày gần nhất; hệ thống billing định nghĩa "active" là hợp đồng chưa hết hạn. Cả hai đều trả về field tên status: active — API vẫn "hoạt động tốt" ở tầng kỹ thuật, nhưng báo cáo doanh thu và báo cáo churn sẽ lệch nhau, và không ai phát hiện ra cho đến khi có audit.

Tầng tổ chức (Organizational Interoperability) — các quy trình nghiệp vụ đứng sau hệ thống có phối hợp được với nhau không. Hai hệ thống có thể trao đổi dữ liệu hoàn hảo cả về kỹ thuật lẫn ngữ nghĩa, nhưng nếu quy trình duyệt đơn hàng của phòng Sales và quy trình ghi nhận công nợ của phòng Kế toán chạy theo hai nhịp độ khác nhau (Sales chốt đơn tức thời, Kế toán đối soát cuối tuần), thì dữ liệu vẫn "đúng" về mặt hệ thống nhưng gây lệch pha nghiệp vụ thực tế — tồn kho ảo, công nợ trễ, khách hàng nhận thông báo sai.

Một Chief EA khi review bất kỳ đề xuất tích hợp nào cũng cần tự hỏi cả ba câu, không chỉ câu đầu. Phần lớn thất bại tích hợp trong thực tế không nằm ở tầng kỹ thuật — nằm ở chỗ không ai đặt câu hỏi về tầng ngữ nghĩa và tổ chức trước khi bắt tay code.

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

Nguyên tắc cốt lõi: tầng tích hợp trung gian thay vì điểm-tới-điểm

Nguyên tắc kiến trúc quan trọng nhất của interoperability, cũng là nguyên tắc mà TOGAF nhấn mạnh xuyên suốt Technology Architecture, là: khi số lượng hệ thống cần giao tiếp với nhau vượt quá một ngưỡng nhỏ (thường là 3-4 hệ thống trở lên), phải chuyển từ mô hình tích hợp điểm-tới-điểm sang mô hình có một tầng tích hợp trung gian (integration layer).

Lý do là toán học đơn giản: với N hệ thống tích hợp điểm-tới-điểm, số lượng kết nối tối đa tăng theo cấp N×(N-1)/2 — 5 hệ thống có thể phát sinh tới 10 kết nối, 10 hệ thống có thể phát sinh tới 45 kết nối. Mỗi kết nối là một điểm lỗi tiềm ẩn, một hợp đồng ngầm (implicit contract) không ai kiểm soát, và một rào cản khi muốn thay thế bất kỳ hệ thống nào trong mạng lưới. Với tầng tích hợp trung gian, mỗi hệ thống chỉ cần biết "nói chuyện" với một điểm duy nhất — số kết nối tăng tuyến tính theo N, không phải theo cấp N².

Tầng tích hợp trung gian có thể hiện thực bằng nhiều công nghệ tuỳ quy mô và bối cảnh — không có một đáp án đúng duy nhất, EA cần chọn dựa trên đặc điểm luồng dữ liệu:

• API Gateway — phù hợp khi giao tiếp chủ yếu là synchronous request/response (hệ thống A cần dữ liệu tức thời từ hệ thống B). Đóng vai trò là điểm vào duy nhất, xử lý authentication, rate limiting, versioning, routing.
• Enterprise Service Bus (ESB) / Message Broker (RabbitMQ, Kafka...) — phù hợp khi giao tiếp là asynchronous, event-driven, cần decouple thời gian thực giữa bên gửi và bên nhận, hoặc cần broadcast một sự kiện tới nhiều hệ thống cùng lúc mà bên gửi không cần biết ai đang lắng nghe.
• Enterprise Integration Hub / iPaaS — phù hợp với các tổ chức có nhiều hệ thống SaaS mua ngoài, cần orchestrate luồng nghiệp vụ phức tạp giữa các hệ thống không thể tuỳ biến sâu.
• Data Integration Layer / CDC (Change Data Capture) — phù hợp khi bài toán chính là đồng bộ dữ liệu (không phải gọi hành vi), ví dụ đẩy dữ liệu vào một kho dữ liệu tập trung để các hệ thống phân tích cùng đọc thay vì mỗi hệ thống tự kéo từ nguồn.

Nguyên tắc thứ hai, thường bị bỏ qua: tầng tích hợp trung gian không chỉ là công nghệ, nó phải đi kèm một Interface Catalog — danh mục tất cả các điểm tích hợp đang tồn tại, ai sở hữu, contract là gì, tầng nào (kỹ thuật/ngữ nghĩa/tổ chức) đã được xác nhận. Đây chính là loại Catalog artifact mà TOGAF khuyến nghị duy trì trong Architecture Repository — không có nó, tầng tích hợp trung gian về công nghệ vẫn tồn tại nhưng về quản trị thì vẫn mù mờ như cũ.

Nguyên tắc thứ ba: chuẩn hoá hợp đồng dữ liệu (data contract) tại tầng ngữ nghĩa trước khi tầng kỹ thuật được xây. Một Canonical Data Model — mô hình dữ liệu chuẩn hoá dùng chung cho các thực thể cốt lõi (Customer, Order, Product...) — giúp mỗi hệ thống chỉ cần map dữ liệu của mình vào/ra khỏi mô hình chuẩn một lần, thay vì phải hiểu định dạng riêng của từng hệ thống đối tá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 công ty cụ thể, không có số liệu thật.)

Một doanh nghiệp bán lẻ đa kênh, sau nhiều năm tăng trưởng qua các đợt mua lại và triển khai rời rạc, có trong tay: một hệ thống ERP lõi, một CRM riêng cho đội sales, một nền tảng e-commerce mua ngoài, một hệ thống quản lý kho (WMS) do đối tác vận hành, và vài chục công cụ báo cáo/marketing tự động do các phòng ban tự mua theo nhu cầu riêng. Không có bản đồ tích hợp chính thức nào được duy trì.

Khi đội kiến trúc bắt đầu rà soát (thông qua Architecture Repository và phỏng vấn từng phòng ban), họ phát hiện gần năm mươi kết nối điểm-tới-điểm đang chạy ngầm: e-commerce gọi trực tiếp API của ERP để lấy tồn kho; CRM có một job đêm kéo dữ liệu đơn hàng từ database ERP bằng kết nối trực tiếp (không qua API, đọc thẳng bảng); công cụ marketing tự động export CSV thủ công từ CRM rồi upload lên nền tảng email; WMS gửi webhook về cả ERP lẫn e-commerce riêng biệt cho cùng một sự kiện "đã xuất kho", với hai định dạng payload khác nhau.

Hậu quả cụ thể: mỗi lần ERP cần nâng cấp phiên bản, đội hạ tầng phải dành nhiều tuần chỉ để dò xem có bao nhiêu kết nối ẩn sẽ bị ảnh hưởng, vì kết nối đọc thẳng database không hề xuất hiện trong bất kỳ tài liệu API nào. Có ít nhất hai lần dữ liệu tồn kho lệch giữa e-commerce và WMS do hai bên hiểu khác nhau về thời điểm một đơn hàng được coi là "đã trừ kho" — một lỗi ở tầng ngữ nghĩa chứ không phải lỗi kỹ thuật.

Đội EA đề xuất và triển khai một tầng tích hợp trung gian gồm API Gateway cho các luồng đồng bộ (đọc tồn kho, tra cứu khách hàng) và một Message Broker cho các luồng sự kiện bất đồng bộ (đơn hàng tạo mới, xuất kho, cập nhật tồn kho). Song song, họ định nghĩa một Canonical Data Model cho các thực thể cốt lõi (Customer, Order, Product, Inventory) và yêu cầu mọi hệ thống mới hoặc được nâng cấp phải map qua mô hình chuẩn này thay vì tích hợp trực tiếp với hệ thống khác.

Quá trình chuyển đổi không làm trong một lần — các kết nối điểm-tới-điểm cũ được thay thế dần theo từng đợt, ưu tiên những kết nối rủi ro cao nhất trước (đọc thẳng database, không có versioning). Kết quả sau giai đoạn tái cấu trúc: số điểm tích hợp cần quản lý giảm đáng kể vì nhiều luồng dữ liệu trùng lặp được hợp nhất qua một kênh chung; quan trọng hơn, đội hạ tầng có thể ước lượng được tác động khi thay đổi một hệ thống chỉ bằng cách tra cứu Interface Catalog, thay vì phải phỏng vấn từng phòng ban như trước.

📐 Template/Artifact áp dụng ngay

Interface Catalog — bảng chuẩn TOGAF-style để kiểm kê và quản trị toàn bộ điểm tích hợp trong landscape. Đây là bước đầu tiên bắt buộc trước khi thiết kế bất kỳ tầng tích hợp trung gian nào — không kiểm kê được hiện trạng thì không tái cấu trúc được.

Nguyên tắc dùng bảng: mọi kết nối mới trước khi triển khai phải được đăng ký vào catalog này và trả lời được cả ba cột "tầng đã xác nhận" — nếu chỉ tick được cột kỹ thuật mà bỏ trống ngữ nghĩa/tổ chức, đó là tín hiệu cảnh báo cần review thêm trước khi go-live.

🎯 Góc nhìn Chief EA

• Nếu ngày mai tôi phải thay thế một hệ thống bất kỳ trong landscape, tôi có thể tra cứu chính xác nó đang kết nối với bao nhiêu hệ thống khác, hay tôi sẽ phải triệu tập họp toàn công ty để dò tìm?
• Có bao nhiêu điểm tích hợp trong tổ chức tôi đang là point-to-point "tạm thời" mà thực ra đã tồn tại nhiều năm?
• Khi hai hệ thống trao đổi một trường dữ liệu cùng tên, tôi có chắc cả hai bên hiểu đúng cùng một nghĩa, hay tôi đang giả định điều đó?
• Interface Catalog của tổ chức tôi có phải tài liệu sống được cập nhật mỗi khi có tích hợp mới, hay là một file đã lỗi thời từ lần audit gần nhất?

🔗 Bài viết liên quan

• Giai đoạn C (Application Portfolio) — bức tranh toàn cảnh các ứng dụng là nền tảng để xây Interface Catalog chính xác.
• Catalog, Matrix, Diagram — nền tảng phương pháp luận để xây các artifact dạng bảng như Interface Catalog trong bài này.

Bài trước: Kiến trúc bảo mật (Security Architecture) · Bài tiếp theo: Architecture Artifacts