Cách đây chừng 10 năm, MDM là một xu hướng hot-hit trong ngành công nghệ, một định hướng mang tính chiến lược của nhiều công ty. Bây giờ MDM là cụm từ nhạy cảm, pha lẫn sự tiếc nuối và hổ thẹn của nhiều người.

Tại sao nên nỗi? Và đâu là hướng đi cho MDM?

Ý tưởng của MDM rất dễ hiểu: tập trung “tất cả” dữ liệu vào một chỗ, kết nối, sàng lọc xử lý sạch sẽ để cung cấp khi cần. Lợi ích của MDM là không thể bàn cãi, nó có thể đem lại sự thay đổi sâu rộng về sản phẩm dịch vụ lẫn mô hình hoạt động của doanh nghiệp.

Vì vậy ai cũng có thể có ý tưởng này, từ cấp lãnh đạo, đến trưởng bộ phận nghiệp vụ, đến các cấp IT.

Nhưng sự đời không như là mơ. Nếu nói MDM là mục đích cuối, thì chặng đường này phải trải qua một số giai đoạn sau:

– Giai đoạn lấy yêu cầu nghiệp vụ. Có một nghịch lý là thường chỉ có một: hoặc nghiệp vụ, hoặc IT là bên chủ động, bên còn lại thì cực kỳ thụ động. Ai đã từng trong cái chăn đó thì chắc sẽ hiểu có bao nhiêu loại rận trong thế lưỡng nan này.

– Giai đoạn lên kiến trúc, lựa chọn công nghệ, hãng (công cụ hỗ trợ tập hợp, tổ chức, phân loại, bảo mật, chính sách, phân tích…). Thật không may mắn là càng gần cuối thập niên đầu tiên của thế kỷ 21 thì càng ít hãng vỗ ngực nhận mình có công nghệ hỗ trợ MDM. Khi còn làm ở Oracle- một hãng dẫn đầu về xử lý dữ liệu, Middleware (platform, Service bus) và lớp Ứng dụng siêu mạnh (EBS, Siebel…) nên tôi cũng thường cũng rất hăng hái với các yêu cầu về MDM của khách hàng. Tuy nhiên kết quả chưa bao giờ khả quan. Một số khách hàng chấp nhận đầu tư pilot cho MDM cũng đều nhận quả đắng.

– Giai đoạn tập hợp và xử lý dữ liệu (sau khi đã chọn được công nghệ). Thực tế là công ty có nhu cầu MDM là công ty có dữ liệu từ nhiều nguồn, nhiều định dạng, nhiều công nghệ. Cho dù công nghệ có hỗ trợ đến đâu thì đây cũng là bước dễ thất bại nhất. Nó đòi hỏi trình cực cao của các CIO, CTO về khoa học công nghệ (cả sâu lẫn rộng, bao gồm cả sự cập nhật thường xuyên vì chỉ 2-3 là công nghệ đã thay đổi). Ngoài ra còn cần cả kỹ năng mềm để đi quan hệ, tìm sự hậu thuẫn của các bộ phận nghiệp vụ lẫn IT, đối tác và cấp lãnh đạo.

Quá trình này có thể phải lặp đi lặp lại vì chỉ cần Nghiệp vụ thay đổi thì dữ liệu đầu vào cũng thay đổi theo.

– Giai đoạn hái quả ngọt: thật ra tôi chưa gặp ai hái quả ngọt, chủ yếu là hái quả đắng, quả chua, quả chát. Nếu không phải Dự án nửa đường đứt gánh: lãnh đạo hết kiên nhẫn, hết kinh phí, phát sinh quá lớn, công nghệ không đáp ứng…Thì kết quả thì là nửa vời: dữ liệu tập trung một nửa, phải thủ công nhiều bước, chất lượng dữ liệu không đạt, hiệu suất quá kém (load dữ liệu chăm chẳng hạn)… Nói chung là thất bại.

Vậy đâu là tương lai của MDM?

Nếu ai đó xin tôi một lời khuyên, tôi sẽ nói thế này. Triển khai MDM giống như triển khai một cuộc họp có tất cả các phòng ban tham dự trong thời gian vô tận. Trong phòng họp, tất cả câu hỏi đều được trả lời nhanh nhất vì các phòng ban đều có mặt.

Tuy nhiên việc tập hợp này rất phức tạp, việc duy trì tất cả thành viên luôn có mặt còn phức tạp hơn. Vì vậy, thay vì luôn có mặt, chỉ cần đảm bảo “có mặt trong thời gian ngắn nhất”.

Dễ hiểu hơn, thay vì MDM, chúng ta có nhiều cách nhiều lựa chọn dễ thành công hơn: một giải pháp API point-to-point để kết nối dữ liệu không cần tập hợp, một khoá chính ở cấp độ cao hơn (Global ID hay universal ID) để mapping dữ liệu, hay chỉ đơn giản là tập hợp thành vài nhóm dữ liệu có liên quan rồi kết nối với nhau.

Không nên nhầm lẫn MDM với Data lake hay data warehouse, cũng không nên nhầm lẫn MDM với CDM hay CDP.

Nếu không phân biệt được các Khái niệm trên thì cũng không sao vì có sao thì cũng không biết phải làm sao.

Nam Nguyễn