EA – TỪ MÔ HÌNH HÀN LÂM ĐẾN TƯ DUY QUY HOẠCH DOANH NGHIỆP

Khi bắt đầu môn Kiến trúc Doanh nghiệp (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.

EA: Giải Quyết Tận Gốc, Không Chỉ Phần Ngọn

Đ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 và Bốn Lớp Kiến Trúc: Hành Trình Tự Nhiên Của Doanh Nghiệp

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.

• Architecture Vision (Tầm nhìn Kiến trúc): Là phần khiến tôi ấn tượng nhất. Đây 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.

• Business Architecture (Kiến trúc Nghiệp vụ): 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. 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 (Kiến trúc Ứng dụng): Đị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 có kiến trúc 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.

• Data Architecture (Kiến trúc Dữ liệu): Giúp tôi “tỉnh ra” nhiều điều. Vấn đề dữ liệu không nhất quán 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ị. Một doanh nghiệp muốn làm số hóa phải bắt đầu từ dữ liệu có kiến trúc.

• Technology Architecture (Kiến trúc Công nghệ): 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 đến khả năng mở rộng, bảo mật và tính liên tục.

Transition Planning và Quản Trị Yêu Cầu: Chuyển Đổi Thực Tế

Phần tôi thấy thực tế nhất là Transition Planning (Lập kế hoạch Chuyển đổi). Không tổ chức nào có thể thay đổi tất cả cùng lúc. Góc nhìn EA thay đổi cách tiếp cận của tôi từ “đổi mới toàn diện” sang 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.

Cuối cùng là Requirements Management (Quản trị Yêu cầu)—tinh thần cốt lõi xuyên suốt toàn bộ EA. Kiến trúc không thể đứng yên. Điều quan trọng 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.

EA: Giá Trị Lớn Nhất Là Tư Duy

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ó lệch với lộ trình kiến trúc không?

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 tin EA sẽ đồng hành cùng mình rất lâu. Đây mới chỉ là điểm bắt đầu cho hành trình tư duy mới mà EA đã mở ra.

Hoàng Gia Quốc – SS09HN

VỀ TÁC GIẢ

Hoàng Gia Quốc

Team Leader · TPBank

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