TOGAF® Standard — Architecture Content¶

4. Sản phẩm Bàn giao Kiến trúc (Architecture Deliverables)¶

Dựa trên các nguồn tài liệu được cung cấp, dưới đây là thông tin chi tiết về các sản phẩm bàn giao kiến trúc (Architecture Deliverables) trong tiêu chuẩn TOGAF, kèm theo chú thích các thuật ngữ tiếng Anh:

4.1. Giới thiệu¶

Chương này cung cấp mô tả các sản phẩm bàn giao (deliverables) được tham chiếu trong ADM (Architecture Development Method - Phương pháp Phát triển Kiến trúc).

Sản phẩm bàn giao kiến trúc (architecture deliverables) thường là các sản phẩm công việc chính thức (formal work products) hoặc theo hợp đồng (contractual work products) của một dự án kiến trúc. Do đó, chúng có thể bị giới hạn hoặc thay đổi bởi bất kỳ khuôn khổ quản lý dự án hoặc quy trình tổng thể nào của doanh nghiệp (enterprise), chẳng hạn như CMMI® (Capability Maturity Model Integration - Mô hình Tích hợp Độ chín Năng lực), PRINCE2® (PRojects IN Controlled Environments - Dự án trong Môi trường được Kiểm soát), PMBOK® (Project Management Body of Knowledge - Tập hợp Kiến thức Quản lý Dự án), hoặc MSP® (Managing Successful Programmes - Quản lý các Chương trình Thành công).

Mục đích của chương này là cung cấp một đường cơ sở điển hình (typical baseline) cho các sản phẩm bàn giao kiến trúc. Điều này nhằm xác định rõ hơn các hoạt động cần thiết trong ADM và đóng vai trò là điểm khởi đầu cho việc điều chỉnh (tailoring) trong một tổ chức cụ thể.

Khuôn khổ Nội dung TOGAF (TOGAF Content Framework) xác định các sản phẩm bàn giao được tạo ra dưới dạng đầu ra (outputs) từ việc thực hiện chu trình ADM và có thể được sử dụng làm đầu vào (inputs) tại các thời điểm khác trong ADM. Các sản phẩm bàn giao khác có thể được tạo ra ở nơi khác và được ADM sử dụng.

4.2. Mô tả Sản phẩm Bàn giao (Deliverable Descriptions)¶

Bảng dưới đây liệt kê các sản phẩm bàn giao kiến trúc chính được tạo ra khi thực hiện ADM, cùng với các giai đoạn mà chúng là đầu ra và đầu vào:

Deliverable (Sản phẩm bàn giao)	Output from… (Đầu ra từ…)	Input to… (Đầu vào cho…)
Architecture Building Blocks (Các khối xây dựng kiến trúc)	B, C, D, F, H	A, B, C, D, E, F, G, H
Architecture Contract (Hợp đồng kiến trúc)	G	G, H
Architecture Definition Document (Tài liệu định nghĩa kiến trúc)	A, B, C, D, E, F	B, C, D, E, F, G, H
Architecture Principles (Nguyên tắc kiến trúc)	Preliminary (Sơ bộ), A, B, C, D	Preliminary (Sơ bộ), A, B, C, D, E, F, G, H
Architecture Repository (Kho lưu trữ kiến trúc)	Preliminary (Sơ bộ), A, B, C, D, Requirements Management (Quản lý yêu cầu)	Preliminary (Sơ bộ), A, B, C, D, E, F, G, H, Requirements Management (Quản lý yêu cầu)
Architecture Requirements Specification (Đặc tả yêu cầu kiến trúc)	B, C, D, E, F, Requirements Management (Quản lý yêu cầu)	C, D, Requirements Management (Quản lý yêu cầu)
Architecture Roadmap (Lộ trình kiến trúc)	B, C, D, E, F	B, C, D, E, F
Architecture Vision (Tầm nhìn kiến trúc)	A, E	B, C, D, E, F, G, H, Requirements Management (Quản lý yêu cầu)
Business Principles, Business Goals, and Business Drivers (Các nguyên tắc kinh doanh, mục tiêu kinh doanh và động lực kinh doanh)	Preliminary (Sơ bộ), A, B	A, B
Capability Assessment (Đánh giá năng lực)	A, E	B, C, D, E, F
Change Request (Yêu cầu thay đổi)	F, G, H	H
Communications Plan (Kế hoạch truyền thông)	A	B, C, D, E, F
Compliance Assessment (Đánh giá tuân thủ)	G	H
Implementation and Migration Plan (Kế hoạch triển khai và di chuyển)	E, F	F
Implementation Governance Model (Mô hình quản trị triển khai)	F	G, H
Organizational Model for Enterprise Architecture (Mô hình tổ chức cho Kiến trúc Doanh nghiệp)	Preliminary (Sơ bộ)	Preliminary (Sơ bộ), A, B, C, D, E, F, G, H, Requirements Management (Quản lý yêu cầu)
Request for Architecture Work (Yêu cầu công việc kiến trúc)	Preliminary (Sơ bộ), F, H	A, G
Requirements Impact Assessment (Đánh giá tác động yêu cầu)	Requirements Management (Quản lý yêu cầu)	Requirements Management (Quản lý yêu cầu)
Solution Building Blocks (Các khối xây dựng giải pháp)	G	A, B, C, D, E, F, G
Statement of Architecture Work (Báo cáo công việc kiến trúc)	A, B, C, D, E, F, G, H	B, C, D, E, F, G, H, Requirements Management (Quản lý yêu cầu)
Tailored Architecture Framework (Khuôn khổ kiến trúc được điều chỉnh)	Preliminary (Sơ bộ), A	Preliminary (Sơ bộ), A, B, C, D, E, F, G, H, Requirements Management (Quản lý yêu cầu)

Các phần sau đây cung cấp mô tả ví dụ về các sản phẩm bàn giao được tham chiếu trong ADM. Cần lưu ý rằng không phải tất cả nội dung được mô tả ở đây đều cần có trong một sản phẩm bàn giao cụ thể. Thay vào đó, khuyến nghị sử dụng các tham chiếu bên ngoài nếu có thể (ví dụ: chỉ tham chiếu tên của các kế hoạch chiến lược thay vì sao chép chúng vào Yêu cầu công việc kiến trúc - Request for Architecture Work). Mặc dù không cần tuân thủ từng chữ các mô tả, mỗi yếu tố cần được xem xét cẩn thận; việc bỏ qua bất kỳ mục đầu vào hoặc đầu ra nào có thể gây ra vấn đề về sau.

4.2.1. Các khối xây dựng kiến trúc (Architecture Building Blocks)¶

Đây là các tài liệu và mô hình kiến trúc từ Kho lưu trữ kiến trúc (Architecture Repository) của doanh nghiệp. Xem Chương 5, Building Blocks (Các khối xây dựng) để biết thêm chi tiết.

4.2.2. Hợp đồng kiến trúc (Architecture Contract )¶

4.2.2.1. Mục đích¶

Hợp đồng kiến trúc (Architecture Contracts) là các thỏa thuận chung giữa các đối tác phát triển và nhà tài trợ về các sản phẩm bàn giao, chất lượng, và sự phù hợp với mục đích của một kiến trúc. Việc triển khai thành công các thỏa thuận này sẽ được thực hiện thông qua Quản trị Kiến trúc (Architecture Governance) hiệu quả.
Việc triển khai một cách tiếp cận có quản trị đối với việc quản lý các hợp đồng sẽ đảm bảo các điều sau:
Một hệ thống giám sát liên tục để kiểm tra tính toàn vẹn, các thay đổi, việc ra quyết định và kiểm toán tất cả các hoạt động liên quan đến kiến trúc trong tổ chức.
Tuân thủ các nguyên tắc, tiêu chuẩn và yêu cầu của các kiến trúc hiện có hoặc đang phát triển.
Xác định các rủi ro trong tất cả các khía cạnh của việc phát triển và triển khai kiến trúc(s), bao gồm phát triển nội bộ so với các tiêu chuẩn, chính sách, công nghệ và sản phẩm được chấp nhận, cũng như các khía cạnh vận hành của kiến trúc để tổ chức có thể tiếp tục kinh doanh trong một môi trường linh hoạt.
Một tập hợp các quy trình và thực tiễn đảm bảo trách nhiệm giải trình, trách nhiệm và kỷ luật đối với việc phát triển và sử dụng tất cả các tạo phẩm kiến trúc.
Một sự hiểu biết chính thức về tổ chức quản trị chịu trách nhiệm về hợp đồng, mức độ quyền hạn của họ và phạm vi kiến trúc dưới sự quản trị của cơ quan này.

4.2.2.2. Nội dung¶

Nội dung điển hình của một Hợp đồng Thiết kế và Phát triển Kiến trúc (Architecture Design and Development Contract) bao gồm:
Giới thiệu và bối cảnh (Introduction and background)
Bản chất của thỏa thuận (The nature of the agreement)
Phạm vi kiến trúc (Scope of the architecture)
Các nguyên tắc và yêu cầu kiến trúc và chiến lược (Architecture and strategic principles and requirements)
Yêu cầu tuân thủ (Conformance requirements)
Quy trình và vai trò phát triển và quản lý kiến trúc (Architecture development and management process and roles)
Các thước đo Kiến trúc Mục tiêu (Target Architecture measures)
Các giai đoạn sản phẩm bàn giao được xác định (Defined phases of deliverables)
Kế hoạch công việc chung được ưu tiên (Prioritized joint workplan)
Các khung thời gian (Time window(s))
Thước đo bàn giao kiến trúc và kinh doanh (Architecture delivery and business metrics)
Nội dung điển hình của một Hợp đồng Kiến trúc Người dùng Kinh doanh (Business Users' Architecture Contract) bao gồm:
Giới thiệu và bối cảnh (Introduction and background)
Bản chất của thỏa thuận (The nature of the agreement)
Phạm vi (Scope)
Yêu cầu chiến lược (Strategic requirements)
Yêu cầu tuân thủ (Conformance requirements)
Người chấp nhận kiến trúc (Architecture adopters)
Khung thời gian (Time window)
Thước đo kinh doanh kiến trúc (Architecture business metrics)
Kiến trúc dịch vụ (Service architecture) (bao gồm Thỏa thuận cấp độ dịch vụ - SLA (Service-Level Agreement)).
Để biết thêm chi tiết về việc sử dụng Hợp đồng Kiến trúc, xem Tiêu chuẩn TOGAF — Khả năng và Quản trị EA (TOGAF Standard — EA Capability and Governance).

4.2.3. Tài liệu định nghĩa kiến trúc (Architecture Definition Document)¶

4.2.3.1. Mục đích¶

Tài liệu định nghĩa kiến trúc (Architecture Definition Document) là một "container" cho các tạo phẩm kiến trúc cốt lõi được tạo ra trong một dự án và cho các thông tin liên quan quan trọng. Tài liệu này bao gồm tất cả các lĩnh vực kiến trúc (Kinh doanh, Dữ liệu, Ứng dụng và Công nghệ) và cũng xem xét tất cả các trạng thái kiến trúc liên quan (Kiến trúc Hiện trạng - Baseline, Chuyển đổi - Transition và Mục tiêu - Target).
Một Kiến trúc Chuyển đổi (Transition Architecture) thể hiện doanh nghiệp ở một trạng thái quan trọng về mặt kiến trúc giữa Kiến trúc Hiện trạng (Baseline Architecture) và Kiến trúc Mục tiêu (Target Architecture). Các Kiến trúc Chuyển đổi được sử dụng để mô tả các Kiến trúc Mục tiêu chuyển đổi cần thiết để hiện thực hóa Kiến trúc Mục tiêu một cách hiệu quả.
Tài liệu định nghĩa kiến trúc là một tài liệu bổ sung cho Đặc tả yêu cầu kiến trúc (Architecture Requirements Specification), với một mục tiêu bổ sung:
Tài liệu định nghĩa kiến trúc cung cấp một cái nhìn định tính (qualitative view) về giải pháp và nhằm mục đích truyền đạt ý định của các kiến trúc sư.
Đặc tả yêu cầu kiến trúc cung cấp một cái nhìn định lượng (quantitative view) về giải pháp, nêu rõ các tiêu chí có thể đo lường (measurable criteria) phải được đáp ứng trong quá trình triển khai kiến trúc.

4.2.3.2. Nội dung¶

Nội dung điển hình của một Tài liệu định nghĩa kiến trúc bao gồm:
Phạm vi (Scope)
Mục tiêu và các ràng buộc (Goals, objectives, and constraints)
Các nguyên tắc kiến trúc (Architecture Principles)
Kiến trúc Hiện trạng (Baseline Architecture)
Các mô hình kiến trúc (cho mỗi trạng thái cần mô hình hóa):
- Các mô hình Kiến trúc Kinh doanh (Business Architecture models)
- Các mô hình Kiến trúc Dữ liệu (Data Architecture models)
- Các mô hình Kiến trúc Ứng dụng (Application Architecture models)
- Các mô hình Kiến trúc Công nghệ (Technology Architecture models)
Lý do và biện minh cho phương pháp kiến trúc (Rationale and justification for architectural approach)
Ánh xạ tới Kho lưu trữ kiến trúc (Mapping to Architecture Repository):
- Ánh xạ tới Bức tranh kiến trúc (Architecture Landscape)
- Ánh xạ tới các mô hình tham chiếu (reference models)
- Ánh xạ tới các tiêu chuẩn (standards)
Đánh giá khả năng tái sử dụng (Re-use assessment)
Phân tích khoảng cách (Gap analysis)
Đánh giá tác động (Impact assessment)
Kiến trúc Chuyển đổi (Transition Architecture):
- Định nghĩa các trạng thái chuyển đổi (Definition of transition states)
- Kiến trúc Kinh doanh cho mỗi trạng thái chuyển đổi (Business Architecture for each transition state)
- Kiến trúc Dữ liệu cho mỗi trạng thái chuyển đổi (Data Architecture for each transition state)
- Kiến trúc Ứng dụng cho mỗi trạng thái chuyển đổi (Application Architecture for each transition state)
- Kiến trúc Công nghệ cho mỗi trạng thái chuyển đổi (Technology Architecture for each transition state)

4.2.4. Nguyên tắc kiến trúc (Architecture Principles)¶

4.2.4.1. Mục đích¶

Các nguyên tắc là các quy tắc và hướng dẫn chung, được thiết kế để tồn tại lâu dài và hiếm khi được sửa đổi, nhằm thông báo và hỗ trợ cách thức một tổ chức thực hiện sứ mệnh của mình.
Đến lượt mình, các nguyên tắc có thể chỉ là một yếu tố trong một tập hợp các ý tưởng có cấu trúc mà cùng nhau định nghĩa và hướng dẫn tổ chức, từ các giá trị đến các hành động và kết quả.

4.2.4.2. Nội dung¶

Xem Tiêu chuẩn TOGAF — Kỹ thuật ADM (TOGAF Standard — ADM Techniques) để biết hướng dẫn và một bộ chi tiết các Nguyên tắc kiến trúc chung, bao gồm:
Các nguyên tắc kinh doanh (Business principles)
Các nguyên tắc dữ liệu (Data principles)
Các nguyên tắc ứng dụng (Application principles)
Các nguyên tắc công nghệ (Technology principles)

4.2.5. Kho lưu trữ kiến trúc (Architecture Repository)¶

4.2.5.1. Mục đích¶

Kho lưu trữ kiến trúc (Architecture Repository) hoạt động như một khu vực lưu trữ cho tất cả các dự án liên quan đến kiến trúc trong doanh nghiệp. Kho lưu trữ cho phép các dự án quản lý sản phẩm bàn giao của họ, định vị các tài sản có thể tái sử dụng (re-usable assets), và công bố đầu ra cho các bên liên quan và các bên quan tâm khác.

4.2.5.2. Nội dung¶

Xem Chương 7, Architecture Repository (Kho lưu trữ kiến trúc) để biết mô tả chi tiết về nội dung của một Kho lưu trữ kiến trúc.

4.2.6. Đặc tả yêu cầu kiến trúc (Architecture Requirements Specification)¶

4.2.6.1. Mục đích¶

Đặc tả yêu cầu kiến trúc (Architecture Requirements Specification) cung cấp một tập hợp các tuyên bố định lượng (quantitative statements) phác thảo những gì một dự án triển khai phải làm để tuân thủ kiến trúc. Đặc tả yêu cầu kiến trúc thường sẽ tạo thành một thành phần chính của một hợp đồng triển khai hoặc hợp đồng để định nghĩa kiến trúc chi tiết hơn.
Như đã đề cập ở trên, Đặc tả yêu cầu kiến trúc là một tài liệu bổ sung cho Tài liệu định nghĩa kiến trúc, với một mục tiêu bổ sung:
Tài liệu định nghĩa kiến trúc (Architecture Definition Document) cung cấp một cái nhìn định tính về giải pháp và nhằm mục đích truyền đạt ý định của kiến trúc sư.
Đặc tả yêu cầu kiến trúc cung cấp một cái nhìn định lượng về giải pháp, nêu rõ các tiêu chí có thể đo lường (measurable criteria) phải được đáp ứng trong quá trình triển khai kiến trúc.

4.2.6.2. Nội dung¶

Nội dung điển hình của một Đặc tả yêu cầu kiến trúc bao gồm:
Các thước đo thành công (Success measures)
Các yêu cầu kiến trúc (Architecture requirements)
Các hợp đồng dịch vụ kinh doanh (Business service contracts)
Các hợp đồng dịch vụ ứng dụng (Application service contracts)
Hướng dẫn triển khai (Implementation guidelines)
Đặc tả triển khai (Implementation specifications)
Tiêu chuẩn triển khai (Implementation standards)
Yêu cầu tương tác (Interoperability requirements)
Yêu cầu Quản lý Dịch vụ CNTT (IT Service Management requirements)
Các ràng buộc (Constraints)
Các giả định (Assumptions)

4.2.7. Lộ trình kiến trúc (Architecture Roadmap)¶

4.2.7.1. Mục đích¶

Lộ trình kiến trúc (Architecture Roadmap) liệt kê các gói công việc (work packages) riêng lẻ sẽ hiện thực hóa Kiến trúc Mục tiêu (Target Architecture) và sắp xếp chúng trên một dòng thời gian để thể hiện sự tiến triển từ Kiến trúc Hiện trạng (Baseline Architecture) đến Kiến trúc Mục tiêu. Lộ trình kiến trúc làm nổi bật giá trị kinh doanh của từng gói công việc ở mỗi giai đoạn. Các Kiến trúc Chuyển đổi (Transition Architectures) cần thiết để hiện thực hóa Kiến trúc Mục tiêu một cách hiệu quả được xác định là các bước trung gian. Lộ trình kiến trúc được phát triển dần dần trong suốt các Giai đoạn E và F, và được thông báo bởi các thành phần lộ trình dễ nhận biết từ Giai đoạn B, C và D trong ADM.

4.2.7.2. Nội dung¶

Nội dung điển hình của một Lộ trình kiến trúc bao gồm:
Danh mục gói công việc (Work package portfolio):
- Mô tả gói công việc (tên, mô tả, mục tiêu, sản phẩm bàn giao) (Work package description (name, description, objectives, deliverables))
- Yêu cầu chức năng (Functional requirements)
- Sự phụ thuộc (Dependencies)
- Mối quan hệ với cơ hội (Relationship to opportunity)
- Mối quan hệ với Tài liệu định nghĩa kiến trúc và Đặc tả yêu cầu kiến trúc (Relationship to Architecture Definition Document and Architecture Requirements Specification)
- Giá trị kinh doanh (Business value)
Danh mục các yếu tố triển khai (Implementation Factor catalog), bao gồm:
- Rủi ro (Risks)
- Vấn đề (Issues)
- Giả định (Assumptions)
- Phụ thuộc (Dependencies)
- Hành động (Actions)
- Đầu vào (Inputs)
Ma trận tổng hợp các khoảng cách, giải pháp và sự phụ thuộc (Consolidated Gaps, Solutions, and Dependencies matrix), bao gồm:
- Lĩnh vực kiến trúc (Architecture domain)
- Khoảng cách (Gap)
- Các giải pháp tiềm năng (Potential solutions)
- Sự phụ thuộc (Dependencies)
- Bất kỳ Kiến trúc Chuyển đổi nào (Any Transition Architectures)
Các khuyến nghị triển khai (Implementation recommendations):
- Các thước đo tiêu chí về hiệu quả của các dự án (Criteria measures of effectiveness of projects)
- Rủi ro và vấn đề (Risks and issues)
- Các khối xây dựng giải pháp (Solution Building Blocks)

4.2.8. Tầm nhìn kiến trúc (Architecture Vision)¶

4.2.8.1. Mục đích¶

Tầm nhìn kiến trúc (Architecture Vision) được tạo ra sớm trong chu trình ADM. Nó cung cấp một bản tóm tắt về những thay đổi đối với doanh nghiệp sẽ tích lũy từ việc triển khai thành công Kiến trúc Mục tiêu. Mục đích của Tầm nhìn kiến trúc là cung cấp cho các bên liên quan chính một kết quả đã được thỏa thuận chính thức. Việc đồng thuận sớm về kết quả cho phép các kiến trúc sư tập trung vào chi tiết cần thiết để xác thực tính khả thi. Việc cung cấp một Tầm nhìn kiến trúc cũng hỗ trợ giao tiếp với các bên liên quan bằng cách cung cấp một phiên bản tóm tắt của Định nghĩa Kiến trúc đầy đủ.

4.2.8.2. Nội dung¶

Nội dung điển hình của một Tầm nhìn kiến trúc bao gồm:
Mô tả vấn đề (Problem description):
- Các bên liên quan và mối quan tâm của họ (Stakeholders and their concerns)
- Danh sách các Kịch bản kinh doanh (Business Scenarios) cần được giải quyết
- Danh sách các vấn đề/kịch bản cần được giải quyết (List of issues/scenarios to be addressed)
Mục tiêu của Báo cáo công việc kiến trúc (Objective of the Statement of Architecture Work)
Các góc nhìn tóm tắt cần thiết cho Yêu cầu công việc kiến trúc và Bản nháp Kiến trúc Kinh doanh, Dữ liệu, Ứng dụng và Công nghệ đã tạo ra; thường bao gồm:
- Sơ đồ chuỗi giá trị (Value Chain diagram)
- Sơ đồ khái niệm giải pháp (Solution Concept diagram)
- Các yêu cầu đã ánh xạ (Mapped requirements)
- Tham chiếu đến Bản nháp Tài liệu định nghĩa kiến trúc (Reference to Draft Architecture Definition Document)

4.2.9. Các nguyên tắc kinh doanh, mục tiêu kinh doanh và động lực kinh doanh (Business Principles, Business Goals, and Business Drivers)¶

4.2.9.1. Mục đích¶

Các nguyên tắc kinh doanh, mục tiêu kinh doanh và động lực kinh doanh cung cấp bối cảnh cho công việc kiến trúc, bằng cách mô tả các nhu cầu và cách thức làm việc được doanh nghiệp sử dụng. Nhiều yếu tố nằm ngoài sự xem xét của kỷ luật kiến trúc vẫn có thể có ý nghĩa đáng kể đối với cách thức kiến trúc được phát triển.

4.2.9.2. Nội dung¶

Nội dung và cấu trúc của bối cảnh kinh doanh cho kiến trúc có khả năng khác nhau đáng kể từ tổ chức này sang tổ chức khác.

4.2.10. Đánh giá năng lực (Capability Assessment)¶

4.2.10.1. Mục đích¶

Trước khi bắt tay vào Định nghĩa kiến trúc chi tiết, việc hiểu mức độ năng lực hiện trạng và mục tiêu của doanh nghiệp là rất có giá trị. Đánh giá năng lực (Capability Assessment) này có thể được xem xét ở một số cấp độ:
Mức độ năng lực của toàn doanh nghiệp là gì? Doanh nghiệp muốn tăng hoặc tối ưu hóa năng lực ở đâu? Đâu là các lĩnh vực kiến trúc trọng tâm sẽ hỗ trợ sự phát triển mong muốn của doanh nghiệp?
Mức độ năng lực hoặc độ chín (maturity level) của chức năng CNTT (IT function) trong doanh nghiệp là gì? Các tác động có thể có của việc thực hiện dự án kiến trúc về mặt quản trị thiết kế (design governance), quản trị vận hành (operational governance), kỹ năng và cấu trúc tổ chức là gì? Phong cách, mức độ hình thức và lượng chi tiết phù hợp cho dự án kiến trúc để phù hợp với văn hóa và năng lực của tổ chức CNTT là gì?
Năng lực và độ chín của chức năng kiến trúc trong doanh nghiệp là gì? Các tài sản kiến trúc nào hiện đang tồn tại? Chúng có được duy trì và chính xác không? Các tiêu chuẩn và mô hình tham chiếu nào cần được xem xét? Có khả năng có cơ hội tạo ra các tài sản có thể tái sử dụng trong dự án kiến trúc không?
Khi tồn tại các khoảng cách năng lực, mức độ sẵn sàng chuyển đổi của doanh nghiệp để đạt được năng lực mục tiêu là gì? Các rủi ro đối với chuyển đổi, các rào cản văn hóa và các yếu tố khác cần được giải quyết ngoài khoảng cách năng lực cơ bản là gì?

4.2.10.2. Nội dung¶

Nội dung điển hình của một Đánh giá năng lực bao gồm:
Đánh giá năng lực kinh doanh (Business Capability Assessment), bao gồm:
- Các năng lực của doanh nghiệp (Capabilities of the business)
- Đánh giá trạng thái hiện trạng về mức độ hiệu suất của từng năng lực (Baseline state assessment of the performance level of each capability)
- Nguyện vọng trạng thái tương lai về mức độ hiệu suất của từng năng lực (Future state aspiration for the performance level of each capability)
- Đánh giá trạng thái hiện trạng về cách từng năng lực được hiện thực hóa (Baseline state assessment of how each capability is realized)
- Nguyện vọng trạng thái tương lai về cách từng năng lực nên được hiện thực hóa (Future state aspiration for how each capability should be realized)
- Đánh giá các tác động có thể có đối với tổ chức kinh doanh do việc triển khai thành công Kiến trúc Mục tiêu (Assessment of likely impacts to the business organization resulting from the successful deployment of the Target Architecture)
Đánh giá năng lực CNTT (IT Capability Assessment), bao gồm:
- Mức độ chín hiện trạng và mục tiêu của quy trình thay đổi (Baseline and target maturity level of change process)
- Mức độ chín hiện trạng và mục tiêu của quy trình vận hành (Baseline and target maturity level of operational processes)
- Đánh giá năng lực và dung lượng hiện trạng (Baseline capability and capacity assessment)
- Đánh giá các tác động có thể có đối với tổ chức CNTT do việc triển khai thành công Kiến trúc Mục tiêu (Assessment of the likely impacts to the IT organization resulting from the successful deployment of the Target Architecture)
Đánh giá độ chín kiến trúc (Architecture maturity assessment), bao gồm:
- Các quy trình, tổ chức, vai trò và trách nhiệm của Quản trị Kiến trúc (Architecture Governance processes, organization, roles, and responsibilities)
- Đánh giá kỹ năng kiến trúc (Architecture skills assessment)
- Chiều rộng, chiều sâu và chất lượng của định nghĩa bức tranh kiến trúc trong Kho lưu trữ kiến trúc (Breadth, depth, and quality of landscape definition with the Architecture Repository)
- Chiều rộng, chiều sâu và chất lượng của định nghĩa tiêu chuẩn trong Kho lưu trữ kiến trúc (Breadth, depth, and quality of standards definition with the Architecture Repository)
- Chiều rộng, chiều sâu và chất lượng của định nghĩa mô hình tham chiếu trong Kho lưu trữ kiến trúc (Breadth, depth, and quality of reference model definition with the Architecture Repository)
- Đánh giá tiềm năng tái sử dụng (Assessment of re-use potential)
Đánh giá sẵn sàng chuyển đổi kinh doanh (Business Transformation Readiness Assessment), bao gồm:
- Các yếu tố sẵn sàng (Readiness factors)
- Tầm nhìn cho mỗi yếu tố sẵn sàng (Vision for each readiness factor)
- Xếp hạng sẵn sàng hiện tại và mục tiêu (Current and target readiness ratings)
- Rủi ro sẵn sàng (Readiness risks)

4.2.11. Yêu cầu thay đổi (Change Request)¶

4.2.11.1. Mục đích¶

Trong quá trình triển khai kiến trúc, khi có thêm thông tin được biết, có thể Định nghĩa kiến trúc (Architecture Definition) và các yêu cầu ban đầu không phù hợp hoặc không đủ để hoàn thành việc triển khai một giải pháp. Trong những trường hợp này, các dự án triển khai cần phải đi chệch khỏi phương pháp kiến trúc được đề xuất hoặc yêu cầu mở rộng phạm vi. Ngoài ra, các yếu tố bên ngoài — chẳng hạn như yếu tố thị trường, thay đổi trong chiến lược kinh doanh và cơ hội công nghệ mới — có thể mở ra cơ hội để mở rộng và tinh chỉnh kiến trúc.
Trong những trường hợp này, một Yêu cầu thay đổi (Change Request) có thể được gửi để khởi động một chu trình công việc kiến trúc tiếp theo.

4.2.11.2. Nội dung¶

Nội dung điển hình của một Yêu cầu thay đổi bao gồm:
Mô tả thay đổi được đề xuất (Description of the proposed change)
Lý do cho thay đổi được đề xuất (Rationale for the proposed change)
Đánh giá tác động của thay đổi được đề xuất (Impact assessment of the proposed change), bao gồm:
- Tham chiếu đến các yêu cầu cụ thể (Reference to specific requirements)
- Ưu tiên của bên liên quan đối với các yêu cầu cho đến nay (Stakeholder priority of the requirements to date)
- Các giai đoạn cần xem xét lại (Phases to be revisited)
- Giai đoạn dẫn đầu về ưu tiên yêu cầu (Phase to lead on requirements prioritization)
- Kết quả điều tra giai đoạn và ưu tiên sửa đổi (Results of phase investigations and revised priorities)
- Khuyến nghị về quản lý yêu cầu (Recommendations on management of requirements)
- Số tham chiếu kho lưu trữ (Repository reference number)

4.2.12. Kế hoạch truyền thông (Communications Plan)¶

4.2.12.1. Mục đích¶

Kiến trúc Doanh nghiệp (Enterprise Architectures) chứa một lượng lớn thông tin phức tạp và phụ thuộc lẫn nhau. Việc truyền đạt thông tin mục tiêu một cách hiệu quả đến đúng các bên liên quan vào đúng thời điểm là một Yếu tố Thành công Quan trọng (CSF - Critical Success Factor) cho Kiến trúc Doanh nghiệp. Việc phát triển một Kế hoạch truyền thông** (Communications Plan) cho kiến trúc cho phép việc truyền thông này được thực hiện trong một quy trình được lên kế hoạch và quản lý.

4.2.12.2. Nội dung¶

Nội dung điển hình của một Kế hoạch truyền thông bao gồm:
Xác định các bên liên quan và phân nhóm theo yêu cầu truyền thông (Identification of stakeholders and grouping by communication requirements)
Xác định nhu cầu truyền thông, các thông điệp chính liên quan đến Tầm nhìn kiến trúc, rủi ro truyền thông và CSF (Identification of communication needs, key messages in relation to the Architecture Vision, communication risks, and CSFs)
Xác định các cơ chế sẽ được sử dụng để giao tiếp với các bên liên quan và cho phép truy cập thông tin kiến trúc, chẳng hạn như cuộc họp, bản tin, kho lưu trữ, v.v. (Identification of mechanisms that will be used to communicate with stakeholders and allow access to architecture information, such as meetings, newsletters, repositories, etc.)
Xác định một lịch trình truyền thông, cho thấy những thông tin liên lạc nào sẽ xảy ra với nhóm bên liên quan nào vào thời điểm nào và ở đâu (Identification of a communications timetable, showing which communications will occur with which stakeholder groups at what time and in what location)

4.2.13. Đánh giá tuân thủ (Compliance Assessment)¶

4.2.13.1. Mục đích¶

Sau khi một kiến trúc đã được định nghĩa, cần phải quản trị kiến trúc đó thông qua việc triển khai để đảm bảo rằng Tầm nhìn kiến trúc ban đầu được hiện thực hóa một cách thích hợp và bất kỳ bài học nào từ việc triển khai được đưa trở lại quy trình kiến trúc. Các đánh giá tuân thủ định kỳ của các dự án triển khai cung cấp một cơ chế để xem xét tiến độ dự án và đảm bảo rằng thiết kế và triển khai đang tiến hành phù hợp với các mục tiêu chiến lược và kiến trúc.

4.2.13.2. Nội dung¶

Nội dung điển hình của một Đánh giá tuân thủ (Compliance Assessment) bao gồm:
Tổng quan về tiến độ và trạng thái dự án (Overview of project progress and status)
Tổng quan về kiến trúc/thiết kế dự án (Overview of project architecture/design)
Các danh sách kiểm tra kiến trúc đã hoàn thành (Completed architecture checklists):
- Danh sách kiểm tra phần cứng và hệ điều hành (Hardware and operating system checklist)
- Danh sách kiểm tra dịch vụ phần mềm và middleware (Software services and middleware checklist)
- Danh sách kiểm tra ứng dụng (Applications checklists)
- Danh sách kiểm tra quản lý thông tin (Information management checklists)
- Danh sách kiểm tra bảo mật (Security checklists)
- Danh sách kiểm tra quản lý hệ thống (System management checklists)
- Danh sách kiểm tra kỹ thuật hệ thống (System engineering checklists)
- Danh sách kiểm tra phương pháp và công cụ (Methods and tools checklists)

4.2.14. Kế hoạch triển khai và di chuyển (Implementation and Migration Plan)¶

4.2.14.1. Mục đích¶

Kế hoạch triển khai và di chuyển (Implementation and Migration Plan) cung cấp một lịch trình các dự án sẽ hiện thực hóa Kiến trúc Mục tiêu (Target Architecture). Kế hoạch này bao gồm các dự án có thể thực thi được nhóm lại thành các danh mục đầu tư (portfolios) và chương trình (programs) được quản lý. Chiến lược triển khai và di chuyển (Implementation and Migration Strategy) xác định cách tiếp cận thay đổi là một yếu tố chính của Kế hoạch triển khai và di chuyển.

4.2.14.2. Nội dung¶

Nội dung điển hình của một Kế hoạch triển khai và di chuyển bao gồm:
Chiến lược triển khai và di chuyển (Implementation and Migration Strategy):
- Định hướng triển khai chiến lược (Strategic implementation direction)
- Phương pháp sắp xếp trình tự triển khai (Implementation sequencing approach)
Phân tích dự án và danh mục đầu tư (Project and portfolio breakdown of implementation):
- Phân bổ các gói công việc cho dự án và danh mục đầu tư (Allocation of work packages to project and portfolio)
- Các năng lực được cung cấp bởi các dự án (Capabilities delivered by projects)
- Các mốc quan trọng và thời gian (Milestones and timing)
- Cấu trúc phân tích công việc (Work breakdown structure)
- Có thể bao gồm tác động đến danh mục đầu tư, chương trình và dự án hiện có (May include impact on existing portfolio, program, and projects)
Nó có thể chứa:
- Điều lệ dự án (Project charters):
- Các gói công việc được bao gồm (Included work packages)
- Giá trị kinh doanh (Business value)
- Rủi ro, vấn đề, giả định, phụ thuộc (Risk, issues, assumptions, dependencies)
- Yêu cầu và chi phí tài nguyên (Resource requirements and costs)
- Lợi ích của việc di chuyển, được xác định (bao gồm ánh xạ đến các yêu cầu kinh doanh) (Benefits of migration, determined (including mapping to business requirements))
- Chi phí ước tính của các lựa chọn di chuyển (Estimated costs of migration options)

4.2.15. Mô hình quản trị triển khai (Implementation Governance Model)¶

4.2.15.1. Mục đích¶

Sau khi một kiến trúc đã được định nghĩa, cần phải lên kế hoạch cách thức Kiến trúc Chuyển đổi (Transition Architecture) thực hiện kiến trúc đó sẽ được quản trị thông qua việc triển khai. Trong các tổ chức đã thiết lập các chức năng kiến trúc, có thể đã có một khuôn khổ quản trị, nhưng các quy trình, tổ chức, vai trò, trách nhiệm và thước đo cụ thể có thể cần được định nghĩa trên cơ sở từng dự án.
Mô hình quản trị triển khai (Implementation Governance Model) đảm bảo rằng một dự án chuyển sang triển khai cũng chuyển đổi một cách suôn sẻ sang Quản trị Kiến trúc (Architecture Governance) phù hợp.

4.2.15.2. Nội dung¶

Nội dung điển hình của một Mô hình quản trị triển khai bao gồm:
Các quy trình quản trị (Governance processes)
Cấu trúc tổ chức quản trị (Governance organization structure)
Các vai trò và trách nhiệm quản trị (Governance roles and responsibilities)
Các điểm kiểm tra quản trị và tiêu chí thành công/thất bại (Governance checkpoints and success/failure criteria)

4.2.16. Mô hình tổ chức cho Kiến trúc Doanh nghiệp (Organizational Model for Enterprise Architecture)¶

4.2.16.1. Mục đích¶

Để một khuôn khổ kiến trúc được sử dụng thành công, nó phải được hỗ trợ bởi tổ chức, vai trò và trách nhiệm đúng đắn trong doanh nghiệp. Điều đặc biệt quan trọng là định nghĩa ranh giới giữa các nhà thực hành Kiến trúc Doanh nghiệp (Enterprise Architecture) khác nhau và các mối quan hệ quản trị trải dài trên các ranh giới này.

4.2.16.2. Nội dung¶

Nội dung điển hình của một Mô hình tổ chức cho Kiến trúc Doanh nghiệp (Organizational Model for Enterprise Architecture) bao gồm:
Phạm vi các tổ chức bị ảnh hưởng (Scope of organizations impacted)
Đánh giá độ chín, các khoảng cách và phương pháp giải quyết (Maturity assessment, gaps, and resolution approach)
Các vai trò và trách nhiệm cho đội ngũ kiến trúc (Roles and responsibilities for architecture team(s))
Các ràng buộc đối với công việc kiến trúc (Constraints on architecture work)
Yêu cầu ngân sách (Budget requirements)
Chiến lược quản trị và hỗ trợ (Governance and support strategy)

4.2.17. Yêu cầu công việc kiến trúc (Request for Architecture Work)¶

4.2.17.1. Mục đích¶

Đây là một tài liệu được gửi từ tổ chức tài trợ đến tổ chức kiến trúc để kích hoạt khởi động một chu trình phát triển kiến trúc. Yêu cầu công việc kiến trúc (Request for Architecture Work) có thể được tạo ra như một đầu ra của Giai đoạn Sơ bộ (Preliminary Phase), là kết quả của các Yêu cầu thay đổi kiến trúc (architecture Change Requests) đã được phê duyệt, hoặc là các điều khoản tham chiếu cho công việc kiến trúc bắt nguồn từ lập kế hoạch di chuyển.
Nói chung, tất cả thông tin trong tài liệu này nên ở cấp độ cao.

4.2.17.2. Nội dung¶

Các Yêu cầu công việc kiến trúc thường bao gồm:
Các nhà tài trợ tổ chức (Organization sponsors)
Tuyên bố sứ mệnh của tổ chức (Organization’s mission statement)
Các mục tiêu kinh doanh (và các thay đổi) (Business goals (and changes))
Các kế hoạch chiến lược của doanh nghiệp (Strategic plans of the business)
Giới hạn thời gian (Time limits)
Các thay đổi trong môi trường kinh doanh (Changes in the business environment)
Các ràng buộc tổ chức (Organizational constraints)
Thông tin ngân sách, các ràng buộc tài chính (Budget information, financial constraints)
Các ràng buộc bên ngoài, các ràng buộc kinh doanh (External constraints, business constraints)
Mô tả hệ thống kinh doanh hiện tại (Current business system description)
Mô tả kiến trúc/hệ thống CNTT hiện tại (Current architecture/IT system description)
Mô tả tổ chức đang phát triển (Description of developing organization)
Mô tả các tài nguyên có sẵn cho tổ chức đang phát triển (Description of resources available to developing organization)

4.2.18. Đánh giá tác động yêu cầu (Requirements Impact Assessment)¶

4.2.18.1. Mục đích¶

Trong suốt ADM, thông tin mới được thu thập liên quan đến một kiến trúc. Khi thông tin này được thu thập, các sự thật mới có thể xuất hiện làm mất hiệu lực các khía cạnh hiện có của kiến trúc. Một Đánh giá tác động yêu cầu (Requirements Impact Assessment) đánh giá các yêu cầu và đặc tả kiến trúc hiện tại để xác định các thay đổi cần được thực hiện và các tác động của những thay đổi đó.

4.2.18.2. Nội dung¶

Nội dung điển hình của một Đánh giá tác động yêu cầu bao gồm:
Tham chiếu đến các yêu cầu cụ thể (Reference to specific requirements)
Ưu tiên của bên liên quan đối với các yêu cầu cho đến nay (Stakeholder priority of the requirements to date)
Các giai đoạn cần xem xét lại (Phases to be revisited)
Giai đoạn dẫn đầu về ưu tiên yêu cầu (Phase to lead on requirements prioritization)
Kết quả điều tra giai đoạn và ưu tiên sửa đổi (Results of phase investigations and revised priorities)
Khuyến nghị về quản lý yêu cầu (Recommendations on management of requirements)
Số tham chiếu kho lưu trữ (Repository reference number)

4.2.19. Các khối xây dựng giải pháp (Solution Building Blocks)¶

Đây là các khối xây dựng cụ thể của việc triển khai từ Kho lưu trữ kiến trúc (Architecture Repository) của doanh nghiệp. Xem Chương 5, Building Blocks (Các khối xây dựng) để biết thêm chi tiết.

4.2.20. Báo cáo công việc kiến trúc (Statement of Architecture Work)¶

4.2.20.1. Mục đích¶

Báo cáo công việc kiến trúc (Statement of Architecture Work) định nghĩa phạm vi và cách tiếp cận sẽ được sử dụng để hoàn thành một chu trình phát triển kiến trúc. Báo cáo công việc kiến trúc thường là tài liệu mà dựa vào đó việc thực hiện thành công dự án kiến trúc sẽ được đo lường và có thể tạo thành cơ sở cho một thỏa thuận hợp đồng giữa nhà cung cấp và người tiêu dùng dịch vụ kiến trúc.

4.2.20.2. Nội dung¶

Nội dung điển hình của một Báo cáo công việc kiến trúc bao gồm:
Tiêu đề (Title)
Yêu cầu và bối cảnh dự án kiến trúc (Architecture project request and background)
Mô tả và phạm vi dự án kiến trúc (Architecture project description and scope)
Tổng quan về Tầm nhìn kiến trúc (Overview of Architecture Vision)
Các quy trình thay đổi phạm vi cụ thể (Specific change of scope procedures)
Các vai trò, trách nhiệm và sản phẩm bàn giao (Roles, responsibilities, and deliverables)
Các tiêu chí và quy trình chấp nhận (Acceptance criteria and procedures)
Kế hoạch và lịch trình dự án kiến trúc (Architecture project plan and schedule)
Phê duyệt (Approvals)

4.2.21. Khung kiến trúc được điều chỉnh (Tailored Architecture Framework)¶

4.2.21.1. Mục đích¶

Khuôn khổ TOGAF cung cấp một tiêu chuẩn ngành cho kiến trúc có thể được sử dụng trong nhiều tổ chức khác nhau. Tuy nhiên, trước khi khuôn khổ TOGAF có thể được sử dụng hiệu quả trong một dự án kiến trúc, việc điều chỉnh (tailoring) ở hai cấp độ là cần thiết.
Đầu tiên, cần phải điều chỉnh mô hình TOGAF để tích hợp vào doanh nghiệp. Việc điều chỉnh này sẽ bao gồm tích hợp với các khuôn khổ quản lý, tùy chỉnh thuật ngữ, phát triển các phong cách trình bày, lựa chọn, cấu hình và triển khai các công cụ kiến trúc, v.v.. Tính hình thức và chi tiết của bất kỳ khuôn khổ nào được áp dụng cũng nên phù hợp với các yếu tố ngữ cảnh khác của doanh nghiệp, chẳng hạn như văn hóa, các bên liên quan, các mô hình thương mại cho Kiến trúc Doanh nghiệp (Enterprise Architecture) và mức độ Năng lực Kiến trúc (Architecture Capability) hiện có.
Sau khi khuôn khổ đã được điều chỉnh cho doanh nghiệp, việc điều chỉnh thêm là cần thiết để điều chỉnh khuôn khổ cho dự án kiến trúc cụ thể. Việc điều chỉnh ở cấp độ này sẽ chọn các sản phẩm bàn giao và tạo phẩm phù hợp để đáp ứng nhu cầu của dự án và các bên liên quan.
Xem Tiêu chuẩn TOGAF — Phương pháp Phát triển Kiến trúc (TOGAF Standard — Architecture Development Method) để biết thêm các cân nhắc khi lựa chọn và điều chỉnh khuôn khổ kiến trúc.

4.2.21.2. Nội dung¶

Nội dung điển hình của một Khuôn khổ kiến trúc được điều chỉnh (Tailored Architecture Framework) bao gồm:
Phương pháp kiến trúc được điều chỉnh (Tailored architecture method)
Nội dung kiến trúc được điều chỉnh (sản phẩm bàn giao và tạo phẩm) (Tailored architecture content (deliverables and artifacts))
Các công cụ được cấu hình và triển khai (Configured and deployed tools)
Giao diện với các mô hình quản trị và các khuôn khổ khác (Interfaces with governance models and other frameworks):
- Lập kế hoạch kinh doanh doanh nghiệp (Corporate Business Planning)
- Kiến trúc Doanh nghiệp (Enterprise Architecture)
- Quản lý danh mục đầu tư, chương trình, dự án (Portfolio, Program, Project Management)
- Phát triển/Kỹ thuật hệ thống (System Development/Engineering)
- Vận hành (Dịch vụ) (Operations (Services))