Kiến trúc công nghệ doanh nghiệp được tổ chức như thế nào?

Một cách tổ chức phổ biến là nhìn doanh nghiệp qua các miền Business, Data, Application và Technology. Đây cũng là cách phân chia được sử dụng trong TOGAF Standard để mô tả các miền chính của kiến trúc doanh nghiệp. Trong thực tế, các miền này không vận hành riêng biệt: yêu cầu nghiệp vụ định hướng dữ liệu và ứng dụng; ứng dụng sử dụng hạ tầng công nghệ; còn bảo mật, tích hợp, quản trị và tiêu chuẩn kỹ thuật tác động xuyên suốt toàn bộ cấu trúc.

Vì vậy, kiến trúc không nên được hiểu như một mô hình xếp tầng cứng nhắc. Các lớp chủ yếu tạo ra một cách nhìn có cấu trúc để doanh nghiệp kiểm soát quan hệ phụ thuộc và tác động thay đổi.

Cấu trúc kiến trúc đi từ nhu cầu nghiệp vụ đến nền tảng công nghệ

Ở mức khái quát, kiến trúc có thể được đọc theo chuỗi:

Năng lực và quy trình nghiệp vụ → dữ liệu → ứng dụng → nền tảng công nghệ

Chuỗi này thể hiện quan hệ hỗ trợ, không có nghĩa mỗi lớp chỉ giao tiếp với lớp nằm ngay bên cạnh.

Lớp nghiệp vụ xác định doanh nghiệp cần thực hiện những năng lực nào. Các năng lực đó tạo ra yêu cầu đối với thông tin và dữ liệu. Dữ liệu được tạo, xử lý hoặc cung cấp thông qua các ứng dụng. Ứng dụng lại cần môi trường tính toán, mạng, lưu trữ, nền tảng tích hợp và các dịch vụ kỹ thuật để hoạt động.

Ví dụ, một năng lực xử lý đơn hàng có thể cần dữ liệu khách hàng, sản phẩm, tồn kho và thanh toán. Những dữ liệu này được sử dụng bởi hệ thống thương mại điện tử, ERP hoặc các dịch vụ chuyên biệt. Các hệ thống tiếp tục phụ thuộc vào cơ sở dữ liệu, API, nền tảng cloud, mạng và cơ chế quản lý danh tính.

Nhìn theo chuỗi như vậy giúp trả lời một câu hỏi quan trọng của kiến trúc: nếu một thành phần thay đổi, những thành phần nào phía trên hoặc phía dưới sẽ bị ảnh hưởng?

Giới hạn của cách nhìn theo lớp là nó dễ tạo cảm giác hệ thống vận hành một chiều. Thực tế có nhiều quan hệ ngang giữa các ứng dụng, nhiều nguồn dữ liệu dùng chung và nhiều nền tảng kỹ thuật phục vụ đồng thời hàng chục hoặc hàng trăm hệ thống. Vì thế, cấu trúc lớp phải luôn đi kèm bản đồ quan hệ.

Lớp nghiệp vụ xác định công nghệ phải phục vụ điều gì

Lớp nghiệp vụ là điểm xuất phát để giải thích tại sao một thành phần công nghệ tồn tại. Nó mô tả những yếu tố như năng lực kinh doanh, quy trình, vai trò tổ chức và các dịch vụ mà doanh nghiệp cần cung cấp.

Chẳng hạn, “quản lý quan hệ khách hàng” là một năng lực nghiệp vụ. CRM chỉ là một hoặc nhiều giải pháp công nghệ được sử dụng để thực hiện năng lực đó. Nếu bắt đầu kiến trúc từ tên sản phẩm như CRM, ERP hay một nền tảng cloud, doanh nghiệp rất dễ đồng nhất kiến trúc với danh mục sản phẩm đang sở hữu.

Quan hệ từ nghiệp vụ xuống công nghệ thường được hình thành theo logic:

Mục tiêu kinh doanh → năng lực cần có → quy trình thực hiện → thông tin cần sử dụng → ứng dụng hỗ trợ → công nghệ vận hành

Cơ chế này tạo khả năng truy vết. Khi doanh nghiệp cân nhắc loại bỏ một hệ thống, kiến trúc sư có thể kiểm tra hệ thống đó đang hỗ trợ những năng lực và quy trình nào thay vì chỉ đánh giá tuổi đời kỹ thuật của nó.

Ngược lại, nếu một mục tiêu chiến lược mới không thể truy xuống các năng lực, ứng dụng và nền tảng cần thiết, doanh nghiệp có thể nhận ra khoảng trống công nghệ trước khi triển khai.

Lớp nghiệp vụ vì thế không có nhiệm vụ mô tả chi tiết cách máy chủ, cơ sở dữ liệu hay API hoạt động. Vai trò của nó là tạo căn cứ để xác định công nghệ nào cần tồn tại và tồn tại để làm gì.

Dữ liệu và ứng dụng chuyển nhu cầu kinh doanh thành năng lực số

Giữa nghiệp vụ và hạ tầng là hai miền có quan hệ đặc biệt chặt chẽ: dữ liệu và ứng dụng.

Kiến trúc dữ liệu xác định những đối tượng thông tin quan trọng của doanh nghiệp, nơi dữ liệu được tạo ra, nơi dữ liệu được lưu giữ, cách dữ liệu được chia sẻ và trách nhiệm quản lý dữ liệu. Các đối tượng điển hình có thể là khách hàng, sản phẩm, hợp đồng, đơn hàng hoặc giao dịch.

Kiến trúc ứng dụng xác định những hệ thống hoặc dịch vụ phần mềm thực hiện các chức năng cần thiết và cách chúng tương tác.

Hai miền này không nên được thiết kế độc lập. Một ứng dụng có thể vừa tạo dữ liệu vừa tiêu thụ dữ liệu của hệ thống khác. Nếu không xác định quyền sở hữu và luồng dữ liệu, nhiều hệ thống có thể duy trì những phiên bản khác nhau của cùng một thông tin.

Ví dụ, nếu CRM, ERP và nền tảng thương mại điện tử đều lưu hồ sơ khách hàng nhưng không có quy tắc xác định nguồn dữ liệu chuẩn, việc tích hợp ba hệ thống chỉ giải quyết đường truyền dữ liệu chứ chưa giải quyết được tính nhất quán.

Các mối liên kết thường cần làm rõ gồm:

·         Ứng dụng nào sở hữu hoặc tạo dữ liệu

·         Ứng dụng nào tiêu thụ dữ liệu

·         Dữ liệu được trao đổi qua API, sự kiện, tệp hay cơ chế khác

·         Thành phần nào phụ thuộc vào dữ liệu hoặc dịch vụ của thành phần khác

·         Điều gì xảy ra khi nguồn dữ liệu hoặc giao diện thay đổi

Do đó, bản đồ ứng dụng có giá trị hơn một danh sách phần mềm khi nó biểu diễn được dependency, interface và data flow giữa các thành phần.

Lớp công nghệ cung cấp môi trường để ứng dụng vận hành

Lớp công nghệ là phần gần nhất với hạ tầng kỹ thuật. Nó bao gồm các nền tảng và dịch vụ cần thiết để triển khai, kết nối và vận hành ứng dụng, chẳng hạn như năng lực tính toán, lưu trữ, mạng, cơ sở dữ liệu, middleware, nền tảng cloud, container, dịch vụ tích hợp và quản lý danh tính.

Vai trò của lớp này không phải chỉ ghi lại doanh nghiệp đang sử dụng sản phẩm nào. Kiến trúc cần chỉ rõ năng lực kỹ thuật mà sản phẩm hoặc nền tảng đang cung cấp.

Ví dụ, một ứng dụng có thể yêu cầu:

·         Môi trường tính toán để chạy workload

·         Cơ sở dữ liệu để lưu trạng thái

·         Dịch vụ mạng để kết nối

·         Nền tảng quản lý API để trao đổi với hệ thống khác

·         Dịch vụ danh tính để xác thực và phân quyền

·         Cơ chế giám sát để theo dõi trạng thái vận hành

Việc tách “năng lực công nghệ” khỏi “sản phẩm cụ thể” có ý nghĩa khi thay đổi nền tảng. Nếu một cơ sở dữ liệu hoặc nhà cung cấp cloud được thay thế nhưng chức năng kiến trúc vẫn giữ nguyên, doanh nghiệp có thể đánh giá phạm vi thay đổi dựa trên các dependency đã được xác định.

Ở đây cũng cần phân biệt kiến trúc công nghệ với hạ tầng CNTT. Hạ tầng là tập hợp tài nguyên đang vận hành. Kiến trúc còn mô tả nguyên tắc tổ chức, quan hệ phụ thuộc, tiêu chuẩn và trạng thái mục tiêu của những tài nguyên đó. Hai doanh nghiệp có thể sở hữu các công nghệ tương tự nhưng có kiến trúc rất khác nhau nếu cách kết nối, phân quyền và phân bổ trách nhiệm khác nhau.

Giá trị cốt lõi nằm ở mối liên kết giữa các lớp

Các lớp chỉ trở thành kiến trúc khi quan hệ giữa chúng được xác định. Nếu tách từng lớp thành những danh mục độc lập, kết quả chủ yếu là inventory chứ chưa cho thấy cấu trúc của hệ thống doanh nghiệp.

Có một số quan hệ đặc biệt quan trọng.

Quan hệ hỗ trợ cho biết một thành phần ở lớp dưới phục vụ năng lực ở lớp trên. Ví dụ, một ứng dụng hỗ trợ một quy trình; một nền tảng cơ sở dữ liệu hỗ trợ một ứng dụng.

Quan hệ phụ thuộc cho biết một thành phần không thể hoạt động bình thường nếu thành phần khác bị thay đổi hoặc gián đoạn.

Quan hệ luồng dữ liệu cho biết thông tin xuất phát từ đâu, được biến đổi ở đâu và được sử dụng bởi thành phần nào.

Quan hệ tích hợp mô tả các điểm giao tiếp như API, message hoặc event giữa các hệ thống.

Quan hệ tiêu chuẩn hóa xác định những công nghệ, giao thức hoặc cách triển khai được phép sử dụng trong một phạm vi nhất định.

Các quan hệ này tạo ra khả năng phân tích tác động. Giả sử doanh nghiệp muốn thay thế một hệ thống ERP. Nếu kiến trúc đã xác định các ứng dụng tích hợp với ERP, dữ liệu do ERP sở hữu, quy trình phụ thuộc vào ERP và nền tảng kỹ thuật liên quan, phạm vi thay đổi có thể được đánh giá từ trước. Nếu chỉ có sơ đồ ERP như một hộp độc lập, phần lớn rủi ro nằm ngoài sơ đồ.

Đây cũng là lý do một sơ đồ duy nhất hiếm khi biểu diễn đầy đủ kiến trúc. Mỗi nhóm người dùng cần một viewpoint phù hợp: lãnh đạo quan tâm đến năng lực và tác động kinh doanh, nhóm ứng dụng quan tâm đến dependency và interface, còn nhóm nền tảng cần chi tiết về môi trường vận hành.

Bảo mật và quản trị phải xuyên suốt thay vì trở thành một lớp cô lập

Bảo mật, quản trị và các nguyên tắc kiến trúc thường không phù hợp nếu bị xem đơn thuần như một tầng nằm trên hoặc dưới các tầng khác. Chúng tác động xuyên suốt.

Ví dụ, quản lý danh tính liên quan đồng thời đến người dùng nghiệp vụ, ứng dụng và nền tảng kỹ thuật. Quy định về dữ liệu ảnh hưởng đến cách dữ liệu được tạo, truy cập, lưu trữ và trao đổi. Tiêu chuẩn tích hợp ảnh hưởng đến nhiều ứng dụng chứ không thuộc riêng một hệ thống.

Quản trị kiến trúc xác định những quyết định nào phải được kiểm soát và những tiêu chuẩn nào các nhóm triển khai cần tuân theo. Một kiến trúc có thể mô tả rất rõ trạng thái mong muốn nhưng vẫn mất tác dụng nếu các dự án mới liên tục đưa vào công nghệ, mô hình dữ liệu hoặc cách tích hợp không phù hợp với kiến trúc chung.

Trong thực tế, doanh nghiệp thường cần quản lý ít nhất ba trạng thái:

Hiện trạng cho biết hệ thống đang được tổ chức như thế nào.

Trạng thái mục tiêu mô tả cấu trúc mong muốn trong tương lai.

Lộ trình chuyển đổi xác định những thay đổi cần thực hiện để đi từ hiện trạng tới mục tiêu.

Điểm quan trọng là trạng thái mục tiêu không phải một bản vẽ cố định vĩnh viễn. Kiến trúc cần được cập nhật khi chiến lược, quy trình, dữ liệu, ứng dụng hoặc nền tảng thay đổi. Nếu không, khoảng cách giữa tài liệu kiến trúc và hệ thống thực tế sẽ ngày càng lớn.

Một kiến trúc có tổ chức tốt phải cho phép truy vết tác động thay đổi

Chất lượng của kiến trúc không nên được đánh giá bằng số lượng sơ đồ hay mức độ chi tiết của tài liệu. Một tiêu chí thực tế hơn là khả năng trả lời các câu hỏi về quan hệ và tác động.

Khi xem một thành phần công nghệ, doanh nghiệp nên có thể truy vết:

1.    Thành phần này phục vụ năng lực hoặc quy trình nghiệp vụ nào

2.    Ứng dụng nào sử dụng hoặc phụ thuộc vào nó

3.    Dữ liệu nào được tạo, lưu trữ hoặc truyền qua nó

4.    Thành phần nào kết nối với nó

5.    Tiêu chuẩn và nguyên tắc nào chi phối việc sử dụng

6.    Những gì sẽ bị ảnh hưởng nếu thành phần được thay thế

Nếu không thể thực hiện những truy vết này, vấn đề thường không nằm ở việc thiếu thêm một sơ đồ mà ở chỗ các quan hệ kiến trúc chưa được mô hình hóa đầy đủ.

Doanh nghiệp cũng không nhất thiết phải đưa mọi chi tiết kỹ thuật vào cùng một mức kiến trúc. Một cổng mạng, máy ảo hoặc phiên bản thư viện chỉ cần xuất hiện khi thông tin đó có ý nghĩa đối với quyết định kiến trúc. Việc đưa quá nhiều chi tiết vận hành vào mô hình cấp doanh nghiệp có thể làm mất các quan hệ quan trọng hơn giữa nghiệp vụ, dữ liệu, ứng dụng và công nghệ.

Kiến trúc công nghệ doanh nghiệp vì vậy có thể được hiểu như một hệ thống các lớp có quan hệ truy vết, thay vì một tập hợp công nghệ được xếp cạnh nhau. Nghiệp vụ xác định nhu cầu; dữ liệu và ứng dụng hiện thực hóa các năng lực số; nền tảng công nghệ cung cấp môi trường vận hành; còn bảo mật, tiêu chuẩn và quản trị kiểm soát cách toàn bộ cấu trúc phát triển.

Điểm quyết định không phải doanh nghiệp chia kiến trúc thành bao nhiêu lớp, mà là có mô tả được quan hệ giữa các lớp hay không. Khi những quan hệ đó rõ ràng, kiến trúc trở thành công cụ để phân tích phụ thuộc, đánh giá tác động thay đổi và giữ các quyết định công nghệ nhất quán với mục tiêu của doanh nghiệp.