Skip to content

TOGAF® Standard — Architecture Content

1. Giới thiệu

1.1. Tổng quan

Các kiến trúc sư thực hiện Phương pháp phát triển kiến trúc – ADM (Architecture Development Method) sẽ tạo ra nhiều đầu ra (outputs) từ nỗ lực của mình, chẳng hạn như luồng quy trình (process flows), yêu cầu kiến trúc (architectural requirements), kế hoạch dự án (project plans), hoặc đánh giá tuân thủ dự án (project compliance assessments).

Khung nội dung (Content Framework) cung cấp một mô hình cấu trúc (structural model) cho nội dung kiến trúc, cho phép các sản phẩm công việc (work products) chính mà kiến trúc sư tạo ra được định nghĩa, cấu trúc và trình bày một cách nhất quán.

Khung nội dung được cung cấp ở đây nhằm cho phép khung TOGAF (TOGAF framework) có thể được sử dụng như một khung độc lập (stand-alone framework) cho kiến trúc trong một doanh nghiệp. Tuy nhiên, cũng tồn tại các khung nội dung khác (other Content Frameworks) (ví dụ như Khung Zachman® (Zachman® Framework)), và dự kiến một số doanh nghiệp có thể lựa chọn sử dụng một khung bên ngoài kết hợp với khung TOGAF. Trong những trường hợp đó, Khung nội dung TOGAF (TOGAF Content Framework) cung cấp một tài liệu tham khảo hữu ích và một điểm khởi đầu để ánh xạ nội dung TOGAF sang các khung nội dung khác.

Khung nội dung kiến trúc (Architecture Content Framework) sử dụng ba loại chính để mô tả các sản phẩm công việc kiến trúc trong ngữ cảnh sử dụng:

Sản phẩm bàn giao (Deliverable)

  • Deliverable là một sản phẩm công việc (work product) được quy định theo hợp đồng, và sau đó được xem xét chính thức (formally reviewed), phê duyệt (approved), và ký xác nhận (signed off) bởi các bên liên quan (stakeholders).
  • Deliverables đại diện cho đầu ra (outputs) của dự án. Các deliverables ở dạng tài liệu thường sẽ được lưu trữ (archived) sau khi dự án hoàn thành, hoặc được chuyển vào Kho kiến trúc (Architecture Repository) như một mô hình tham chiếu (reference model), tiêu chuẩn (standard), hoặc ảnh chụp (snapshot) của Bức tranh Kiến trúc tổng thể (Architecture Landscape) tại một thời điểm nhất định.

Tạo phẩm (Artifact)

  • Artifact là một sản phẩm công việc kiến trúc (architectural work product) mô tả một khía cạnh (aspect) của kiến trúc.
  • Artifacts thường được phân loại thành:
  • Danh mục (catalogs): danh sách các thành phần
  • Ma trận (matrices): thể hiện các mối quan hệ giữa các thành phần
  • Sơ đồ (diagrams): hình ảnh trực quan mô tả các thành phần
  • Ví dụ: Danh mục yêu cầu (requirements catalog), Ma trận tương tác ứng dụng (application interaction matrix), Sơ đồ chuỗi giá trị (value chain diagram).
  • Một deliverable kiến trúc có thể chứa nhiều artifacts, và các artifacts này sẽ tạo thành nội dung (content) của Kho kiến trúc (Architecture Repository).

Khối xây dựng (Building Block)

  • Building block là một thành phần có khả năng tái sử dụng (re-usable component), có thể được kết hợp với các building blocks khác để xây dựng nên kiến trúc (architectures) và giải pháp (solutions).
  • Building blocks có thể được định nghĩa ở nhiều cấp độ chi tiết khác nhau, tùy thuộc vào giai đoạn phát triển kiến trúc:
  • Ở giai đoạn đầu: một building block có thể chỉ bao gồm tên hoặc mô tả sơ lược (outline description).
  • Ở giai đoạn sau: một building block có thể được phân rã (decomposed) thành nhiều building blocks hỗ trợ (supporting building blocks) và có thể đi kèm với đặc tả đầy đủ (full specification).
  • Building blocks có thể liên quan đến cả kiến trúc (architectures) và giải pháp (solutions).
Khối xây dựng kiến trúc (Architecture Building Blocks – ABBs)
  • Thường mô tả yêu cầu (requirements) đối với các SBBs ở mức logic hoặc độc lập với nhà cung cấp (supplier-independent level).
  • Những yêu cầu này có thể bao gồm:
  • Dịch vụ (services) cần thực hiện,
  • Nguồn dữ liệu (data resources),
  • Năng lực (capabilities) cần thiết.
  • ABBs bao gồm các thành phần logic về nghiệp vụ (business), ứng dụng (application), và công nghệ (technology).
Khối xây dựng giải pháp (Solution Building Blocks – SBBs)
  • Đại diện cho các thành phần vật lý (physical components) hoặc thành phần phụ thuộc nhà cung cấp (supplier-specific components), có khả năng hiện thực hóa một phần hoặc toàn bộ ABB logic.
  • Có các loại SBBs thuộc: nghiệp vụ (business), ứng dụng (application), và công nghệ (technology).

Mối quan hệ giữa Deliverables, Artifacts và Building Blocks được thể hiện trong Hình 1-1.

Figure 1-1: Relationships between Deliverables, Artifacts, and Building Blocks Hình 1-1: Mối quan hệ giữa Deliverables, Artifacts và Building Blocks

Ví dụ, một Tài liệu Định nghĩa Kiến trúc (Architecture Definition Document) là một sản phẩm bàn giao (deliverable) dùng để ghi lại một Mô tả Kiến trúc (Architecture Description).

Tài liệu này sẽ bao gồm một số tạo phẩm (artifacts) bổ sung, thể hiện các quan điểm kiến trúc (architecture views) của các khối xây dựng (building blocks) có liên quan đến kiến trúc. Ví dụ, một sơ đồ luồng quy trình (process flow diagram, một artifact) có thể được tạo ra để mô tả quy trình xử lý cuộc gọi mục tiêu (target call handling process, một building block*). Tạo phẩm này cũng có thể mô tả các khối xây dựng khác, chẳng hạn như các tác nhân (actors) tham gia trong quy trình (ví dụ: một Đại diện Dịch vụ Khách hàng – Customer Services Representative).

Một ví dụ về mối quan hệ giữa deliverables, artifacts, và building blocks được minh họa trong Hình 1-2.

Figure 1-2: Example — Architecture Definition Document Hình 1-2: Ví dụ — Tài liệu Định nghĩa Cấu trúc

1.2. Khung nội dung TOGAF và Siêu mô hình doanh nghiệp (TOGAF Content Framework and Enterprise Metamodel)

1.2.1. Tổng quan

TOGAF ADM (Architecture Development Method) cung cấp cơ chế quản lý vòng đời (lifecycle management) để tạo và quản lý các kiến trúc trong một doanh nghiệp.
Ở mỗi giai đoạn trong ADM, phần thảo luận về đầu vào (inputs), đầu ra (outputs), và các bước thực hiện (steps) mô tả một số sản phẩm công việc kiến trúc (architecture work products).

Một nhiệm vụ thiết yếu khi thiết lập Năng lực Kiến trúc Doanh nghiệp đặc thù cho tổ chức (enterprise-specific Enterprise Architecture Capability) trong Giai đoạn Sơ bộ (Preliminary Phase) của ADM là xác định:

  • Một khung phân loại (categorization framework) được sử dụng để cấu trúc Mô tả Kiến trúc (Architecture Descriptions), các sản phẩm công việc (work products) được dùng để thể hiện kiến trúc, và tập hợp các mô hình (models) mô tả kiến trúc; khung này được gọi là Khung nội dung (Content Framework).
  • Một sự hiểu biết về các thực thể (entities) trong doanh nghiệp và các mối quan hệ (relationships) giữa chúng cần được ghi lại, lưu trữ và phân tích để tạo ra Mô tả Kiến trúc (Architecture Description); Siêu mô hình doanh nghiệp (Enterprise Metamodel) thể hiện thông tin này dưới dạng một mô hình chính thức.
  • Các tạo phẩm cụ thể (specific artifacts) cần được phát triển (xem Chương 4, Sản phẩm bàn giao kiến trúc – Architecture Deliverables).

Khung nội dung được lựa chọn có thể chịu ảnh hưởng bởi:

  • Khung kiến trúc (Architecture Framework) được chọn làm nền tảng cho Năng lực Kiến trúc Doanh nghiệp
  • Công cụ phần mềm (software tool) được lựa chọn để hỗ trợ năng lực kiến trúc doanh nghiệp

1.2.2. Khung nội dung (Content Framework)

Khung nội dung (Content Framework) định nghĩa một khung phân loại (categorization framework) được dùng để cấu trúc Mô tả Kiến trúc (Architecture Description), các sản phẩm công việc (work products) được dùng để thể hiện kiến trúc, và tập hợp các mô hình (models) mô tả kiến trúc.

Kho Kiến trúc (Architecture Repository), được giải thích trong Mục 4.2.5, “Architecture Repository”, được cấu trúc để lưu trữ các tạo phẩm (artifacts) và sản phẩm công việc (work products) được xác định trong Khung nội dung.

Khung nội dung là một thành phần của Khung Kiến trúc đặc thù cho tổ chức (Enterprise-Specific Architecture Framework).

1.2.3. Siêu mô hình doanh nghiệp (Enterprise Metamodel)

TOGAF Standard khuyến khích phát triển một Siêu mô hình doanh nghiệp (Enterprise Metamodel), trong đó định nghĩa các loại thực thể (types of entity) xuất hiện trong các mô hình (models) mô tả doanh nghiệp, cùng với mối quan hệ (relationships) giữa các thực thể đó.

Một Siêu mô hình doanh nghiệp mang lại giá trị theo nhiều cách:

  • Nó cung cấp cho kiến trúc sư một bộ khởi đầu về các loại đối tượng cần nghiên cứu và bao phủ trong mô hình của họ.
  • Nó cung cấp một hình thức kiểm tra tính đầy đủ (completeness-check) cho bất kỳ ngôn ngữ mô hình kiến trúc (architecture modeling language) hay siêu mô hình kiến trúc (architecture metamodel) nào được đề xuất sử dụng trong một doanh nghiệp.

Cụ thể: mức độ bao phủ của nó đối với các loại thực thể trong Siêu mô hình doanh nghiệp đến đâu, và khả năng quản lý các thông tin cần thiết về chúng như thuộc tính (attributes) và mối quan hệ (relationships) ra sao.

  • Nó có thể giúp đảm bảo:
  • Tính nhất quán (Consistency)
  • Tính đầy đủ (Completeness)
  • Khả năng truy vết (Traceability)

Lưu ý rằng TOGAF Standard không nhằm ràng buộc doanh nghiệp trong việc lựa chọn:

  • Tạo phẩm (artifacts)
  • Ký pháp mô hình (modeling notation)

TOGAF Standard có thể được sử dụng cùng với:

  • Ngôn ngữ mô hình ArchiMate® (ArchiMate modeling language)
  • Business Process Model and Notation™ (BPMN™)
  • Unified Modeling Language™ (UML®)
  • Sơ đồ quan hệ thực thể (entity relationship diagramming)
  • Lưu đồ (flowcharting)
  • Hoặc bất kỳ ký pháp nào khác có thể diễn đạt được các khái niệm của TOGAF.

Các loại thực thể trong một doanh nghiệp và mối quan hệ giữa chúng là đặc thù cho từng doanh nghiệp riêng lẻ.
Phát triển một siêu mô hình chất lượng cao (high-quality metamodel) là một khía cạnh quan trọng trong việc thiết lập Năng lực Kiến trúc Doanh nghiệp (Enterprise Architecture Capability).

1.2.4. Khung nội dung TOGAF (The TOGAF Content Framework)

Khung nội dung TOGAF (TOGAF Content Framework) định nghĩa một khung phân loại (categorization framework) để cấu trúc Mô tả Kiến trúc (Architecture Description), các sản phẩm công việc (work products) để thể hiện kiến trúc, và tập hợp các mô hình (models) mô tả kiến trúc.

Có nhiều Khung nội dung thay thế (alternative Content Frameworks), ví dụ:

  • TOGAF Content Framework
  • Zachman Framework
  • DoDAF
  • NAF

Việc lựa chọn một Khung nội dung là cần thiết, mặc dù bản thân việc chọn khung nào là ít quan trọng hơn.
Khung nội dung cuối cùng thường sẽ được điều chỉnh để phù hợp với nhu cầu cụ thể của tổ chức.

Khung nội dung TOGAF được thiết kế nhằm:

  • Cung cấp một mô hình chi tiết về các sản phẩm công việc kiến trúc (architectural work products)
  • Dẫn dắt tính nhất quán trong các đầu ra (outputs) được tạo khi tuân theo ADM
  • Cung cấp một danh sách kiểm tra toàn diện (comprehensive checklist) các đầu ra kiến trúc có thể được tạo ra
  • Giảm rủi ro xuất hiện khoảng trống (gaps) trong bộ sản phẩm bàn giao kiến trúc cuối cùng
  • Hỗ trợ một doanh nghiệp trong việc quy định các khái niệm, thuật ngữ, và sản phẩm bàn giao kiến trúc chuẩn hóa

Ở cấp độ cao nhất, Khung nội dung TOGAF (xem Hình 1-3) được cấu trúc phù hợp với các giai đoạn của ADM.

Figure 1-3: Content Framework by ADM Phase Hình 1-3: Khung nội dung theo giai đoạn ADM

  • Nguyên tắc Kiến trúc, Tầm nhìn, Mô hình Động lực và Yêu cầu (Architecture Principles, Vision, Motivation, and Requirements models) nhằm mục đích nắm bắt bối cảnh xung quanh của các mô hình kiến trúc chính thức, bao gồm các Nguyên tắc Kiến trúc chung (general Architecture Principles), bối cảnh chiến lược (strategic context) tạo đầu vào cho việc mô hình hóa kiến trúc, và các yêu cầu (requirements) được tạo ra từ kiến trúc.

Các khía cạnh liên quan của bối cảnh kinh doanh (business context) vốn là cơ sở cho Yêu cầu về công việc kiến trúc (Request for Architecture work) thường được khảo sát, tinh chỉnh, xác nhận và ghi lại trong Giai đoạn Sơ bộ (Preliminary Phase) và Giai đoạn Tầm nhìn Kiến trúc (Architecture Vision phase).

  • Kiến trúc nghiệp vụ (Business Architecture) nắm bắt các mô hình kiến trúc của doanh nghiệp, tập trung cụ thể vào những yếu tố thúc đẩy tổ chức, cấu trúc của nó và các năng lực (capabilities) của nó.

  • Mô hình Kiến trúc Hệ thống Thông tin (Information Systems Architecture models) nắm bắt các mô hình kiến trúc của hệ thống CNTT, tập trung vào ứng dụng (applications) và dữ liệu (data) phù hợp với các giai đoạn của TOGAF ADM.

  • Mô hình Kiến trúc Công nghệ (Technology Architecture models) nắm bắt các tài sản công nghệ (technology assets) được sử dụng để triển khai và hiện thực hóa các giải pháp hệ thống thông tin.

  • Mô hình Hiện thực hóa/Chuyển đổi Kiến trúc (Architecture Realization/Transformation models) nắm bắt các lộ trình thay đổi (change roadmaps) thể hiện sự chuyển tiếp giữa các trạng thái kiến trúc, cũng như các cam kết điều hướng (binding statements) được sử dụng để dẫn dắt và quản trị việc triển khai kiến trúc.

  • Mô hình Quản lý Thay đổi Kiến trúc (Architecture Change Management models) nắm bắt các sự kiện quản lý hiện thực hóa giá trị (value realization management events), cả bên trong lẫn bên ngoài, tác động đến Kiến trúc Doanh nghiệp (Enterprise Architecture) và việc phát sinh yêu cầu hành động (requirements for action).

Figure 1-4: Content Framework Overview Hình 1-4: Tổng quan Khung Nội dung

1.3. Khung Nội dung và TOGAF ADM (Content Framework and the TOGAF ADM)

TOGAF ADM (Architecture Development Method) mô tả quy trình chuyển đổi từ trạng thái cơ sở (baseline state) của doanh nghiệp sang trạng thái mục tiêu (target state) của doanh nghiệp.

ADM sẽ giải quyết một nhu cầu kinh doanh thông qua quy trình hình thành tầm nhìn (visioning), định nghĩa kiến trúc (architecture definition), lập kế hoạch chuyển đổi (transformation planning), và quản trị kiến trúc (Architecture Governance).

Ở mỗi giai đoạn trong quy trình này, ADM yêu cầu thông tin đầu vào (inputs) và sẽ tạo ra các kết quả đầu ra (outputs) như là kết quả của việc thực thi một loạt các bước. Khung Nội dung (Content Framework) cung cấp một cấu trúc nền tảng cho ADM nhằm định nghĩa chi tiết hơn các đầu vào và đầu ra, đồng thời đặt từng sản phẩm bàn giao (deliverable) vào trong ngữ cảnh của tầm nhìn kiến trúc tổng thể (holistic architecture view) của doanh nghiệp.

Do đó, Khung Nội dung nên được sử dụng như một công cụ đồng hành (companion) với ADM. ADM mô tả những việc cần làm để tạo ra một kiến trúc, trong khi Khung Nội dung mô tả kiến trúc sẽ trông như thế nào khi hoàn thành.

1.4. Liên tục Doanh nghiệp (The Enterprise Continuum)

Thông thường, việc tạo ra một kiến trúc hợp nhất duy nhất để đáp ứng tất cả các yêu cầu của tất cả các bên liên quan trong mọi thời điểm là điều không thể. Vì vậy, Kiến trúc sư Doanh nghiệp (Enterprise Architect) sẽ cần phải xử lý không chỉ một Kiến trúc Doanh nghiệp duy nhất, mà là nhiều Kiến trúc Doanh nghiệp có liên quan (related Enterprise Architectures).

Mỗi kiến trúc có thể có một mục đích khác nhau và các kiến trúc này có thể liên kết với nhau. Việc xác định phạm vi (bounding the scope) của một kiến trúc một cách hiệu quả do đó là một Yếu tố Thành công Quan trọng (Critical Success Factor - CSF), cho phép các kiến trúc sư chia nhỏ không gian vấn đề phức tạp thành các thành phần có thể quản lý được và có thể được xử lý riêng biệt.

Liên tục Doanh nghiệp (Enterprise Continuum) cung cấp một góc nhìn về Kho Kiến trúc (Architecture Repository), thể hiện sự tiến hóa của các kiến trúc có liên quan này từ tổng quát đến cụ thể (generic to specific), từ trừu tượng đến cụ thể hóa (abstract to concrete), và từ logic đến vật lý (logical to physical).

Chương 6, Enterprise Continuum sẽ thảo luận về Liên tục Doanh nghiệp, bao gồm Liên tục Kiến trúc (Architecture Continuum) và Liên tục Giải pháp (Solutions Continuum).

1.5. Kho Kiến trúc (The Architecture Repository)

Vận hành một Năng lực Kiến trúc (Architecture Capability) trưởng thành trong một doanh nghiệp lớn tạo ra một khối lượng rất lớn các sản phẩm kiến trúc. Việc quản lý và khai thác hiệu quả các sản phẩm này đòi hỏi một phân loại chính thức (formal taxonomy) cho các loại tài sản kiến trúc (architectural assets) khác nhau, cùng với các quy trình và công cụ chuyên dụng (dedicated processes and tools) để lưu trữ nội dung kiến trúc.

Chương 7, Architecture Repository cung cấp một khung cấu trúc (structural framework) cho Kho Kiến trúc (Architecture Repository), cho phép doanh nghiệp phân biệt giữa các loại tài sản kiến trúc tồn tại ở các cấp độ trừu tượng khác nhau (different levels of abstraction) trong tổ chức.