Hướng dẫn thiết thực cho phát triển kiến trúc doanh nghiệp – p3

 

Một siêu mô hình là một khung nhìn trừu tượng về kiến trúc của bạn. Nó cho thấy dữ liệu mà bạn đang cố gắng nắm bắt và các mối quan hệ giữa các dữ liệu. Đây là nơi mà bạn thấy được sự sắp hàng, dựa trên các câu trả lời cho các câu hỏi nghiệp vụ của bạn.
Ví dụ, nếu bạn cần biết ứng dụng hỗ trợ một quy trình nghiệp vụ nhất định, thì phải có một mối quan hệ giữa hai cái đó trong siêu mô hình của bạn. Nếu không, sẽ không có kết nối nào giữa các dữ liệu, bạn không thể trả lời câu hỏi nghiệp vụ của mình và kiến trúc không dùng được.
Lưu ý rằng bạn không cần một mối quan hệ trực tiếp giữa tất cả mọi thứ trong siêu mô hình của mình và bạn chỉ cần liên kết những thứ này với nhau để có các mối quan hệ logic. Ví dụ, việc liên kết một phòng ban trong tổ chức với một công nghệ không có ý nghĩa gì cả, nhưng việc liên kết một công nghệ với một ứng dụng lại có ý nghĩa. Một công cụ mô hình hóa tốt, ví dụ như Rational System Architect hỗ trợ duyệt qua siêu mô hình để tạo các báo cáo phức tạp. Vì vậy, trong ví dụ về siêu mô hình này, bạn có thể báo cáo về phần cứng hỗ trợ một chức năng nghiệp vụ cho dù không có một mối quan hệ trực tiếp trong siêu mô hình đó. Trong một siêu mô hình bạn có thể có khả năng duyệt đi từ một chức năng nghiệp vụ, đến một quy trình nghiệp vụ thuộc sở hữu của chức năng đó, đến một vị trí của quy trình nghiệp vụ đó, đến một ứng dụng đang hỗ trợ mà quy trình này cần đến và cuối cùng đến các công nghệ hỗ trợ ứng dụng đó.

Bây giờ bạn đã xác định được các câu hỏi nghiệp vụ của mình, khung công tác của mình và siêu mô hình mà bạn cần để trả lời các câu hỏi của mình, bạn cần tìm ra cần vẽ những mô hình nào.
Sử dụng một quy trình nghiệp vụ làm một ví dụ, có nhiều tiêu chuẩn công nghiệp hỗ trợ việc mô hình hóa các quy trình nghiệp vụ, ví dụ như BPMN và các lưu đồ. Hãy chọn phương pháp luận mô hình hóa của bạn dựa trên các tiêu chí sau:
Đối tượng người xem. Các nhà quản lý hiểu các sơ đồ đơn giản như BPMN; các nhà phát triển phần mềm thường thích các sơ đồ tuần tự UML hoặc các sơ đồ trường hợp sử dụng.
Các phần tử của siêu mô hình. Nếu trong siêu mô hình của mình, bạn cần hiểu dữ liệu trong khi nó liên hệ các quy trình nghiệp vụ, thì hãy xem xét việc sử dụng BPMN để mô hình hóa dữ liệu đó. Nếu thay vào đó, bạn chỉ lo lắng về trình tự của các bước quy trình thì hãy xem xét việc tạo ra một lưu đồ.
Sau khi biết đối tượng người xem và nội dung mà bạn muốn mô hình hóa thì bạn có thể xác định các sơ đồ mà bạn cần tạo ra. Trong ví dụ trên do bạn cần thông tin về các quy trình nghiệp vụ và các giao diện hệ thống, bạn có thể chọn các mô hình sau:
BPMN (nắm bắt các quy trình nghiệp vụ)
Kiến trúc hệ thống (nắm bắt các ứng dụng)
Với ví dụ khách sạn, chúng cần trả lời câu hỏi nghiệp vụ "Các ứng dụng nào hỗ trợ quy trình nghiệp vụ nào?"
Điều quan trọng cần nhớ là bạn không thể sử dụng một sơ đồ duy nhất để mô hình hóa tất cả mọi thứ trong kiến trúc doanh nghiệp của bạn. Hơn nữa, việc tách các khung nhìn kiến trúc, ví dụ như khung nhìn ứng dụng khỏi khung nhìn nghiệp vụ, là một cách làm thực hành tốt nhất. Nếu bạn cố gắng mô hình hóa cả hai khung nhìn trong cùng một sơ đồ, thì nó thường gây ra sự nhầm lẫn và không nắm bắt thông tin một cách có ý nghĩa.
Siêu mô hình của bạn cần có các đặc tính sau đây:
Các mối quan hệ giữa các phần tử kiến trúc. Ví dụ, một quy trình nghiệp vụ đến một ứng dụng.
Các định nghĩa của các phần tử. Ví dụ, ý nghĩa của thuật ngữ "ứng dụng" và bạn sẽ nắm bắt các đặc tính nào.
Khả năng truy tìm nguồn gốc cho các câu hỏi nghiệp vụ. Ví dụ, nếu câu hỏi của bạn là "Các ứng dụng nào hỗ trợ các quy trình nghiệp vụ nào?" Bạn biết rằng bạn cần có một quy trình nghiệp vụ và một ứng dụng trong siêu mô hình của bạn, với một mối quan hệ trực tiếp hoặc gián tiếp giữa chúng.
Về đầu trang

Bước 6. Xác định các mô hình cần thiết trong kiến trúc


Như Will Gadd đã nói, "Có gì đó hiện ra và chẳng làm điều gì có ích mà tôi thấy rất hấp dẫn".

Sử dụng các công cụ thích hợp

Một công cụ hoặc phương pháp luận mô hình hóa duy nhất không cung cấp một giải pháp đầy đủ. Bên cạnh một công cụ để phát triển các mô hình, bạn cũng nên có các công cụ để xuất bản, quản lý các yêu cầu và hiển thị trên bảng điều khiển. Một bảng điều khiển trình bày thông tin kiến trúc doanh nghiệp của bạn dưới dạng các biểu đồ dễ hiểu giống như các biểu đồ chia bánh và biểu đồ thanh.

Nếu công cụ kiến trúc của bạn có thể tùy chỉnh, thì các tùy chỉnh câu hỏi sẽ thay đổi cách công cụ này được dự kiến để được sử dụng. Tùy chỉnh quá nhiều thường là một dấu hiệu cho thấy bạn đang sử dụng công cụ hoặc cách tiếp cận sai. Cũng nên nhớ rằng tùy chỉnh tạo thêm gánh nặng quản trị kiến trúc.

Một số khách hàng tùy chỉnh các công cụ kiến trúc để tạo mô hình riêng của họ. Đây không phải là một cách tiếp cận thực hành tốt nhất, đặc biệt là nếu "mô hình" là một sơ đồ duy nhất chiếm toàn bộ một bức tường có chứa tất cả các thông tin về kiến trúc của bạn. Thay vì tạo giấy dán tường, hãy tạo các báo cáo. Không phải tất cả mọi thứ đều cần được hiển thị trên một sơ đồ.

Con người cũng quan trọng như các công cụ khi tạo một kiến trúc. Một người duy nhất không thể là một chuyên gia trong mọi khía cạnh của kiến trúc. Hãy phát triển một đội ngũ có kiến thức sâu rộng để hỗ trợ kiến trúc. Để có một danh sách các đặc trưng lý tưởng của một nhóm kiến trúc, hãy xem bài đầu tiên trong loạt bài Hãy khai thác tối đa giá trị từ nhà tư vấn kiến trúc doanh nghiệp của bạn.

Franki Schafrik, Kiến trúc sư doanh nghiệp cao cấp, IBM 
Franki Schafrik có 17 năm kinh nghiệm về sử dụng Rational System Architect. Cô có 20 năm kinh nghiệm tư vấn về Kiến trúc doanh nghiệp với các khách hàng chính phủ và thương mại trên toàn thế giới. Cô dạy các phương pháp luận DoDAF và EA ở nhiều nước. 

*

*

Top