Tích hợp hệ thống là việc nối các phần mềm riêng lẻ trong doanh nghiệp — bán hàng, kho, kế toán, nhân sự, website, sàn thương mại điện tử — để dữ liệu được nhập một lần và chảy tự động tới nơi cần dùng, thay vì nhân viên gõ lại hoặc xuất nhập bảng tính. Câu hỏi then chốt không phải "có nối được không" mà là "nối theo kiến trúc nào" vì kiến trúc quyết định chi phí khi số hệ thống tăng lên.
Có bốn kiến trúc chính: nối trực tiếp từng cặp (điểm–điểm), qua một trung tâm (hub and spoke), qua trục dịch vụ doanh nghiệp (ESB), và qua nền tảng tích hợp dạng dịch vụ đám mây (iPaaS); kiến trúc hướng sự kiện là lớp bổ sung ngày càng phổ biến. Doanh nghiệp dưới năm hệ thống thường ổn với điểm–điểm có kỷ luật; vượt mức đó, chi phí bảo trì tăng nhanh hơn số hệ thống và cần một lớp trung gian.
Vì sao tích hợp là bài toán kiến trúc, không chỉ là bài toán lập trình
Mỗi phần mềm được thiết kế quanh nghiệp vụ của nó và có mô hình dữ liệu riêng. Phần mềm bán hàng coi "khách hàng" là người mua lẻ có số điện thoại; phần mềm kế toán coi "khách hàng" là đối tượng công nợ có mã số thuế; CRM coi đó là một công ty có nhiều người liên hệ. Tích hợp không chỉ là chuyển dữ liệu mà là dịch nghĩa giữa các mô hình, và mỗi bản dịch là một quyết định nghiệp vụ.
Thêm vào đó là bài toán thời gian và độ tin cậy. Hệ thống A gửi đơn lúc hệ thống B đang bảo trì thì sao? Hai hệ thống cùng sửa một khách hàng trong một phút thì bản nào thắng? Mạng chập chờn làm một yêu cầu đến hai lần thì có tạo hai đơn không? Năm 2003, Gregor Hohpe và Bobby Woolf hệ thống hoá các lời giải cho những câu hỏi này trong cuốn Enterprise Integration Patterns, gồm 65 mẫu như kênh thông điệp, bộ định tuyến, bộ chuyển đổi, hàng đợi thư lỗi. Hơn hai mươi năm sau, phần lớn công cụ tích hợp hiện đại vẫn dùng chính bộ từ vựng ấy.
Vì vậy, chọn kiến trúc tích hợp giống chọn sơ đồ đường giao thông cho một khu công nghiệp: làm sai từ đầu thì mỗi nhà máy mới vào đều phải mở thêm đường riêng, và đến một lúc không ai dám sửa nút giao nào.
Điểm–điểm: rẻ lúc đầu, đắt về sau
Cách tự nhiên nhất là nối thẳng từng cặp phần mềm cần nói chuyện với nhau. Với hai ba hệ thống, đây là lựa chọn hợp lý: nhanh, rẻ, ít thành phần. Vấn đề nằm ở phép đếm. Nếu mọi hệ thống đều cần trao đổi với nhau, số kết nối là n(n−1)/2: năm hệ thống là 10 kết nối, mười hệ thống là 45. Thực tế không phải cặp nào cũng cần nối, nhưng xu hướng tăng nhanh hơn tuyến tính là có thật.
Hậu quả thường gặp có tên lóng là "kiến trúc mì sợi": logic chuyển đổi dữ liệu nằm rải rác trong từng kết nối, mỗi cái do một người hoặc một nhà thầu viết, mỗi cái ghi nhật ký một kiểu. Khi thay phần mềm kế toán, bạn phải sửa đồng thời mọi kết nối chạm vào nó, và thường không có danh sách đầy đủ những kết nối đó.
Điểm–điểm vẫn dùng được lâu dài nếu có kỷ luật: một danh mục tích hợp ghi rõ nguồn, đích, tần suất, người chịu trách nhiệm; chuẩn chung về nhật ký và cảnh báo; và quy tắc không cho hệ thống nào đọc thẳng cơ sở dữ liệu của hệ thống khác. Nhiều doanh nghiệp vừa ở Việt Nam vận hành ổn với sáu bảy kết nối được quản lý như vậy.
Hub and spoke và ESB: đưa logic về một trung tâm
Kiến trúc trung tâm (hub and spoke) đặt một phần mềm trung gian ở giữa. Mỗi hệ thống chỉ nối với trung tâm, trung tâm lo định tuyến và chuyển đổi. Số kết nối giảm về n, và thay một hệ thống chỉ cần sửa một đầu nối. Đây là lý do thế hệ phần mềm trung gian (middleware) tích hợp ứng dụng doanh nghiệp phát triển mạnh vào những năm 1990.
Trục dịch vụ doanh nghiệp (Enterprise Service Bus, ESB) là bước phát triển từ đầu những năm 2000, gắn với trào lưu kiến trúc hướng dịch vụ (SOA). Thay vì một trung tâm duy nhất, ESB là một lớp hạ tầng phân tán cung cấp chuyển đổi định dạng, định tuyến theo nội dung, đảm bảo giao nhận, bảo mật và giám sát. Ngân hàng, viễn thông, hãng hàng không — nơi có hàng chục hệ thống lõi và yêu cầu giao dịch nghiêm ngặt — là những người dùng điển hình.
Phê phán chính đối với ESB đến từ thực tế triển khai: trục trung tâm dần ôm quá nhiều logic nghiệp vụ, trở thành một khối nguyên khối mới mà chỉ một nhóm chuyên gia hiểu được, và mọi thay đổi phải xếp hàng chờ nhóm đó. Các nhà phê bình gọi hiện tượng này là "ống thông minh, đầu cuối ngốc" và đề xuất ngược lại: ống truyền đơn giản, logic nằm ở hai đầu. Đây cũng là một trong những lý do kiến trúc vi dịch vụ ra đời.
Bài học rút ra cho doanh nghiệp không phải "đừng dùng trung tâm tích hợp" mà là giữ trung tâm ở vai trò hạ tầng: vận chuyển, chuyển đổi định dạng, giám sát. Quy tắc nghiệp vụ như tính chiết khấu, phân loại khách hàng hay quyết định duyệt đơn nên nằm ở hệ thống nghiệp vụ làm chủ dữ liệu đó. Khi một quy tắc giá được viết trong lớp tích hợp, kế toán và kinh doanh sẽ không tìm thấy nó trong phần mềm mình dùng, và đến lúc kiểm toán hỏi vì sao một đơn được giảm giá, không ai trả lời được ngay.
iPaaS: tích hợp như một dịch vụ đám mây
Nền tảng tích hợp dạng dịch vụ (integration platform as a service, iPaaS) xuất hiện khoảng đầu thập niên 2010, khi doanh nghiệp chuyển sang dùng nhiều phần mềm dịch vụ (SaaS) chạy trên đám mây. Về bản chất, iPaaS là một trung tâm tích hợp do nhà cung cấp vận hành, đi kèm thư viện đầu nối dựng sẵn tới các phần mềm phổ biến, công cụ kéo thả để vẽ luồng dữ liệu, và hạ tầng giám sát.
Lợi ích rõ nhất là tốc độ: một luồng "đơn hàng mới trên sàn thương mại điện tử → tạo đơn trong phần mềm kho → tạo hoá đơn nháp trong kế toán" có thể dựng trong vài ngày nếu cả ba phần mềm đều có đầu nối sẵn. Doanh nghiệp không phải tự vận hành máy chủ tích hợp. Ở đầu thấp của phân khúc là các công cụ tự động hoá cho người không chuyên; ở đầu cao là các nền tảng có quản trị phiên bản, môi trường thử và kiểm soát truy cập chi tiết.
Giới hạn cần biết: đầu nối dựng sẵn thường chỉ phủ các thao tác phổ biến; phần mềm nội địa đặc thù có thể không có đầu nối; chi phí thường tính theo số luồng hoặc số lượt chạy nên tăng theo quy mô giao dịch; và logic tích hợp nằm trên nền tảng của bên thứ ba, nên đổi nhà cung cấp iPaaS cũng là một dự án. Dữ liệu đi qua máy chủ của bên thứ ba cũng đặt ra câu hỏi về bảo vệ dữ liệu cá nhân cần kiểm theo quy định hiện hành.
So sánh bốn kiến trúc theo tiêu chí ra quyết định
Bảng dưới đây tóm lược đặc điểm của từng kiến trúc theo các tiêu chí mà hội đồng chọn giải pháp thường cân nhắc. Mức đánh giá là định tính, mang tính tương đối giữa các phương án.
| Tiêu chí | Điểm–điểm | Hub / ESB | iPaaS | Hướng sự kiện |
|---|---|---|---|---|
| Chi phí khởi đầu | Thấp | Cao | Thấp đến vừa | Vừa đến cao |
| Chi phí khi thêm hệ thống | Tăng nhanh | Thấp | Thấp nếu có đầu nối | Thấp |
| Năng lực nội bộ cần có | Lập trình viên | Nhóm chuyên trách | Chuyên viên cấu hình | Kiến trúc sư và kỹ sư vận hành |
| Độ trễ dữ liệu | Tuỳ cách viết | Gần thời gian thực | Vài giây đến vài phút | Gần thời gian thực |
| Giám sát tập trung | Khó | Tốt | Tốt | Tốt nếu đầu tư |
| Rủi ro khoá chặt | Thấp | Cao với sản phẩm đóng | Vừa | Thấp với nền tảng mã nguồn mở |
| Phù hợp | Dưới năm hệ thống | Tổ chức lớn, giao dịch chặt | Doanh nghiệp dùng nhiều SaaS | Khối lượng sự kiện lớn, nhiều bên nhận |
Kiến trúc hướng sự kiện, trong đó hệ thống phát đi thông báo "đơn hàng đã tạo" và các bên quan tâm tự đăng ký nhận, không thay thế ba kiến trúc kia mà thường chạy song song. Nó giải quyết tốt bài toán một sự kiện cần đến nhiều nơi, nhưng đòi hỏi tư duy thiết kế khác về tính nhất quán dữ liệu.
Quy trình chọn kiến trúc tích hợp cho doanh nghiệp vừa
Quyết định kiến trúc nên dựa trên bản đồ luồng dữ liệu thật, không dựa trên sản phẩm đang được chào bán. Các bước sau giúp ra quyết định có căn cứ.
- Vẽ bản đồ hệ thống hiện tại: liệt kê mọi phần mềm, kể cả bảng tính dùng chung, và mọi luồng dữ liệu đang chạy bằng tay hoặc tự động giữa chúng.
- Xác định nguồn đúng cho từng loại dữ liệu: khách hàng, sản phẩm, giá, tồn kho, công nợ do hệ thống nào làm chủ; hệ thống khác chỉ được đọc hoặc đề xuất sửa.
- Phân loại luồng theo yêu cầu thời gian: luồng nào cần gần tức thời (tồn kho cho website), luồng nào chạy theo lô cuối ngày được (bút toán tổng hợp).
- Đếm và dự báo: số hệ thống trong ba năm tới, khối lượng giao dịch giờ cao điểm, số đối tác bên ngoài cần kết nối.
- Đánh giá năng lực nội bộ: có người duy trì được nền tảng không, hay cần dịch vụ vận hành sẵn.
- Chạy thử một luồng đại diện trên phương án ưu tiên, đo thời gian dựng, xử lý lỗi và chi phí thật trước khi cam kết cho toàn bộ.
Bước thứ hai thường chiếm nhiều thời gian họp nhất và cũng mang lại giá trị lớn nhất. Hai hệ thống cùng cho phép sửa giá bán là nguồn gốc của rất nhiều sai lệch mà không kiến trúc tích hợp nào tự sửa được.
Bước cuối cùng cũng quan trọng không kém: luồng đại diện nên là luồng có ngoại lệ thật, như đơn bị huỷ giữa chừng hay hàng trả lại, chứ không phải luồng đơn giản nhất. Một nền tảng trình diễn tốt với đơn hàng chuẩn nhưng lúng túng với đơn trả hàng sẽ bộc lộ điểm yếu ngay trong tuần thử, trước khi bạn ký hợp đồng nhiều năm.
Câu hỏi thường gặp
Middleware là gì, có phải là ESB không?
Middleware là tên gọi chung cho phần mềm nằm giữa các ứng dụng để giúp chúng giao tiếp: hàng đợi thông điệp, máy chủ ứng dụng, trung tâm tích hợp. ESB là một dạng middleware cụ thể với tập chức năng định tuyến, chuyển đổi và giám sát. Mọi ESB là middleware nhưng không phải middleware nào cũng là ESB.
Doanh nghiệp nhỏ có cần iPaaS không?
Nếu chỉ có hai ba phần mềm và chúng đã có kết nối dựng sẵn với nhau, chưa cần. iPaaS đáng cân nhắc khi bạn dùng từ bốn phần mềm SaaS trở lên, có nhân viên đang chép dữ liệu thủ công hằng ngày, và không có lập trình viên nội bộ để duy trì các kết nối tự viết.
ESB có lỗi thời không?
Không hẳn. Ở các tổ chức có nhiều hệ thống lõi tại chỗ và yêu cầu giao dịch chặt, ESB vẫn chạy ổn định. Điều thay đổi là ít dự án mới chọn ESB làm trung tâm duy nhất; xu hướng là kết hợp cổng API, iPaaS và nền tảng sự kiện, mỗi thứ cho đúng loại luồng.
Cổng API (API gateway) khác iPaaS thế nào?
Cổng API đứng trước các API để quản lý truy cập: xác thực, giới hạn tốc độ, ghi nhật ký, định tuyến. Nó không chuyển đổi dữ liệu hay điều phối luồng nghiệp vụ nhiều bước. iPaaS thì tập trung vào điều phối và chuyển đổi giữa các ứng dụng. Hai thứ thường bổ sung cho nhau.
Ai nên sở hữu các tích hợp trong doanh nghiệp?
Phần kỹ thuật nên có một đầu mối IT hoặc nhóm tích hợp chịu trách nhiệm vận hành. Phần nghiệp vụ, tức quy tắc ánh xạ và nguồn đúng của từng loại dữ liệu, cần chủ sở hữu ở phía bộ phận dùng dữ liệu. Thiếu một trong hai, sự cố sẽ bị đẩy qua lại.
Có nên để nhà cung cấp phần mềm tự làm tích hợp không?
Được, nếu hợp đồng ghi rõ phạm vi, tài liệu bàn giao, quyền sở hữu mã nguồn tích hợp và trách nhiệm bảo trì khi một trong hai phần mềm nâng cấp. Rủi ro lớn nhất là tích hợp nằm trong tay một nhà thầu mà doanh nghiệp không có tài liệu để người khác tiếp quản.