TOGAF® Standard — Architecture Content¶
3. Architectural Artifacts¶
Chương "3. Architectural Artifacts" của Tiêu chuẩn TOGAF® – Nội dung Kiến trúc thảo luận về các khái niệm xoay quanh các hiện vật kiến trúc và mô tả các hiện vật được khuyến nghị tạo ra cho mỗi giai đoạn trong Phương pháp Phát triển Kiến trúc (ADM).
3.1. Các Khái Niệm Cơ Bản (Basic Concepts)¶
Các hiện vật kiến trúc được tạo ra để mô tả hệ thống, giải pháp hoặc trạng thái của doanh nghiệp. Các khái niệm được thảo luận trong phần này đã được điều chỉnh từ các định nghĩa chính thức hơn trong ISO/IEC/IEEE 42010:2022 và ISO/IEC/IEEE 15288:2015.
Hình 3-1: Các khái niệm cơ bản về kiến trúc
- Architectural artifacts (Hiện vật kiến trúc): Là các sản phẩm được tạo ra để mô tả một hệ thống, một giải pháp hoặc trạng thái của doanh nghiệp.
- Environment (Môi trường): Là bối cảnh xác định cài đặt và hoàn cảnh của tất cả các ảnh hưởng đến một hệ thống. Môi trường của một hệ thống bao gồm các ảnh hưởng về phát triển, công nghệ, kinh doanh, vận hành, tổ chức, chính trị, kinh tế, pháp lý, quy định, sinh thái và xã hội.
- System (Hệ thống): Là sự kết hợp của các yếu tố tương tác được tổ chức để đạt được một hoặc nhiều mục đích đã nêu.
- Architecture (Kiến trúc): Là các khái niệm hoặc thuộc tính cơ bản của một hệ thống trong môi trường của nó, được thể hiện trong các yếu tố, mối quan hệ và trong các nguyên tắc thiết kế và tiến hóa của nó.
- Architecture Description (Mô tả Kiến trúc): Là một sản phẩm công việc được sử dụng để thể hiện một kiến trúc; một tập hợp các chế độ xem kiến trúc (architecture views) và các mô hình (models) cùng nhau ghi lại kiến trúc.
- Stakeholders (Các bên liên quan): Là các cá nhân, nhóm, tổ chức hoặc các lớp của chúng, có lợi ích trong một hệ thống.
- Concerns (Mối quan tâm): Là những lợi ích trong một hệ thống có liên quan đến một hoặc nhiều bên liên quan của nó. Các mối quan tâm có thể liên quan đến bất kỳ khía cạnh nào của chức năng, phát triển hoặc vận hành hệ thống, bao gồm các cân nhắc như hiệu suất, độ tin cậy, bảo mật, phân phối và khả năng phát triển, và có thể xác định tính chấp nhận của hệ thống.
- Architecture view (Chế độ xem kiến trúc): Là một biểu diễn của một hệ thống từ góc độ của một tập hợp các mối quan tâm liên quan. Nó bao gồm một hoặc nhiều mô hình kiến trúc của hệ thống. Một chế độ xem kiến trúc sẽ bao gồm các phần được chọn từ một hoặc nhiều mô hình, được lựa chọn để chứng minh cho một bên liên quan hoặc nhóm các bên liên quan cụ thể rằng các mối quan tâm của họ đang được giải quyết đầy đủ trong thiết kế kiến trúc hệ thống.
- Architecture Model (Mô hình Kiến trúc): Là một biểu diễn của một chủ đề quan tâm. Một mô hình cung cấp một biểu diễn thu nhỏ, đơn giản hóa và/hoặc trừu tượng của chủ đề.
- Architecture viewpoint (Điểm nhìn kiến trúc): Là một đặc tả các quy ước cho một loại chế độ xem kiến trúc cụ thể. Nó cũng có thể được gọi là định nghĩa hoặc lược đồ cho loại chế độ xem kiến trúc đó. Nó thiết lập các quy ước để xây dựng, diễn giải và sử dụng một chế độ xem kiến trúc để giải quyết một mối quan tâm cụ thể (hoặc tập hợp các mối quan tâm) về một hệ thống quan tâm.
- Model Kind (Loại Mô hình): Thiết lập các quy ước cho một loại mô hình hóa.
- Viewpoint library (Thư viện điểm nhìn): Là một bộ sưu tập các đặc tả điểm nhìn kiến trúc có trong phần Reference Library của Kho lưu trữ Kiến trúc (Architecture Repository).
Sự khác biệt giữa architecture view và architecture viewpoint:
- Một architecture view là những gì bạn thấy; một architecture viewpoint là nơi bạn đang nhìn từ đó – điểm thuận lợi hoặc góc nhìn xác định những gì bạn thấy.
- Các điểm nhìn kiến trúc (architecture viewpoints) là chung chung và có thể được lưu trữ trong thư viện để tái sử dụng; một chế độ xem kiến trúc (architecture view) luôn cụ thể cho kiến trúc mà nó được tạo ra.
- Mọi chế độ xem kiến trúc đều có một điểm nhìn kiến trúc liên quan mô tả nó, ít nhất là một cách ngầm định. Việc định nghĩa rõ ràng các điểm nhìn kiến trúc được khuyến khích bởi ISO/IEC/IEEE 42010:2022 để tái sử dụng chúng qua các kiến trúc khác nhau.
- Tóm lại, các chế độ xem kiến trúc là biểu diễn của kiến trúc tổng thể theo những ý nghĩa mà các bên liên quan hiểu được, giúp họ xác minh rằng hệ thống sẽ giải quyết các mối quan tâm của họ. Các mối quan tâm thường liên quan đến các yêu cầu và giúp đảm bảo lợi ích của các bên liên quan được giải quyết.
Một ví dụ đơn giản minh họa là điểm nhìn kiến trúc về các lĩnh vực kinh doanh của The Open Group, thể hiện các mối quan hệ cấp cao giữa các địa điểm địa lý và chức năng kinh doanh bằng sơ đồ hộp lồng nhau.
Góc nhìn về kiến trúc được thể hiện như trong Bảng 3-1.
Bảng 3-1: Ví dụ về Điểm nhìn Kiến trúc
| Architecture Viewpoint Element | Description |
|---|---|
| Stakeholders | Management Board, Chief Executive Officer |
| Concerns | Show the top-level relationships between US/UK geographical sites and business functions. |
| Modeling technique | Nested boxes diagram. Outer boxes = locations; inner boxes = business functions. Semantics of nesting = functions performed in the locations. |
Khung kiến trúc tương ứng của The Open Group (năm 2017) được trình bày trong Hình 3-2.
Hình 3-2: Ví dụ về quan điểm kiến trúc — Các lĩnh vực kinh doanh của The Open Group
3.2. Phát triển Chế độ xem Kiến trúc trong ADM (Developing Architecture Views in the ADM)¶
Kiến trúc sư có trách nhiệm đảm bảo sự đầy đủ (phù hợp với mục đích) và tính toàn vẹn của kiến trúc, giải quyết các mối quan tâm của các bên liên quan, và dung hòa các mối quan tâm mâu thuẫn. Quá trình phát triển các chế độ xem kiến trúc là một quá trình lặp đi lặp lại, thường đi từ kinh doanh đến công nghệ và từ tổng quan cấp cao đến chi tiết cấp thấp. Các chế độ xem kiến trúc phải được phát triển cho cả môi trường hiện có (baseline) và môi trường mục tiêu (target) để hỗ trợ phân tích khoảng trống (gap analysis).
Việc tạo ra các chế độ xem có thể theo các bước sau nếu tổ chức đã áp dụng ISO/IEC/IEEE 42010:2022 và có thư viện các điểm nhìn kiến trúc:
- Tham khảo thư viện các điểm nhìn kiến trúc hiện có.
- Chọn các điểm nhìn kiến trúc thích hợp dựa trên các bên liên quan và mối quan tâm cần được đề cập.
- Tạo các chế độ xem của hệ thống bằng cách sử dụng các điểm nhìn kiến trúc đã chọn làm mẫu.
Lợi ích của cách tiếp cận này bao gồm giảm công việc cho kiến trúc sư, dễ hiểu hơn cho các bên liên quan và tăng sự tin cậy vào tính hợp lệ của các chế độ xem. Tuy nhiên, trong trường hợp không có điểm nhìn kiến trúc phù hợp hoặc tổ chức chưa áp dụng tiêu chuẩn, kiến trúc sư có thể phát triển một điểm nhìn mới hoặc tạo một chế độ xem ad hoc và sau đó xem xét việc định nghĩa rõ ràng điểm nhìn ngầm định để tái sử dụng.
3.3. Chế độ xem, Công cụ và Ngôn ngữ (Views, Tools, and Languages)¶
Để đạt được các mục tiêu về tính đầy đủ và toàn vẹn trong kiến trúc, các chế độ xem kiến trúc thường được phát triển, trực quan hóa, truyền đạt và quản lý bằng cách sử dụng công cụ. Điều mong muốn là Mô tả Kiến trúc được mã hóa bằng một ngôn ngữ tiêu chuẩn để cho phép một cách tiếp cận tiêu chuẩn để mô tả ngữ nghĩa kiến trúc và tái sử dụng chúng giữa các công cụ khác nhau. Các điểm nhìn kiến trúc tiêu chuẩn (tức là các mẫu hoặc lược đồ) cũng nên được phát triển để các công cụ khác nhau có thể tương tác.
3.4. Chế độ xem Kiến trúc và Điểm nhìn Kiến trúc (Architecture Views and Architecture Viewpoints)¶
Phần này minh họa các khái niệm bằng ví dụ về một hệ thống sân bay đơn giản với hai bên liên quan khác nhau: phi công và kiểm soát viên không lưu.
- Điểm nhìn của phi công: Tập trung vào các mối quan tâm như hành khách và nhiên liệu, mô tả hệ thống từ góc độ vị trí và hướng bay đối với đường băng, sử dụng một ngôn ngữ cụ thể.
- Điểm nhìn của kiểm soát viên không lưu: Tập trung vào các máy bay khác, mô tả hệ thống bằng mô hình không gian và vị trí, hướng bay của máy bay trong không gian, cũng sử dụng một ngôn ngữ chung.
- Cả hai điểm nhìn này không mô tả hoàn chỉnh toàn bộ hệ thống vì mỗi góc nhìn giới hạn cách mỗi bên thấy hệ thống. Tuy nhiên, có những yếu tố được chia sẻ, như mô hình giao tiếp giữa phi công và kiểm soát viên, và thông tin quan trọng về máy bay.
- Các công cụ được sử dụng để hỗ trợ các bên liên quan, ví dụ: các chỉ số nhiên liệu, độ cao, tốc độ cho phi công; radar cho kiểm soát viên; và radio là công cụ chung.
Áp dụng ví dụ này vào Kiến trúc Doanh nghiệp, có thể xem xét điểm nhìn của người dùng (users) và nhà phát triển (developers) đối với một hệ thống máy tính mới.
- Điểm nhìn của người dùng: Phản ánh các mối quan tâm khi tương tác với hệ thống, không thấy các chi tiết như ứng dụng hay hệ thống quản lý cơ sở dữ liệu (DBMS). Họ mô tả hệ thống bằng mô hình về tính khả dụng, thời gian phản hồi và quyền truy cập thông tin.
- Điểm nhìn của nhà phát triển: Tập trung vào năng suất và công cụ, không bao gồm dữ liệu thực tế hoặc kết nối với người tiêu dùng. Họ mô tả hệ thống bằng mô hình phần mềm kết nối với phần cứng phân tán qua mạng.
- Vẫn có những điểm chung như mô tả các quy trình được hệ thống hỗ trợ hoặc giao thức truyền thông.
- Sự thiếu hụt một ngôn ngữ chung và các công cụ có thể tương tác là một thách thức lớn trong bối cảnh hiện tại của thị trường công cụ.
3.5. Kết luận¶
Khung TOGAF chấp nhận các khái niệm và định nghĩa được trình bày trong ISO/IEC/IEEE 42010:2022, đặc biệt là các khái niệm giúp hướng dẫn phát triển một chế độ xem kiến trúc và làm cho nó có thể hành động được. Các khái niệm này bao gồm:
- Chọn một bên liên quan chính.
- Hiểu các mối quan tâm của họ và tổng quát hóa/ghi lại các mối quan tâm đó.
- Hiểu cách mô hình hóa và giải quyết các mối quan tâm đó.
3.6. Các Hiện vật Kiến trúc theo Giai đoạn ADM (Architectural Artifacts by ADM Phase)¶
Phần này mô tả các hiện vật được khuyến nghị tạo ra cho mỗi giai đoạn của ADM. Để đáp ứng nhu cầu của các bên liên quan, TOGAF sử dụng các khái niệm về khối xây dựng, danh mục, ma trận và sơ đồ.
- Building blocks (Khối xây dựng): Là các thực thể của một loại cụ thể trong metamodel (ví dụ: một dịch vụ kinh doanh gọi là “Đơn đặt hàng”). Khối xây dựng mang siêu dữ liệu (metadata) theo metamodel, hỗ trợ truy vấn và phân tích.
- Catalogs (Danh mục): Là danh sách các khối xây dựng của một loại cụ thể hoặc các loại liên quan, được sử dụng cho mục đích quản trị hoặc tham chiếu (ví dụ: sơ đồ tổ chức). Danh mục cũng mang siêu dữ liệu theo metamodel.
- Matrices (Ma trận): Là các lưới hiển thị mối quan hệ giữa hai hoặc nhiều thực thể mô hình. Ma trận được sử dụng để biểu diễn các mối quan hệ dựa trên danh sách thay vì đồ họa (ví dụ: ma trận CRUD hiển thị ứng dụng nào Tạo, Đọc, Cập nhật, Xóa một loại dữ liệu cụ thể).
- Diagrams (Sơ đồ): Là các bản thể hiện nội dung kiến trúc dưới dạng đồ họa để cho phép các bên liên quan truy xuất thông tin cần thiết. Sơ đồ cũng có thể được sử dụng làm kỹ thuật để điền nội dung kiến trúc một cách đồ họa hoặc để kiểm tra tính đầy đủ của thông tin đã thu thập.
Các khối xây dựng, danh mục, ma trận và sơ đồ đều được hỗ trợ tốt bởi các công cụ Kiến trúc Doanh nghiệp hàng đầu, cho phép tìm kiếm, lọc và truy vấn kho lưu trữ kiến trúc.
Hình 3-3: Các tương tác giữa Metamodel, Các khối xây dựng, Đồ họa và Các bên liên quan
Hình 3-4: Các hiện vật liên quan đến mô hình meta của doanh nghiệp
Chương này sau đó liệt kê các danh mục, ma trận và sơ đồ cụ thể được khuyến nghị tạo ra trong từng giai đoạn của ADM:
- Preliminary Phase (Giai đoạn Sơ bộ): Ví dụ, Principles Catalog (Danh mục Nguyên tắc) để ghi lại các nguyên tắc của Kinh doanh và Kiến trúc.
- Phase A: Architecture Vision (Giai đoạn A: Tầm nhìn Kiến trúc): Bao gồm Stakeholder Catalog (Danh mục Bên liên quan), Value Chain Diagram (Sơ đồ Chuỗi giá trị), Solution Concept Diagram (Sơ đồ Khái niệm Giải pháp), v.v..
- Phase B: Business Architecture (Giai đoạn B: Kiến trúc Kinh doanh): Bao gồm Organization/Actor Catalog (Danh mục Tổ chức/Tác nhân), Driver/Goal/Objective Catalog (Danh mục Động lực/Mục tiêu/Mục đích), Business Interaction Matrix (Ma trận Tương tác Kinh doanh), Business Footprint Diagram (Sơ đồ Dấu ấn Kinh doanh), v.v..
- Phase C: Data Architecture (Giai đoạn C: Kiến trúc Dữ liệu): Bao gồm Data Entity/Data Component Catalog (Danh mục Thực thể Dữ liệu/Thành phần Dữ liệu), Data Entity/Business Function Matrix (Ma trận Thực thể Dữ liệu/Chức năng Kinh doanh), Conceptual Data Diagram (Sơ đồ Dữ liệu Khái niệm), Data Security Diagram (Sơ đồ Bảo mật Dữ liệu), v.v..
- Phase C: Application Architecture (Giai đoạn C: Kiến trúc Ứng dụng): Bao gồm Application Portfolio Catalog (Danh mục Danh mục Ứng dụng), Interface Catalog (Danh mục Giao diện), Application/Organization Matrix (Ma trận Ứng dụng/Tổ chức), Application Communication Diagram (Sơ đồ Giao tiếp Ứng dụng), v.v..
- Phase D: Technology Architecture (Giai đoạn D: Kiến trúc Công nghệ): Bao gồm Technology Standards Catalog (Danh mục Tiêu chuẩn Công nghệ), Technology Portfolio Catalog (Danh mục Danh mục Công nghệ), Application/Technology Matrix (Ma trận Ứng dụng/Công nghệ), Networked Computing/Hardware Diagram (Sơ đồ Máy tính Nối mạng/Phần cứng), v.v..
- Phase E: Opportunities and Solutions (Giai đoạn E: Cơ hội và Giải pháp): Bao gồm Project Context Diagram (Sơ đồ Bối cảnh Dự án), Benefits Diagram (Sơ đồ Lợi ích), Consolidated Gaps, Solutions, and Dependencies Matrix (Ma trận Tổng hợp Các khoảng trống, Giải pháp và Phụ thuộc), v.v..
- Phase F: Migration Planning (Giai đoạn F: Lập kế hoạch Di chuyển): Bao gồm Transition Architecture State Evolution Table (Bảng Tiến hóa Trạng thái Kiến trúc Chuyển đổi), Business Value and Risk Matrix (Ma trận Giá trị Kinh doanh và Rủi ro).
- Requirements Management (Quản lý Yêu cầu): Bao gồm Requirements Catalog (Danh mục Yêu cầu).