EA – Cầu nối chiến lược và công nghệ: bài học và góc nhìn sau môn học

EA – Enterprise Architecture

Khi bắt đầu môn Kiến trúc Doanh nghiệp (Enterprise Architecture – EA), tôi đã nghĩ đây là một môn học khá hàn lâm, thiên về mô hình phức tạp và khung phương pháp khó áp dụng. Nhưng càng học, tôi càng nhận ra EA gần với thực tế doanh nghiệp hơn tôi từng nghĩ—thậm chí nhiều khái niệm tôi từng vô tình làm qua nhưng lúc đó không hề biết tên gọi hay ý nghĩa của chúng.

Điều đầu tiên tôi hiểu rõ là sự khác biệt giữa “xây hệ thống” và “xây kiến trúc”. Khi doanh nghiệp gặp vấn đề, phản xạ quen thuộc là: mua thêm phần mềm, chỉnh sửa quy trình, nâng cấp ứng dụng. Nhưng EA cho tôi thấy rằng những thứ đó chỉ giải quyết phần ngọn. Nếu không có kiến trúc tổng thể, mỗi hệ thống mới lại làm tăng độ rối, tăng trùng lặp và đẩy doanh nghiệp vào trạng thái khó quản trị hơn. Giống như một thành phố phát triển không có quy hoạch: nhìn thì lớn lên nhanh nhưng càng lớn càng lệch, càng phức tạp và càng nhiều mâu thuẫn.

ADM (Architecture Development Method) trong TOGAF10 lúc đầu có vẻ nặng nề, nhưng khi hiểu bản chất, tôi thấy đó là hành trình tự nhiên mà doanh nghiệp nào cũng cần đi: hiểu hiện trạng, xác định tương lai, phân tích khoảng cách, lập lộ trình thay đổi và quản trị yêu cầu xuyên suốt. Những phase như Business Architecture, Application Architecture, Data Architecture hay Technology Architecture,… không phải là lý thuyết xa vời; mỗi phần thực chất phản ánh chính những thứ đang tồn tại trong mọi doanh nghiệp.

Architecture Vision là phần khiến tôi ấn tượng nhất. Trước đây tôi nghĩ kiến trúc chắc phải rất nhiều tài liệu, rất nặng kỹ thuật. Nhưng Architecture Vision hóa ra lại chính là một bản mô tả ngắn gọn về tương lai doanh nghiệp muốn hướng đến—một bức tranh đủ rõ để tạo cảm hứng và để mọi người hiểu vì sao phải thay đổi. Khi hiểu tầm nhìn đó, tôi thấy mình tự tin hơn khi trao đổi với lãnh đạo, vì tôi hiểu “đích đến” là gì.

Business Architecture giúp tôi nhìn doanh nghiệp qua “business capabilities”—những năng lực nghiệp vụ cốt lõi. Trước đây khi một quy trình kéo dài, tôi chỉ nhìn thấy “quy trình rườm rà”. Nhưng giờ tôi hiểu vấn đề nằm ở năng lực: năng lực thẩm định, năng lực tích hợp dữ liệu, năng lực phê duyệt,… Khi nhìn theo năng lực, tôi thấy rõ phần nào mạnh, phần nào yếu, và công nghệ chỉ hữu ích khi được gắn vào đúng năng lực cần nâng cấp.

Application Architecture giúp tôi nhìn lại hệ thống doanh nghiệp bằng một góc nhìn rõ ràng và có trật tự hơn. Nếu trước đây tôi chỉ thấy “rất nhiều hệ thống” và thắc mắc vì sao chúng không kết nối được với nhau, thì giờ tôi hiểu nguyên nhân nằm ở kiến trúc ứng dụng. Application Architecture định nghĩa ứng dụng nào phục vụ năng lực nghiệp vụ nào, dữ liệu đi qua đâu và các hệ thống cần tích hợp với nhau theo cách nào. Khi doanh nghiệp có kiến trúc ứng dụng rõ ràng, các hệ thống không bị trùng chức năng, dữ liệu không bị phân tán và việc tích hợp trở nên dễ dàng, ổn định hơn.

Data Architecture cũng giúp tôi “tỉnh ra” nhiều điều. Trong Doanh nghiệp, dữ liệu khách hàng, dữ liệu giao dịch, dữ liệu báo cáo chảy ở nhiều hệ thống. Có lúc dữ liệu nơi này khác nơi kia mà không ai giải thích được. Trước đây tôi nghĩ đó là chuyện bình thường, nhưng học EA rồi tôi hiểu: đó là vấn đề về kiến trúc dữ liệu—thiếu master data, thiếu domain data, thiếu quy trình quản trị dữ liệu. Một doanh nghiệp muốn làm số hóa hay phân tích chuyên sâu phải bắt đầu từ dữ liệu có kiến trúc.

Technology Architecture giúp tôi nhìn rõ vai trò nền tảng công nghệ—phần ít ai “nhắc tên” nhưng ảnh hưởng mạnh nhất. Chỉ cần hệ thống gặp vấn đề tải, hàng trăm nghìn giao dịch có thể bị ảnh hưởng trong vài phút. Từ đó để thấy rằng khả năng mở rộng, bảo mật và tính liên tục của hạ tầng là nền để mọi ứng dụng phía trên vận hành trơn tru.

Trong EA, phần tôi thấy thực tế nhất là Transition Planning. Không tổ chức nào có thể thay đổi tất cả cùng lúc. Tôi từng làm dự án cố gắng “đổi mới toàn diện” chỉ trong một đợt, và kết quả là vướng mắc liên tục. Sau khi học EA, góc nhìn đã được thay đổi phải với việc chia nhỏ thành nhiều giai đoạn, ưu tiên những phần tạo giá trị nhanh và ít rủi ro trước—giống như sửa nhà thì phải sửa từng khu, không thể vừa đập tường vừa sinh hoạt bình thường.

Cuối cùng là Requirements Management—tinh thần cốt lõi xuyên suốt toàn bộ EA. Doanh nghiệp luôn thay đổi, nhu cầu nghiệp vụ luôn thay đổi, khách hàng luôn thay đổi; kiến trúc vì thế không thể đứng yên. Điều quan trọng không phải là thay đổi nhiều hay ít mà là thay đổi có kiểm soát, có đánh giá tác động và luôn bám sát tầm nhìn chung.

Khi nhìn lại công việc của mình, tôi nhận ra bản thân đã thay đổi cách tư duy. Khi nhận yêu cầu mới, tôi không còn nghĩ ngay đến giải pháp kỹ thuật. Tôi hỏi: Yêu cầu này thuộc năng lực nào? Ảnh hưởng đến dữ liệu không? Có trùng với hệ thống nào? Có lệch với lộ trình kiến trúc không? Rất nhiều câu hỏi được đặt ra để hình dung được kiến trúc và nhờ vậy, tôi đưa ra quyết định chín chắn hơn và tránh được nhiều sai sót trước kia.

Môn EA dạy tôi rằng chuyển đổi số không bắt đầu từ công nghệ, mà bắt đầu từ kiến trúc. Và kiến trúc là thứ giúp doanh nghiệp ổn định, linh hoạt và phát triển bền vững. Với tôi, giá trị lớn nhất của môn học chính là tư duy: tư duy logic, tư duy tổng thể, tư duy dài hạn.

Môn học kết thúc, nhưng tôi biết EA sẽ đồng hành cùng mình rất lâu. Đây không chỉ là kiến thức trong giáo trình mà sẽ trở thành một phần trong cách tôi phân tích, nhìn nhận và ra quyết định trong công việc hằng ngày. Và tôi tin rằng, đây mới chỉ là điểm bắt đầu cho hành trình tư duy mới mà EA đã mở ra cho tôi.

Tham khảo & đọc thêm

• The TOGAF Standard – The Open Group — trang chính thức của bộ chuẩn TOGAF và phương pháp ADM, điểm khởi đầu tốt khi học enterprise architecture.
• Tính nhất quán và vai trò cầu nối chiến lược: điều tôi học từ EA — một góc nhìn khác của học viên về EA như cầu nối giữa chiến lược và công nghệ.
• Kiến trúc doanh nghiệp cho founder: 4 bước lập bản quy hoạch — áp dụng kiến trúc doanh nghiệp cho doanh nghiệp vừa và nhỏ.
• Chuyển đổi số là gì và chiến lược chuyển đổi số — bức tranh lớn về chuyển đổi số mà kiến trúc doanh nghiệp phục vụ.

VỀ TÁC GIẢ

Hoàng Gia Quốc

Team Leader · TPBank

Hạt giống mùa 9 · Hà Nội · Trợ giảng mùa 10 · Ban huấn luyện ITSM

Xem hồ sơ thành viên →

Nguồn: Digital Leaders Publishing Club — bài gốc (tác giả: Hoàng Gia Quốc — @quoc0407). Bản quyền thuộc tác giả gốc.