TOGAF® Standard — Enterprise Architecture Capability and Governance¶

6. Tuân thủ Kiến trúc (Architecture Compliance)¶

Tuân thủ Kiến trúc (Architecture Compliance) là một khía cạnh thiết yếu của Quản trị Kiến trúc (Architecture Governance), nhằm đảm bảo các dự án riêng lẻ tuân thủ Kiến trúc Doanh nghiệp (Enterprise Architecture).

6.1. Giới thiệu¶

Để đạt được điều này, chức năng quản trị IT (IT governance function) trong một doanh nghiệp thường xác định hai quy trình bổ sung:

Chức năng Kiến trúc (Architecture function) được yêu cầu chuẩn bị một loạt Kiến trúc Dự án (Project Architectures), tức là các quan điểm cụ thể của dự án về Kiến trúc Doanh nghiệp (Enterprise Architecture), minh họa cách Kiến trúc Doanh nghiệp (Enterprise Architecture) tác động đến các dự án lớn trong tổ chức (tham khảo các Pha A đến F của ADM).
Các chức năng Quản trị Doanh nghiệp (Enterprise and IT Governance functions) sẽ xác định một quy trình đánh giá Tuân thủ Kiến trúc (Architecture Compliance review process) chính thức để xem xét sự tuân thủ của tất cả các dự án đối với Kiến trúc Doanh nghiệp (Enterprise Architecture).

Ngoài việc định nghĩa các quy trình chính thức, chức năng Quản trị Kiến trúc (Architecture Governance function) cũng có thể quy định rằng chức năng kiến trúc nên mở rộng vai trò của mình ngoài việc định nghĩa kiến trúc và lựa chọn tiêu chuẩn, để tham gia vào quá trình lựa chọn công nghệ và thậm chí cả các mối quan hệ thương mại liên quan đến việc cung cấp dịch vụ bên ngoài và mua sản phẩm. Điều này có thể giúp giảm thiểu sự hiểu sai Kiến trúc Doanh nghiệp (Enterprise Architecture) và tối đa hóa giá trị của việc đàm phán thương mại tập trung.

6.2. Thuật ngữ: Ý nghĩa của Tuân thủ Kiến trúc (Terminology: The Meaning of Architecture Compliance)¶

Mối quan hệ chính giữa kiến trúc và việc triển khai nằm trong định nghĩa các thuật ngữ "phù hợp" (conformant), "tuân thủ" (compliant), v.v. Mặc dù cách sử dụng thuật ngữ có thể khác nhau giữa các tổ chức, các khái niệm về cấp độ phù hợp trong Kiến trúc (Architecture conformance) được minh họa trong Figure 6-1 có thể hữu ích trong việc xây dựng một chiến lược tuân thủ IT.

Figure 6-1: Levels of Architecture Conformance Hình 6-1: Các mức độ tuân thủ kiến trúc

Cụm từ "phù hợp với" (in accordance with) trong Figure 6-1 có nghĩa là:

Hỗ trợ chiến lược đã nêu và các định hướng tương lai.
Tuân thủ các tiêu chuẩn đã nêu (bao gồm các quy tắc cú pháp và ngữ nghĩa được chỉ định).
Cung cấp các chức năng đã nêu.
Tuân thủ các nguyên tắc đã nêu; ví dụ:
Mở bất cứ khi nào có thể và thích hợp.
Tái sử dụng các khối xây dựng thành phần bất cứ khi nào có thể và thích hợp.

6.3. Đánh giá Tuân thủ Kiến trúc (Architecture Compliance Reviews)¶

Đánh giá Tuân thủ Kiến trúc (Architecture Compliance review) là một sự xem xét kỹ lưỡng về sự tuân thủ của một dự án cụ thể đối với các tiêu chí kiến trúc, tinh thần và mục tiêu kinh doanh đã thiết lập. Một quy trình chính thức cho các đánh giá này thường tạo thành cốt lõi của một chiến lược Tuân thủ Kiến trúc Doanh nghiệp (Enterprise Architecture Compliance strategy).

6.3.1. Mục đích (Purpose)¶

Các mục tiêu của đánh giá Tuân thủ Kiến trúc (Architecture Compliance review) bao gồm một số hoặc tất cả các điều sau đây:

Trước hết, phát hiện lỗi trong kiến trúc dự án sớm, từ đó giảm chi phí và rủi ro thay đổi yêu cầu sau này trong vòng đời. Điều này làm rút ngắn thời gian dự án tổng thể và giúp doanh nghiệp nhanh chóng đạt được lợi ích kinh doanh từ việc phát triển kiến trúc.
Đảm bảo áp dụng các phương pháp hay nhất cho công việc kiến trúc.
Cung cấp tổng quan về sự tuân thủ của một kiến trúc đối với các tiêu chuẩn doanh nghiệp bắt buộc.
Xác định nơi các tiêu chuẩn đó có thể cần sửa đổi.
Xác định các dịch vụ hiện đang dành riêng cho ứng dụng nhưng có thể được cung cấp như một phần của cơ sở hạ tầng doanh nghiệp.
Tài liệu hóa các chiến lược hợp tác, chia sẻ tài nguyên và các sức mạnh tổng hợp khác giữa nhiều nhóm kiến trúc.
Tận dụng những tiến bộ trong công nghệ.
Thông báo cho quản lý về tình trạng sẵn sàng về kinh doanh và kỹ thuật của dự án.
Xác định các tiêu chí chính cho các hoạt động mua sắm; ví dụ, để đưa vào tài liệu Yêu cầu thông tin (RFI)/Yêu cầu đề xuất (RFP) cho sản phẩm Thương mại sẵn có (COTS).
Xác định và truyền đạt các khoảng trống kiến trúc đáng kể cho các nhà cung cấp sản phẩm và dịch vụ.

Ngoài các mục tiêu chung liên quan đến đảm bảo chất lượng, còn có các động lực bổ sung, mang tính chính trị hơn để thực hiện đánh giá Tuân thủ Kiến trúc (Architecture Compliance reviews), có thể liên quan trong các trường hợp cụ thể:

Đánh giá Tuân thủ Kiến trúc (Architecture Compliance review) có thể là một cách tốt để quyết định giữa các lựa chọn kiến trúc thay thế, vì những người ra quyết định kinh doanh thường tham gia vào đánh giá có thể hướng dẫn các quyết định về điều gì là tốt nhất cho doanh nghiệp, trái ngược với điều gì có vẻ kỹ thuật hơn hoặc tinh tế hơn.
Kết quả của đánh giá Tuân thủ Kiến trúc (Architecture Compliance review) là một trong số ít các kết quả đo lường được cho ban điều hành để hỗ trợ ra quyết định.
Các đánh giá kiến trúc có thể đóng vai trò là cách để tổ chức kiến trúc (architecture organization) tương tác với các dự án phát triển mà nếu không có thể tiến hành mà không có sự tham gia của chức năng kiến trúc (architecture function).
Các đánh giá kiến trúc có thể thể hiện sự hỗ trợ nhanh chóng và tích cực cho cộng đồng kinh doanh doanh nghiệp (enterprise business community):
Kiến trúc Doanh nghiệp (Enterprise Architecture) và Tuân thủ Kiến trúc (Architecture Compliance) giúp đảm bảo sự liên kết của các dự án IT với các mục tiêu kinh doanh.
Các kiến trúc sư đôi khi có thể bị coi là quá tập trung vào cơ sở hạ tầng kỹ thuật và xa rời hoạt động kinh doanh cốt lõi.
Vì đánh giá Tuân thủ Kiến trúc (Architecture Compliance review) thường tập trung chủ yếu vào các lĩnh vực rủi ro quan trọng của một hệ thống, nó thường làm nổi bật các rủi ro chính cho chủ sở hữu hệ thống.

Trong khi sự tuân thủ kiến trúc là cần thiết cho việc phát triển và triển khai, việc không tuân thủ (non-compliance) cũng cung cấp một cơ chế để làm nổi bật:

Các lĩnh vực cần được giải quyết để tái điều chỉnh.
Các lĩnh vực cần xem xét để tích hợp vào kiến trúc khi chúng được phát hiện bởi các quy trình tuân thủ. Điểm sau đó xác định sự thay đổi và khả năng thích ứng liên tục của kiến trúc đối với các yêu cầu có thể được thúc đẩy bởi sự thiếu kỷ luật, nhưng cũng cho phép các thay đổi được ghi nhận bởi những thay đổi nhanh chóng hơn trong môi trường vận hành. Thông thường, các miễn trừ (dispensations) sẽ được sử dụng để làm nổi bật những thay đổi này và khởi động một quy trình để đăng ký, giám sát và đánh giá sự phù hợp của bất kỳ thay đổi nào được yêu cầu.

6.3.2. Thời gian (Timing)¶

Thời điểm của các hoạt động tuân thủ nên được xem xét liên quan đến sự phát triển của chính kiến trúc. Các đánh giá tuân thủ (Compliance reviews) được tổ chức tại các mốc quan trọng của dự án hoặc các điểm kiểm tra trong vòng đời của dự án. Các điểm kiểm tra cụ thể nên được bao gồm như sau:

Phát triển kiến trúc đó (ADM compliance).
Triển khai kiến trúc (architecture compliance).

Thời điểm dự án kiến trúc để đánh giá nên bao gồm:

Khởi tạo dự án.
Thiết kế ban đầu.
Thay đổi thiết kế lớn.
Tùy hứng (Ad hoc).

Đánh giá Tuân thủ Kiến trúc (Architecture Compliance review) thường được nhắm mục tiêu vào một thời điểm khi các yêu cầu kinh doanh và Kiến trúc Doanh nghiệp (Enterprise Architecture) đã khá vững chắc, và kiến trúc dự án (project architecture) đang hình thành, rất lâu trước khi hoàn thành. Mục tiêu là tổ chức đánh giá càng sớm càng tốt, ở giai đoạn vẫn còn thời gian để sửa chữa bất kỳ lỗi lớn hoặc thiếu sót nào, với điều kiện rõ ràng là cần có sự phát triển đáng kể của kiến trúc dự án (project architecture) để có cái mà xem xét. Các đầu vào cho đánh giá Tuân thủ Kiến trúc (Architecture Compliance review) có thể đến từ các phần khác của vòng đời dự án tiêu chuẩn, có thể ảnh hưởng đến thời điểm.

6.3.3. Kịch bản Quản trị và Nhân sự (Governance and Personnel Scenarios)¶

Về quản trị và thực hiện đánh giá Tuân thủ Kiến trúc (Architecture Compliance review), và các nhân sự liên quan, có nhiều kịch bản khả thi:

Đối với các dự án quy mô nhỏ hơn, quy trình đánh giá có thể đơn giản là một loạt câu hỏi mà các kiến trúc sư dự án hoặc trưởng dự án tự đặt ra, sử dụng các danh sách kiểm tra được cung cấp, có thể tổng hợp các câu trả lời thành một dạng báo cáo dự án cho quản lý. Nhu cầu thực hiện một quy trình như vậy thường được bao gồm trong các chính sách quản trị toàn doanh nghiệp.
Trường hợp dự án đang được xem xét chưa có sự tham gia của kiến trúc sư thực hành hoặc toàn thời gian (ví dụ, trong một dự án cấp ứng dụng), mục đích của đánh giá thường là để mang lại chuyên môn kiến trúc của một chức năng Kiến trúc Doanh nghiệp (Enterprise Architecture function). Trong trường hợp như vậy, chức năng Kiến trúc Doanh nghiệp (Enterprise Architecture function) sẽ tổ chức, lãnh đạo và thực hiện đánh giá, với sự tham gia của các chuyên gia lĩnh vực kinh doanh. Trong kịch bản này, đánh giá không phải là sự thay thế cho sự tham gia của các kiến trúc sư trong một dự án, mà nó có thể là một bổ sung hoặc một hướng dẫn cho sự tham gia của họ. Có khả năng cần một cơ sở dữ liệu để quản lý khối lượng dữ liệu được tạo ra trong phân tích một hệ thống hoặc tập hợp các hệ thống lớn.
Trong hầu hết các trường hợp, đặc biệt là trong các dự án quy mô lớn, chức năng kiến trúc (architecture function) sẽ tham gia sâu vào, và có thể dẫn dắt, dự án phát triển đang được xem xét (Đây là kịch bản TOGAF điển hình). Trong những trường hợp như vậy, đánh giá sẽ được điều phối bởi Kiến trúc sư Doanh nghiệp Trưởng (Lead Enterprise Architect), người sẽ tập hợp một nhóm các chuyên gia lĩnh vực kinh doanh và kỹ thuật để đánh giá, và tổng hợp các câu trả lời cho các câu hỏi được đặt ra trong quá trình đánh giá thành một dạng báo cáo. Các câu hỏi thường sẽ được đặt ra trong quá trình đánh giá bởi các chuyên gia lĩnh vực kinh doanh và kỹ thuật. Ngoài ra, đánh giá có thể được lãnh đạo bởi một đại diện của Hội đồng Kiến trúc (Architecture Board) hoặc một cơ quan tương tự có trách nhiệm toàn doanh nghiệp.

Trong mọi trường hợp, quy trình đánh giá Tuân thủ Kiến trúc (Architecture Compliance review process) cần có sự ủng hộ của quản lý cấp cao, và thường sẽ được ủy quyền như một phần của các chính sách Quản trị Kiến trúc (Architecture Governance) của công ty. Thông thường, CIO doanh nghiệp (enterprise CIO) hoặc Hội đồng Kiến trúc Doanh nghiệp (Enterprise Architecture Board) sẽ ủy quyền các đánh giá kiến trúc cho tất cả các dự án lớn, với các đánh giá hàng năm sau đó.

6.4. Quy trình Đánh giá Tuân thủ Kiến trúc (Architecture Compliance Review Process)¶

6.4.1. Tổng quan¶

Quy trình đánh giá Tuân thủ Kiến trúc (Architecture Compliance review process) được minh họa trong Hình 6-2.

Figure 6-2: Architecture Compliance Review Process Hình 6-2: Quy trình Đánh giá Tuân thủ Cấu trúc

!!! Note "Lưu ý": Một cách khác để kiểm tra sự phù hợp trong kiến trúc là thông qua việc sử dụng khả năng truy vết (traceability) trong các mô hình và các sơ đồ "drill-down". Trong kỹ thuật này, Kiến trúc sư Doanh nghiệp (Enterprise Architect) tạo ra một cái nhìn cấp cao của kiến trúc mà các Kiến trúc sư Giải pháp (Solution Architects) tinh chỉnh thêm bằng cách truy vết các yếu tố của họ đến mô hình Kiến trúc Doanh nghiệp (Enterprise Architecture). Những tinh chỉnh này có thể được quản lý thông qua các sơ đồ "drill-down", chứa tất cả các yếu tố tinh chỉnh và khả năng truy vết của chúng. Bằng cách này, sự phù hợp có thể được xem xét và ít nhất một phần được tự động hóa bằng các công cụ (chẳng hạn như có một kịch bản kiểm tra rằng tất cả các yếu tố Kiến trúc Doanh nghiệp (Enterprise Architecture) đều có tinh chỉnh trong Kiến trúc Giải pháp (Solution Architecture)).

6.4.2. Vai trò (Roles)¶

Các vai trò chính trong quy trình đánh giá Tuân thủ Kiến trúc:

Hội đồng Kiến trúc (Architecture Board): Đảm bảo Kiến trúc Doanh nghiệp (Enterprise Architectures) nhất quán và hỗ trợ nhu cầu kinh doanh tổng thể. Tài trợ và giám sát các hoạt động kiến trúc.
Trưởng dự án (Project Leader) (hoặc Hội đồng Dự án (Project Board)): Chịu trách nhiệm cho toàn bộ dự án.
Điều phối viên Đánh giá Kiến trúc (Architecture Review Co-ordinator): Quản lý toàn bộ quy trình phát triển và đánh giá kiến trúc. Có xu hướng định hướng kinh doanh hơn là định hướng công nghệ.
Kiến trúc sư Doanh nghiệp Trưởng (Lead Enterprise Architect): Đảm bảo kiến trúc có sự gắn kết về kinh doanh và kỹ thuật, và khả năng chống chịu trong tương lai. Là một chuyên gia kiến trúc phù hợp.
Kiến trúc sư (Architect): Một trong những trợ lý của Kiến trúc sư Doanh nghiệp Trưởng (Lead Enterprise Architect).
Khách hàng (Customer): Đảm bảo các yêu cầu kinh doanh được thể hiện và hiểu rõ ràng. Quản lý phần tổ chức sẽ phụ thuộc vào sự thành công của Kiến trúc Doanh nghiệp (Enterprise Architecture).
Chuyên gia Lĩnh vực Kinh doanh (Business Domain Expert): Đảm bảo các quy trình để đáp ứng các yêu cầu kinh doanh được chứng minh và hiểu rõ. Biết cách lĩnh vực kinh doanh hoạt động; cũng có thể là khách hàng.
Người đứng đầu Dự án (Project Principals): Đảm bảo các kiến trúc sư có sự hiểu biết đủ chi tiết về các quy trình của bộ phận khách hàng. Họ có thể cung cấp đầu vào cho chuyên gia lĩnh vực kinh doanh hoặc cho các kiến trúc sư. Là thành viên của tổ chức khách hàng có đầu vào cho các yêu cầu kinh doanh mà kiến trúc phải giải quyết.

Các vai trò chính trong quy trình được thể hiện trong Bảng 6-1:

Bảng 6-1: Các vai trò trong quy trình tuân thủ kiến trúc

STT	Vai trò (Role)	Trách nhiệm (Responsibilities)	Ghi chú (Notes)
1	Hội đồng Kiến trúc (Architecture Board)	Đảm bảo rằng Kiến trúc Doanh nghiệp (Enterprise Architectures) nhất quán và hỗ trợ các nhu cầu kinh doanh tổng thể.	Tài trợ (Sponsor) và giám sát (monitor) các hoạt động kiến trúc.
2	Trưởng dự án (Project Leader) (hoặc Ban dự án (Project Board))	Chịu trách nhiệm cho toàn bộ dự án.
3	Điều phối viên rà soát kiến trúc (Architecture Review Co-ordinator)	Quản lý toàn bộ quá trình phát triển và rà soát kiến trúc (architecture development and review process).	Có xu hướng định hướng kinh doanh (business-oriented) nhiều hơn là định hướng công nghệ (technology-oriented).
4	Kiến trúc sư Doanh nghiệp trưởng (Lead Enterprise Architect)	Đảm bảo rằng kiến trúc vừa phù hợp với kinh doanh vừa thống nhất về mặt kỹ thuật, đồng thời có thể đáp ứng trong tương lai (future-proof).	Là một chuyên gia kiến trúc phù hợp (appropriate architecture specialist).
5	Kiến trúc sư (Architect)	Một trong các trợ lý của Kiến trúc sư Doanh nghiệp trưởng (Lead Enterprise Architect).
6	Khách hàng (Customer)	Đảm bảo rằng các yêu cầu kinh doanh (business requirements) được thể hiện rõ ràng và được hiểu đúng.	Quản lý phần tổ chức sẽ phụ thuộc vào sự thành công của Kiến trúc Doanh nghiệp (Enterprise Architecture).
7	Chuyên gia miền kinh doanh (Business Domain Expert)	Đảm bảo rằng các quy trình để đáp ứng yêu cầu kinh doanh (business requirements) được biện minh và được hiểu rõ.	Hiểu cách thức miền kinh doanh vận hành; cũng có thể chính là khách hàng (customer).
8	Nguyên tắc dự án (Project Principals)	Đảm bảo rằng các kiến trúc sư có sự hiểu biết đủ chi tiết về các quy trình của bộ phận khách hàng. Có thể cung cấp đầu vào cho chuyên gia miền kinh doanh (business domain expert) hoặc cho các kiến trúc sư.	Là các thành viên của tổ chức khách hàng, những người đưa ra đầu vào cho các yêu cầu kinh doanh mà kiến trúc cần giải quyết.

6.4.3. Các bước (Steps)¶

Các bước chính trong quy trình đánh giá Tuân thủ Kiến trúc:

Yêu cầu đánh giá kiến trúc (Request architecture review): Theo ủy quyền của các chính sách và quy trình quản trị. Bất kỳ ai, dù là người có chuyên môn IT hay kinh doanh, có quan tâm hoặc trách nhiệm đối với lĩnh vực kinh doanh bị ảnh hưởng.
Xác định bộ phận chịu trách nhiệm của tổ chức và các người đứng đầu dự án có liên quan (Identify responsible part of organization and relevant project principals): Điều phối viên Đánh giá Kiến trúc (Architecture Review Co-ordinator) thực hiện.
Xác định Kiến trúc sư Doanh nghiệp Trưởng và các kiến trúc sư khác (Identify Lead Enterprise Architect and other architects): Điều phối viên Đánh giá Kiến trúc (Architecture Review Co-ordinator) thực hiện.
Xác định phạm vi đánh giá (Determine scope of review): Xác định những đơn vị kinh doanh/phòng ban khác có liên quan. Hiểu vị trí của hệ thống trong khung kiến trúc doanh nghiệp. Điều phối viên Đánh giá Kiến trúc (Architecture Review Co-ordinator) thực hiện.
Điều chỉnh danh sách kiểm tra (Tailor checklists): Để giải quyết các yêu cầu kinh doanh. Kiến trúc sư Doanh nghiệp Trưởng (Lead Enterprise Architect) thực hiện.
Lên lịch Cuộc họp Đánh giá Kiến trúc (Schedule Architecture Review Meeting): Điều phối viên Đánh giá Kiến trúc (Architecture Review Co-ordinator) với sự hợp tác của Kiến trúc sư Doanh nghiệp Trưởng (Lead Enterprise Architect) thực hiện.
Phỏng vấn các người đứng đầu dự án (Interview project principals): Để có thông tin cơ bản và kỹ thuật: Đối với dự án nội bộ: trực tiếp; Đối với COTS: trực tiếp hoặc qua RFP. Sử dụng danh sách kiểm tra. Kiến trúc sư Doanh nghiệp Trưởng (Lead Enterprise Architect) và/hoặc Kiến trúc sư (Architect), Trưởng dự án (Project Leader) và Khách hàng (Customers) thực hiện.
Phân tích danh sách kiểm tra đã hoàn thành (Analyze completed checklists): Xem xét theo tiêu chuẩn công ty. Xác định và giải quyết các vấn đề. Đưa ra khuyến nghị. Kiến trúc sư Doanh nghiệp Trưởng (Lead Enterprise Architect) thực hiện.
Chuẩn bị báo cáo đánh giá Tuân thủ Kiến trúc (Prepare Architecture Compliance review report): Có thể bao gồm nhân viên hỗ trợ. Kiến trúc sư Doanh nghiệp Trưởng (Lead Enterprise Architect) thực hiện.
Trình bày kết quả đánh giá (Present review findings): Cho Khách hàng (Customer) và cho Hội đồng Kiến trúc (Architecture Board). Kiến trúc sư Doanh nghiệp Trưởng (Lead Enterprise Architect) thực hiện.
Chấp nhận đánh giá và ký duyệt (Accept review and sign off): Hội đồng Kiến trúc (Architecture Board) và Khách hàng (Customer) thực hiện.
Gửi báo cáo đánh giá/tóm tắt cho Điều phối viên Đánh giá Kiến trúc (Send assessment report/summary to Architecture Review Co-ordinator): Kiến trúc sư Doanh nghiệp Trưởng (Lead Enterprise Architect) thực hiện.

Các bước chính trong quy trình được thể hiện trong Bảng 6-2:

Bảng 6-2: Các Bước trong Quy Trình Tuân thủ Cấu trúc

STT	Hành động (Action)	Ghi chú (Notes)	Ai thực hiện (Who)
1	Yêu cầu rà soát kiến trúc (Request architecture review).	Theo quy định của chính sách và thủ tục quản trị (governance policies and procedures).	Bất kỳ ai, dù định hướng CNTT (IT-oriented) hay định hướng kinh doanh (business-oriented), có quan tâm hoặc trách nhiệm với lĩnh vực kinh doanh liên quan
2	Xác định bộ phận chịu trách nhiệm trong tổ chức và các nguyên tắc dự án (project principals) liên quan.		Điều phối viên rà soát kiến trúc (Architecture Review Co-ordinator)
3	Xác định Kiến trúc sư Doanh nghiệp trưởng (Lead Enterprise Architect) và các kiến trúc sư khác.		Điều phối viên rà soát kiến trúc (Architecture Review Co-ordinator)
4	Xác định phạm vi (scope) của rà soát.	Xác định các đơn vị/bộ phận kinh doanh khác có liên quan. Hiểu hệ thống này nằm ở đâu trong khung kiến trúc doanh nghiệp (corporate architecture framework).	Điều phối viên rà soát kiến trúc (Architecture Review Co-ordinator)
5	Điều chỉnh (tailor) các checklist.	Nhằm giải quyết các yêu cầu kinh doanh (business requirements).	Kiến trúc sư Doanh nghiệp trưởng (Lead Enterprise Architect)
6	Lên lịch họp rà soát kiến trúc (Schedule Architecture Review Meeting).		Điều phối viên rà soát kiến trúc (Architecture Review Co-ordinator) phối hợp với Kiến trúc sư Doanh nghiệp trưởng (Lead Enterprise Architect)
7	Phỏng vấn các nguyên tắc dự án (project principals).	Để lấy thông tin bối cảnh và kỹ thuật: Với dự án nội bộ: trực tiếp (in person) Với COTS (Commercial Off-The-Shelf – Phần mềm thương mại sẵn có): trực tiếp hoặc thông qua RFP (Request For Proposal – Yêu cầu đề xuất) Sử dụng checklist.	Kiến trúc sư Doanh nghiệp trưởng (Lead Enterprise Architect) và/hoặc Kiến trúc sư (Architect), Trưởng dự án (Project Leader), và Khách hàng (Customers)
8	Phân tích các checklist đã hoàn thành.	So sánh với các tiêu chuẩn doanh nghiệp (corporate standards). Xác định và xử lý vấn đề. Đưa ra khuyến nghị.	Kiến trúc sư Doanh nghiệp trưởng (Lead Enterprise Architect)
9	Chuẩn bị báo cáo rà soát tuân thủ kiến trúc (Prepare Architecture Compliance review report).	Có thể cần sự tham gia của nhân sự hỗ trợ (supporting staff).	Kiến trúc sư Doanh nghiệp trưởng (Lead Enterprise Architect)
10	Trình bày kết quả rà soát.	* Cho Khách hàng (Customer) Cho Hội đồng Kiến trúc (Architecture Board)*	Kiến trúc sư Doanh nghiệp trưởng (Lead Enterprise Architect)
11	Chấp nhận kết quả rà soát và ký duyệt (sign off).		Hội đồng Kiến trúc (Architecture Board) và Khách hàng (Customer)
12	Gửi báo cáo/ tóm tắt đánh giá cho Điều phối viên rà soát kiến trúc (Architecture Review Co-ordinator).		Kiến trúc sư Doanh nghiệp trưởng (Lead Enterprise Architect)

6.5. Hướng dẫn Đánh giá Tuân thủ Kiến trúc (Architecture Compliance Review Guidelines)¶

6.5.1. Điều chỉnh Danh sách kiểm tra (Tailoring the Checklists)¶

Tập trung vào:

Các lĩnh vực rủi ro cao.
Các yếu tố khác biệt dự kiến (và mới nổi).

Đối với mỗi câu hỏi trong danh sách kiểm tra, cần hiểu:

Bản thân câu hỏi.
Những gì cần tìm trong các phản hồi.
Hỏi ý kiến các chuyên gia chủ đề.
Sửa đổi các câu hỏi trong danh sách kiểm tra cho phù hợp với mục đích sử dụng.
Lưu ý đến nhu cầu phản hồi cho Hội đồng Kiến trúc (Architecture Board).

6.5.2. Thực hiện Đánh giá Tuân thủ Kiến trúc (Conducting Architecture Compliance Reviews)¶

Hiểu rõ các mục tiêu của những người yêu cầu đánh giá; và đi đúng hướng, cung cấp những gì đã được yêu cầu. Ví dụ, họ thường muốn biết điều gì đúng hoặc sai với hệ thống đang được kiến trúc; không phải điều gì đúng hoặc sai với phương pháp phát triển được sử dụng, cấu trúc quản lý của họ, v.v. Rất dễ bị lạc đề và thảo luận các chủ đề thú vị và có lẽ đáng giá, nhưng không phải là điều được yêu cầu. Nếu có thể làm sáng tỏ các cách tiếp cận kỹ thuật, nhưng cuộc thảo luận không cần thiết cho việc đánh giá, hãy tình nguyện cung cấp sau khi đánh giá.
Nếu trong quá trình thảo luận, trở nên rõ ràng có những vấn đề khác cần được giải quyết, nằm ngoài phạm vi của đánh giá được yêu cầu, hãy nêu vấn đề đó với chủ tịch cuộc họp sau đó. Một kế hoạch để giải quyết các vấn đề sau đó có thể được phát triển tùy theo mức độ nghiêm trọng của chúng.
Luôn "khoa học" (stay "scientific"). Thay vì nói: "Chúng tôi thích thấy các cơ sở dữ liệu lớn được lưu trữ trên ABC hơn là XYZ.", hãy nói những điều như: "Thời gian ngừng hoạt động liên quan đến môi trường cơ sở dữ liệu XYZ lớn hơn nhiều so với môi trường cơ sở dữ liệu ABC. Do đó, chúng tôi không khuyến nghị lưu trữ các hệ thống loại M và N trong môi trường XYZ.".
Đặt các câu hỏi "mở" (ask "open" questions); tức là các câu hỏi không giả định một câu trả lời cụ thể.
Thường có "các chương trình nghị sự ẩn" (hidden agendas) hoặc các vấn đề gây tranh cãi giữa những người yêu cầu đánh giá, mà bạn có thể không biết trước. Một cách tiếp cận phi cá nhân trong các cuộc thảo luận có thể giúp thu hẹp khoảng cách ý kiến thay vì làm trầm trọng thêm chúng.
Đối xử với những người được phỏng vấn một cách tôn trọng. Họ có thể không xây dựng hệ thống "theo cách đáng lẽ ra", nhưng họ có thể đã làm tốt nhất có thể trong hoàn cảnh họ được đặt vào.
Giúp bài tập trở thành một trải nghiệm học hỏi cho bạn và những người thuyết trình.
Các đánh giá nên bao gồm các hoạt động đánh giá chi tiết so với các kiến trúc và nên đảm bảo rằng các kết quả được lưu trữ trong Enterprise Continuum.
Để biết ví dụ về các câu hỏi có thể được sử dụng trong đánh giá Tuân thủ Kiến trúc (architecture compliance reviews), hãy tham khảo The Open Group Guide: Architecture Compliance Review Checklists.