Skip to content

TOGAF® Standard — Applying the ADM


4. Phân vùng Kiến trúc (Architecture Partitioning)

4.1. Tổng quan

Phân vùng (Partitions) được sử dụng để đơn giản hóa việc phát triển và quản lý Kiến trúc Doanh nghiệp (Enterprise Architecture). Chúng nằm ở nền tảng của Quản trị Kiến trúc (Architecture Governance) và khác biệt với các khái niệm về các cấp độ (levels) và tổ chức của Sự liên tục của Kiến trúc (Architecture Continuum).

Kiến trúc được phân vùng vì các lý do sau:

  • Các kiến trúc đơn vị tổ chức (Organizational unit architectures) có thể xung đột lẫn nhau.
  • Các nhóm khác nhau (Different teams) cần làm việc trên các yếu tố kiến trúc khác nhau cùng một lúc, và các phân vùng cho phép các nhóm kiến trúc sư cụ thể sở hữu và phát triển các yếu tố kiến trúc cụ thể (own and develop specific elements of the architecture).
  • Tái sử dụng kiến trúc hiệu quả (Effective architecture re-use) đòi hỏi các phân đoạn kiến trúc mô-đun (modular architecture segments) có thể được tích hợp vào các kiến trúc và giải pháp rộng hơn.

Không có một mô hình phân vùng kiến trúc định nghĩa nào, vì mỗi doanh nghiệp nên áp dụng một mô hình phản ánh mô hình hoạt động (operating model) của riêng mình. Mục tiêu là sử dụng các tiêu chí phân loại (classification criteria) để phân vùng doanh nghiệp thành một tập hợp các kiến trúc với độ phức tạp có thể quản lý được (manageable complexity) và quản trị hiệu quả (effective governance).

4.2. Áp dụng phân loại để tạo Kiến trúc được phân vùng (Applying Classification to Create Partitioned Architectures)

Việc phân vùng và tổ chức Sự liên tục của Doanh nghiệp (Enterprise Continuum) thành một tập hợp các giải pháp và kiến trúc liên quan mang lại giá trị với:

  • Độ phức tạp có thể quản lý được (Manageable complexity) cho mỗi kiến trúc hoặc giải pháp riêng lẻ.
  • Các nhóm được xác định (Defined groupings).
  • Các hệ thống phân cấp và cấu trúc điều hướng được xác định (Defined hierarchies and navigation structures).
  • Các quy trình, vai trò và trách nhiệm thích hợp gắn liền với mỗi nhóm (Appropriate processes, roles, and responsibilities attached to each grouping).

Các tiêu chí phân loại để hỗ trợ phân vùng giải pháp (Classification Criteria to support Partitioning of Solutions) bao gồm:

  • Đối tượng (Phạm vi) (Subject Matter (Breadth)): Là đặc điểm tổ chức chính, kiến trúc được phân tách chức năng thành một hệ thống phân cấp các lĩnh vực đối tượng hoặc phân đoạn cụ thể. Đây là kỹ thuật cơ bản để cấu trúc cả giải pháp và các kiến trúc đại diện cho chúng.
  • Thời gian (Time): Vòng đời giải pháp thường được tổ chức theo dòng thời gian để quản lý tác động của việc phát triển, giới thiệu, vận hành và ngừng hoạt động giải pháp so với các hoạt động kinh doanh khác.
  • Độ trưởng thành/Biến động (Maturity/Volatility): Ảnh hưởng đến tốc độ thực hiện vòng đời giải pháp và định hình ưu tiên đầu tư. Các giải pháp trong môi trường biến động cao có thể phù hợp với kỹ thuật phát triển nhanh, linh hoạt.

Tiêu chí phân loại để hỗ trợ phân vùng kiến trúc (Classification Criteria to support Partitioning of Architectures) bao gồm:

  • Mức độ chi tiết (Depth): Mức độ chi tiết trong một kiến trúc có mối tương quan mạnh mẽ với các nhóm bên liên quan. Các kiến trúc ít chi tiết hơn thường được quan tâm bởi các bên liên quan cấp điều hành, trong khi các kiến trúc chi tiết hơn có liên quan đến nhân sự triển khai và vận hành.

Các đặc điểm không thường được sử dụng để phân vùng Bức tranh tổng thể Kiến trúc (Architecture Landscape) là:

  • Các kiến trúc dùng để mô tả Bức tranh tổng thể Kiến trúc thường không trừu tượng (not abstract).
  • Tính biến động của giải pháp (Solution volatility) thường ngăn cản việc định nghĩa các kiến trúc quá xa trong tương lai và làm giảm độ chính xác của các kiến trúc lịch sử theo thời gian.

4.2.1. Các hoạt động trong Giai đoạn Sơ bộ (Activities within the Preliminary Phase)

Mục tiêu chính của Giai đoạn Sơ bộ (Preliminary Phase) là thiết lập Năng lực Kiến trúc (Architecture Capability) cho doanh nghiệp. Hoạt động này yêu cầu thiết lập nhiều phân vùng kiến trúc (architecture partitions) với các ranh giới, quản trị và quyền sở hữu được xác định.

  • Mỗi nhóm (team) thực hiện hoạt động kiến trúc sẽ sở hữu một hoặc nhiều phân vùng kiến trúc và thực hiện ADM (Architecture Development Method) để định nghĩa, quản trị và hiện thực hóa các kiến trúc của họ.
  • Để tránh vấn đề về trách nhiệm khi nhiều nhóm làm việc trên một kiến trúc, nên áp dụng phân vùng để mỗi kiến trúc có một nhóm sở hữu (owning team) duy nhất.
  • Các nhóm kiến trúc tạm thời (temporary architecture teams) nên chịu sự quản trị của một nhóm kiến trúc thường trực (standing architecture team), và cần có quy trình trong chu trình ADM của các nhóm này để thiết lập phân vùng kiến trúc phù hợp.

Các bước trong Giai đoạn Sơ bộ để hỗ trợ phân vùng kiến trúc bao gồm:

  • Xác định cấu trúc tổ chức cho kiến trúc trong doanh nghiệp (Determine the organization structure for architecture within the enterprise): Xác định các nhóm thường trực (standing teams) sẽ tạo ra kiến trúc và thiết lập các ranh giới thích hợp (appropriate boundaries) cho mỗi nhóm, bao gồm các cơ quan quản trị, thành viên nhóm và đường báo cáo.
  • Xác định trách nhiệm cho từng nhóm kiến trúc thường trực (Determine the responsibilities for each standing architecture team): Áp dụng logic phân vùng để xác định phạm vi của mỗi nhóm và phân vùng kiến trúc dưới quyền của một nhóm duy nhất. Bước này phải phân vùng toàn bộ phạm vi doanh nghiệp và gán trách nhiệm cho mỗi kiến trúc được phân vùng cho một nhóm duy nhất. Định nghĩa của mỗi kiến trúc bao gồm: các lĩnh vực đối tượng (subject matter areas), mức độ chi tiết (level of detail), khoảng thời gian (time periods) và các bên liên quan (stakeholders).
  • Xác định mối quan hệ giữa các kiến trúc (Determine the relationships between architectures): Phát triển các mối quan hệ giữa các kiến trúc được phân vùng để chính thức hóa mối quan hệ quản trị và chỉ ra nơi các tạo phẩm (artifacts) từ một kiến trúc dự kiến sẽ được tái sử dụng trong các kiến trúc khác. Các vấn đề cần xem xét bao gồm sự chồng chéo/kết nối/chi tiết hóa giữa các kiến trúc và các yêu cầu tuân thủ giữa chúng.

Sau khi Giai đoạn Sơ bộ hoàn tất, các nhóm thực hiện kiến trúc, phạm vi xác định của họ và mối quan hệ giữa các nhóm và kiến trúc phải được hiểu rõ. Hình 4-1 minh họa việc phân bổ các nhóm vào phạm vi kiến trúc, cho thấy:

Figure 4-1: Allocation of Teams to Architecture Scope Hình 4-1: Phân bổ các đội vào phạm vi kiến trúc

  • Lớp Doanh nghiệp (Enterprise Layer) được định nghĩa qua sự hợp tác giữa Năng lực Doanh nghiệp Tập đoàn (Corporate Enterprise Capability) và Năng lực EA Phân đoạn (Segment EA Capability).
  • Lớp Phân đoạn (Segment Layer) được định nghĩa qua sự hợp tác giữa Năng lực Doanh nghiệp Tập đoàn, Năng lực EA Phân đoạnNhóm Danh mục đầu tư (Portfolio Team).
  • Lớp Năng lực (Capability Layer) được định nghĩa qua sự hợp tác giữa Nhóm Danh mục đầu tưNhóm Dự án (Project Team).

4.3. Tích hợp (Integration)

Việc tạo ra các kiến trúc được phân vùng (partitioned architectures) có nguy cơ dẫn đến một bộ sưu tập kiến trúc rời rạc, không thể tích hợp để hình thành một bức tranh tổng thể.

  • Đối với các doanh nghiệp lớn, phức tạp, kiến trúc liên hợp (federated architectures) — các kiến trúc được phát triển, duy trì và quản lý độc lập sau đó được tích hợp trong một khung tích hợp (integration framework) — là điển hình. Khung này quy định các nguyên tắc về khả năng tương tác, di chuyển và tuân thủ.
  • Để giảm thiểu rủi ro này, cần định nghĩa các tiêu chuẩn về tích hợp nội dung (content integration) và Quản trị Kiến trúc (Architecture Governance) nên coi tích hợp nội dung là một điều kiện tuân thủ kiến trúc.
  • Các khung nội dung (Content frameworks), như khung nội dung TOGAF, có thể được sử dụng để quy định các khối xây dựng tiêu chuẩn (standard building blocks) và tạo phẩm (artifacts) là đối tượng của các tiêu chuẩn tích hợp nội dung.
  • Ví dụ, một danh mục quy trình kinh doanh tiêu chuẩn (standard catalog of business processes) có thể được thống nhất cho một doanh nghiệp. Các kiến trúc sau đó có thể tạo điều kiện tích hợp bằng cách sử dụng cùng một danh sách quy trình và tham chiếu chéo các khía cạnh khác của kiến trúc đến các quy trình tiêu chuẩn đó.

Tích hợp có thể được giải quyết từ một số khía cạnh:

  • Tích hợp trên các miền kiến trúc (Integration across the architecture domains) cung cấp một cái nhìn đa miền về trạng thái của một phân đoạn doanh nghiệp tại một thời điểm.
  • Tích hợp trên phạm vi tổ chức của doanh nghiệp (Integration across the organizational scope of the business) cung cấp một cái nhìn đa phân đoạn về doanh nghiệp.
  • Tầm nhìn Kiến trúc (Architecture Vision) cung cấp một bản tóm tắt tích hợp của Định nghĩa Kiến trúc (Architecture Definitions), mà Định nghĩa Kiến trúc lại cung cấp một bản tóm tắt tích hợp của Kiến trúc Chuyển đổi (Transition Architectures).
  • Hình 4-2 minh họa cách nội dung kiến trúc (architectural content) có thể được tổng hợp bằng nhiều kỹ thuật khác nhau.

Figure 4-2: Architecture Content Aggregation Hình 4-2: Tích hợp Nội dung Cấu trúc