Skip to content

TOGAF® Standard — Introduction and Core Concepts

3. Core Concept

3.1. Tiêu chuẩn TOGAF là gì?

Tiêu chuẩn TOGAF là một khung kiến trúc (architecture framework). Nó cung cấp các phương pháp và công cụ để hỗ trợ việc chấp thuận, xây dựng, sử dụng và duy trì Kiến trúc Doanh nghiệp (Enterprise Architecture). Tiêu chuẩn này dựa trên một mô hình quy trình lặp (iterative process model) được hỗ trợ bởi các thực tiễn tốt nhất (best practices) và một tập hợp các tài sản kiến trúc hiện có có thể tái sử dụng; xem Mục "Tiêu chuẩn TOGAF".

3.2. Kiến trúc (Architecture) trong bối cảnh của tiêu chuẩn TOGAF là gì?

ISO/IEC/IEEE 42010: 2022 định nghĩa kiến trúc như sau:

Quote

Những khái niệm hoặc thuộc tính nền tảng của một thực thể trong môi trường của nó và các nguyên tắc chỉ đạo cho việc hiện thực hóa và phát triển thực thể này cùng các quy trình vòng đời liên quan. (The fundamental concepts or properties of an entity in its environment and governing principles for the realization and evolution of this entity and its related life cycle processes.)

Tiêu chuẩn TOGAF tiếp nhận nhưng không hoàn toàn tuân thủ nghiêm ngặt thuật ngữ của ISO/IEC/IEEE 42010:2022. Ngoài định nghĩa "kiến trúc" của ISO/IEC/IEEE 42010:2022, Tiêu chuẩn TOGAF còn định nghĩa một ý nghĩa thứ hai tùy theo ngữ cảnh:

Quote

Cấu trúc của các thành phần, mối quan hệ giữa chúng, và các nguyên tắc cũng như hướng dẫn chi phối thiết kế và sự phát triển của chúng theo thời gian. (The structure of components, their inter-relationships, and the principles and guidelines governing their design and evolution over time.)

Tiêu chuẩn TOGAF xem doanh nghiệp như một hệ thống và cố gắng đạt được sự cân bằng giữa việc thúc đẩy các khái niệm và thuật ngữ rút ra từ các tiêu chuẩn liên quan, và việc sử dụng các thuật ngữ được chấp nhận rộng rãi mà đa số độc giả của TOGAF quen thuộc. Để biết thêm về thuật ngữ, hãy tham khảo Mục 4 – Định nghĩa

3.3. Các loại kiến trúc mà Tiêu chuẩn TOGAF đề cập đến

Tiêu chuẩn TOGAF được thiết kế để hỗ trợ việc phát triển Kiến trúc Doanh nghiệp (Enterprise Architecture), và nó tập trung vào bốn lĩnh vực kiến trúc chính được chấp nhận rộng rãi như các tập con của Kiến trúc Doanh nghiệp tổng thể.

Các loại kiến trúc mà Tiêu chuẩn TOGAF đề cập bao gồm:

  • Kiến trúc Kinh doanh (Business Architecture): Định nghĩa chiến lược kinh doanh, quản trị, tổ chức và các quy trình kinh doanh chính của một tổ chức. Nó mô tả các khía cạnh kinh doanh tổng thể, đa chiều của khả năng, phân phối giá trị từ đầu đến cuối, thông tin và cấu trúc tổ chức; cũng như mối quan hệ giữa các khía cạnh kinh doanh này với chiến lược, sản phẩm, chính sách, quy trình, sáng kiến và các bên liên quan. Kiến trúc Kinh doanh cũng liên kết các yếu tố kinh doanh với mục tiêu kinh doanh và các yếu tố của các miền khác.
  • Kiến trúc Dữ liệu (Data Architecture): Mô tả cấu trúc của các loại và nguồn dữ liệu chính của tổ chức, tài sản dữ liệu logic, tài sản dữ liệu vật lý và tài nguyên quản lý dữ liệu.
  • Kiến trúc Ứng dụng (Application Architecture): Cung cấp một bản thiết kế cho các ứng dụng riêng lẻ sẽ được triển khai, các tương tác của chúng và mối quan hệ của chúng với các quy trình kinh doanh cốt lõi của tổ chức. Nó mô tả cấu trúc và sự tương tác của các ứng dụng cung cấp các khả năng kinh doanh chính và quản lý tài sản dữ liệu.
  • Kiến trúc Công nghệ (Technology Architecture): Mô tả kiến trúc kỹ thuật số và các khả năng cơ sở hạ tầng phần mềm và phần cứng logic, cùng các tiêu chuẩn cần thiết để hỗ trợ việc triển khai các dịch vụ kinh doanh, dữ liệu và ứng dụng. Điều này bao gồm các dịch vụ kỹ thuật số, Internet of Things (IoT), cơ sở hạ tầng mạng xã hội, dịch vụ đám mây, cơ sở hạ tầng CNTT, middleware, mạng, truyền thông, xử lý, tiêu chuẩn, v.v..

Ngoài ra, Tiêu chuẩn TOGAF cũng cho phép định nghĩa nhiều miền kiến trúc khác bằng cách kết hợp các góc nhìn phù hợp từ các miền Kinh doanh, Dữ liệu, Ứng dụng và Công nghệ. Ví dụ:

  • Kiến trúc Thông tin (Information Architecture)
  • Kiến trúc Rủi ro và An ninh (Risk and Security Architectures)
  • Kiến trúc Kỹ thuật số (Digital Architecture)

Khuôn khổ TOGAF cho phép tạo ra các góc nhìn đa chiều này và phân loại chúng để tạo ra các miền cụ thể, giúp doanh nghiệp xem xét phạm vi rộng hơn của doanh nghiệp và các khả năng của mình.

3.4. Phương pháp Phát triển Kiến trúc (Architecture Development Method - ADM)

Phương pháp Phát triển Kiến trúc TOGAF (TOGAF ADM) cung cấp một quy trình đã được kiểm chứng và có thể lặp lại để phát triển kiến trúc. ADM bao gồm việc thiết lập một khung kiến trúc (architecture framework), phát triển nội dung kiến trúc, chuyển đổi (transition) và quản trị việc hiện thực hóa kiến trúc.

Tất cả các hoạt động này được thực hiện trong một vòng lặp lặp lại (iterative cycle) của việc định nghĩa và hiện thực hóa kiến trúc liên tục, cho phép các tổ chức chuyển đổi doanh nghiệp của mình theo cách có kiểm soát để đáp ứng các mục tiêu và cơ hội kinh doanh. Điều này được minh họa trong Hình 3-1.

Hình 3-1: Chu kỳ phát triển kiến trúc

Các giai đoạn trong ADM như sau:

  • Giai đoạn Sơ bộ (Preliminary Phase): Mô tả các hoạt động chuẩn bị và khởi động cần thiết để tạo ra Năng lực Kiến trúc (Architecture Capability), bao gồm việc tùy chỉnh khung TOGAF và xác định Nguyên tắc Kiến trúc (Architecture Principles).
  • Giai đoạn A: Tầm nhìn Kiến trúc (Architecture Vision): Mô tả giai đoạn khởi đầu của một chu trình phát triển kiến trúc. Giai đoạn này bao gồm việc xác định phạm vi của sáng kiến phát triển kiến trúc, xác định các bên liên quan, xây dựng Tầm nhìn Kiến trúc, và đạt được sự chấp thuận để tiếp tục phát triển kiến trúc.
  • Giai đoạn B: Kiến trúc Kinh doanh (Business Architecture): Mô tả việc phát triển Kiến trúc Kinh doanh để hỗ trợ Tầm nhìn Kiến trúc đã được thống nhất.
  • Giai đoạn C: Kiến trúc Hệ thống Thông tin (Information Systems Architectures): Mô tả việc phát triển các Kiến trúc Hệ thống Thông tin để hỗ trợ Tầm nhìn Kiến trúc đã được thống nhất.
  • Giai đoạn D: Kiến trúc Công nghệ (Technology Architecture): Mô tả việc phát triển Kiến trúc Công nghệ để hỗ trợ Tầm nhìn Kiến trúc đã được thống nhất.
  • Giai đoạn E: Cơ hội & Giải pháp (Opportunities & Solutions): Tiến hành lập kế hoạch triển khai ban đầu và xác định các phương tiện triển khai cho kiến trúc đã được xác định trong các giai đoạn trước.
  • Giai đoạn F: Lập kế hoạch Di chuyển (Migration Planning): Xác định cách chuyển từ Kiến trúc Hiện tại (Baseline Architecture) sang Kiến trúc Mục tiêu (Target Architecture) bằng cách hoàn thiện một Kế hoạch Thực hiện và Di chuyển chi tiết.
  • Giai đoạn G: Quản trị Triển khai (Implementation Governance): Cung cấp sự giám sát kiến trúc trong quá trình triển khai.
  • Giai đoạn H: Quản lý Thay đổi Kiến trúc (Architecture Change Management): Thiết lập các quy trình để quản lý thay đổi đối với kiến trúc mới.
  • Quản lý Yêu cầu (Requirements Management): Vận hành quy trình quản lý các yêu cầu kiến trúc xuyên suốt toàn bộ ADM.

Phần mô tả về các giai đoạn của ADM trong tài liệu TOGAF Standard — Architecture Development Method tập trung vào các khuyến nghị về những gì có thể được thực hiện để xác định và triển khai Kiến trúc Doanh nghiệp.

Hướng dẫn về cách thực hiện những gì đã được chỉ định có thể được tìm thấy trong TOGAF Series Guides. Danh sách đầy đủ các TOGAF Series Guides được tham chiếu được bao gồm trong Phụ lục A – Tài liệu Tham khảo.

Khung TOGAF khuyến nghị rằng ADM nên được điều chỉnh để đáp ứng nhu cầu của doanh nghiệp và hỗ trợ các phong cách kiến trúc khác nhau (xem Mục "Sử dụng Khung TOGAF với Các Phong cách Kiến trúc Khác nhau").

Cụ thể, ADM không:

  • Bắt buộc các giai đoạn phải được thực hiện theo một trình tự cụ thể
  • Bắt buộc sử dụng phương pháp "thác nước" (waterfall method)

Tiêu chuẩn TOGAF mô tả cách ADM có thể được sử dụng theo cách lặp (iteratively) để phát triển một bức tranh tổng thể (landscape) về Kiến trúc Doanh nghiệp.

Thay vì coi sơ đồ ADM như một mô hình quy trình (process model), sẽ hữu ích hơn nếu xem nó như một mô hình tham chiếu (reference model), xác định những gì cần phải làm để cung cấp các giải pháp theo cách tiếp cận kiến trúc, đồng thời xác định các thành phần tương tác trong toàn doanh nghiệp và mối quan hệ giữa chúng.

3.5. Dịch vụ Kiến trúc Doanh nghiệp (Enterprise Architecture Services)

Các hoạt động được mô tả trong ADM thường được cung cấp thông qua mô hình cung cấp dịch vụ (service delivery model). Các dịch vụ này được tổ chức và trình bày theo nhóm dịch vụ (service categories).

Những dịch vụ này nhằm đáp ứng các nhu cầu cụ thể, độc lập với mô hình vận hành cụ thể của một tổ chức. Mỗi dịch vụ được mô tả sẽ sử dụng các hoạt động thích hợp trong ADM để giải quyết một nhu cầu nhất định.

Bảng 3-1 tóm tắt các nhóm dịch vụ được đề xuất và cung cấp một số bối cảnh. Bốn nhóm đầu tiên tập trung vào khách hàng (customer-centric), trong khi các nhóm còn lại tập trung nhiều hơn vào nội bộ các kiến trúc sư (internally centered on architects).

Bảng 3-1: Các loại dịch vụ và mô tả

Danh mục (Categories) Mô tả khách hàng điển hình
(Typical Customer Descriptor)		 Mô tả nhà cung cấp điển hình
(Typical Provider Descriptor)		 Sản phẩm bàn giao
(Deliverable(s))		 Kết quả mong muốn
(Desired Result)
Nhóm dịch vụ hướng khách hàng (Customer-Centric)
Enterprise Support Services
(Dịch vụ hỗ trợ doanh nghiệp)		 Ban lãnh đạo cấp cao (C-level management) Nhà phân tích doanh nghiệp sử dụng Kiến trúc Doanh nghiệp như một công cụ Trả lời các câu hỏi
Báo cáo đánh giá
Khuyến nghị		 Quyết định doanh nghiệp tốt hơn
Giảm rủi ro
Design Support Services
(Dịch vụ hỗ trợ thiết kế)		 Người ra quyết định cấp chương trình Kiến trúc sư doanh nghiệp – người xây dựng/mô hình MVA (bao gồm tiêu chuẩn, tiêu chí tuân thủ) cho chương trình
Hướng dẫn tuân thủ
Báo cáo tuân thủ		 Quyết định thiết kế tốt hơn
Chương trình và dự án thành công
Development Support Services
(Dịch vụ hỗ trợ phát triển)		 Người ra quyết định cấp dự án Kiến trúc sư doanh nghiệp – người xây dựng/mô hình MVA (bao gồm tiêu chuẩn, tiêu chí tuân thủ) cho dự án/sản phẩm
Hướng dẫn tuân thủ
Báo cáo tuân thủ		 Quyết định sản phẩm tốt hơn
Sản phẩm thành công
Requirements Elicitation and Understanding Services
(Dịch vụ thu thập và hiểu yêu cầu)		 Quản lý sản phẩm Kiến trúc sư doanh nghiệp chuyên về hiểu yêu cầu Mối quan tâm của bên liên quan
Yêu cầu
Đánh giá (giá trị, khả năng, v.v.)		 Có góc nhìn toàn diện về yêu cầu và giá trị giải pháp, cân bằng giữa các bên liên quan
Nhóm dịch vụ hướng nội bộ (Internal-Centric)
Architecture Planning Services
(Dịch vụ lập kế hoạch kiến trúc)		 Trưởng nhóm kiến trúc Kiến trúc sư doanh nghiệp giàu kinh nghiệm Kế hoạch dự án kiến trúc Đội ngũ kiến trúc được cung cấp đầy đủ nguồn lực
Enterprise Architecture Practice Development Support Services
(Dịch vụ hỗ trợ phát triển thực hành Kiến trúc Doanh nghiệp)		 Người ra quyết định trong tổ chức kiến trúc Chuyên gia thực hành Kiến trúc Doanh nghiệp Đánh giá năng lực Kiến trúc Doanh nghiệp
Khuyến nghị cải thiện năng lực Kiến trúc Doanh nghiệp		 Thực hành Kiến trúc Doanh nghiệp được tổ chức chặt chẽ và có kỹ năng cao (nội bộ hoặc thuê ngoài)

3.5.1. Dịch vụ hỗ trợ doanh nghiệp (Enterprise Support Services)

Nhóm dịch vụ này bao gồm các dịch vụ tiềm năng giúp đưa ra các quyết định doanh nghiệp sáng suốt nhằm hỗ trợ cho sự thay đổi của tổ chức. Các dịch vụ này có thể được cung cấp độc lập, không phụ thuộc vào bất kỳ dự án cụ thể nào. Trọng tâm của chúng là trả lời các câu hỏi và cung cấp phân tích cấp doanh nghiệp để hỗ trợ các quyết định mang tính chiến lược.

3.5.2. Dịch vụ hỗ trợ thiết kế (Design Support Services)

Nhóm dịch vụ này bao gồm các dịch vụ tiềm năng giúp đưa ra các quyết định thiết kế sáng suốt nhằm hỗ trợ cho sự thay đổi của tổ chức. Các dịch vụ này thường được cung cấp sau khi một dự án đã được cấp vốn, dù là dự án lớn hay nhỏ, theo phương pháp Waterfall hay Agile. Chúng bao gồm việc phát triển Kiến trúc khả dụng tối thiểu (Minimum Viable Architectures – MVA) và các phân tích liên quan để hỗ trợ các quyết định thiết kế.

3.5.3. Dịch vụ hỗ trợ phát triển (Development Support Services)

Nhóm dịch vụ này bao gồm các dịch vụ tiềm năng giúp đưa ra các quyết định phát triển sáng suốt nhằm hỗ trợ cho sự thay đổi của tổ chức. Các dịch vụ này thường được cung cấp trong giai đoạn phát triển của một dự án, dù là lớn hay nhỏ, theo phương pháp Waterfall hay Agile. Trọng tâm của chúng là trả lời các câu hỏi và cung cấp phân tích cấp doanh nghiệp để hỗ trợ các quyết định phát triển.

3.5.4. Dịch vụ thu thập và hiểu yêu cầu (Requirements Elicitation and Understanding Services)

Nhóm dịch vụ này bao gồm các dịch vụ tiềm năng giúp nâng cao khả năng hiểu yêu cầu. Vượt ra ngoài phạm vi quản lý yêu cầu, các dịch vụ này giúp tiếp cận sát hơn với nhu cầu thực sự, từ đó mang lại giá trị kinh doanh cao hơn.

3.5.5. Dịch vụ lập kế hoạch kiến trúc (Architecture Planning Services)

Nhóm dịch vụ này bao gồm các dịch vụ tiềm năng giúp xây dựng và thực hiện các dự án kiến trúc một cách có kế hoạch và hiệu quả nhằm hỗ trợ cho sự thay đổi của tổ chức. Các dịch vụ này thường được cung cấp ở giai đoạn đầu của một "dự án", dù lớn hay nhỏ, theo phương pháp Waterfall hay Agile.

3.5.6. Dịch vụ hỗ trợ phát triển thực hành Kiến trúc Doanh nghiệp (Enterprise Architecture Practice Development Support Services)

Nhóm dịch vụ này bao gồm các dịch vụ tiềm năng giúp phát triển và quản lý hoạt động thực hành Kiến trúc Doanh nghiệp. Chúng tập trung vào việc nâng cao năng lực Kiến trúc Doanh nghiệp.

3.6. Sản phẩm bàn giao, tạo phẩm, và khối xây dựng (Deliverables, Artifacts, and Building Blocks)

Kiến trúc sư thực hiện ADM sẽ tạo ra một số đầu ra như kết quả của công việc của họ, ví dụ: sơ đồ quy trình, yêu cầu kiến trúc, kế hoạch dự án, đánh giá tuân thủ dự án, v.v. Khung nội dung Kiến trúc TOGAF (tham khảo TOGAF Standard — Architecture Content) cung cấp một mô hình cấu trúc cho nội dung kiến trúc, cho phép các sản phẩm chính đượ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 Kiến trúc sử dụng ba loại sau để mô tả loại sản phẩm công việc kiến trúc trong bối cảnh sử dụng:

  • Sản phẩm bàn giao (Deliverable) là một sản phẩm công việc được quy định trong hợp đồng và được các bên liên quan xem xét, phê duyệt, và ký xác nhận.

    Sản phẩm bàn giao thể hiện đầu ra của các dự án; những sản phẩm bàn giao ở dạng tài liệu thường sẽ được lưu trữ khi dự án hoàn thành, hoặc được chuyển vào Kho lưu trữ Kiến trúc (Architecture Repository) như một mô hình tham chiếu, tiêu chuẩn, hoặc ảnh chụp trạng thái Kiến trúc tổng thể (Architecture Landscape) tại một thời điểm cụ thể.

  • Tạo phẩm (Artifact) là một sản phẩm công việc kiến trúc mô tả một khía cạnh của kiến trúc.

    Tạo phẩm thường được phân loại thành danh mục (catalogs — danh sách các đối tượng), ma trận (matrices — thể hiện mối quan hệ giữa các đối tượng), và sơ đồ (diagrams — hình ảnh minh họa các đối tượng). Ví dụ: danh mục yêu cầu (requirements catalog), ma trận tương tác ứng dụng (application interaction matrix), và sơ đồ chuỗi giá trị (value chain diagram).

    Một sản phẩm bàn giao kiến trúc có thể chứa một hoặc nhiều tạo phẩm, và các tạo phẩm sẽ tạo thành nội dung của Kho lưu trữ Kiến trúc. Một tạo phẩm có thể được hoặc không được coi là sản phẩm bàn giao, tùy thuộc vào yêu cầu hợp đồng.

  • Khối xây dựng (Building Block) là một thành phần có khả năng tái sử dụng và có thể được kết hợp với các khối xây dựng khác để cung cấp kiến trúc và giải pháp.

    Khối xây dựng có thể được định nghĩa ở các mức độ chi tiết khác nhau, tùy thuộc vào giai đoạn phát triển kiến trúc. Ví dụ: ở giai đoạn đầu, một khối xây dựng có thể chỉ bao gồm tên hoặc mô tả sơ lược; về sau, khối xây dựng có thể được phân rã thành nhiều khối xây dựng hỗ trợ và kèm theo đầy đủ đặc tả kỹ thuật.

    Khối xây dựng có thể liên quan đến "Kiến trúc" hoặc "Giải pháp":

    • Khối xây dựng kiến trúc (Architecture Building Blocks - ABBs) thường mô tả năng lực cần thiết và định hướng đặc tả cho Khối xây dựng giải pháp (Solution Building Blocks – SBBs). Ví dụ: năng lực dịch vụ khách hàng có thể được yêu cầu trong một doanh nghiệp và được hỗ trợ bởi nhiều SBB như quy trình, dữ liệu, và phần mềm ứng dụng.

    • Khối xây dựng giải pháp (Solution Building Blocks - SBBs) đại diện cho các lựa chọn triển khai thực tế để hiện thực hóa năng lực đã yêu cầu. Ví dụ: một mạng là ABB có thể được triển khai bằng nhiều lựa chọn khác nhau (SBBs), chẳng hạn như mạng vệ tinh theo hai cấu hình chính: một cụm nhiều vi vệ tinh hoặc một nhóm nhỏ vệ tinh cỡ lớn.

Mối quan hệ giữa sản phẩm bàn giao, tạo phẩm, và khối xây dựng được minh họa tại Hình 3-2.

Hình 3-2: Mối quan hệ giữa sản phẩm bàn giao, tạo phẩm, và khối xây dựng

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

Tài liệu này sẽ chứa nhiều tạo phẩm (artifacts) bổ sung, thể hiện các góc nhìn về những khối xây dựng (building blocks) có liên quan đến kiến trúc.

Ví dụ: một sơ đồ quy trình (process flow diagram — một tạo phẩm) có thể được tạo để mô tả quy trình xử lý cuộc gọi mục tiêu (một khối xây dựng). 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 tham gia trong quy trình (ví dụ: Nhân viên Dịch vụ Khách hàng — Customer Services Representative).

Một ví dụ về mối quan hệ giữa sản phẩm bàn giao, tạo phẩm, và khối xây dựng được minh họa tại Hình 3-3.

Hình 3-3: Ví dụ về Tài liệu Định nghĩa Kiến trúc

Các khái niệm về sản phẩm bàn giao (Deliverables), tạo phẩm (Artifacts), và khối xây dựng (Building Blocks) được mô tả chi tiết hơn trong tiêu chuẩn TOGAF — nội dung kiến trúc (TOGAF Standard — Architecture Content).

Tiêu chuẩn TOGAF — Kỹ thuật ADM (TOGAF Standard — ADM Techniques) mô tả phương pháp Phát triển kiến trúc (Architecture Development Method) và bao gồm các danh sách tóm tắt về sản phẩm bàn giao và tạo phẩm có thể được tạo trong từng giai đoạn. tiêu chuẩn TOGAF — nội dung kiến trúc chứa các mô tả chi tiết về những yếu tố này.

3.7. Trừu tượng hóa kiến trúc (Architecture Abstraction)

Một quy trình hoặc kỹ thuật để tạo ra các góc nhìn đơn giản hóa về hệ thống đang quan tâm (system-of-interest), nhằm mục đích thảo luận, giao tiếp và ra quyết định liên quan đến một khía cạnh nào đó của hệ thống, phù hợp với các bên liên quan.

Các cấp độ trừu tượng có tính phân lớp, di chuyển từ các mô hình cấp cao đến các mô hình chi tiết hơn.

Nỗ lực xây dựng kiến trúc có thể được chia thành bốn cấp độ trừu tượng riêng biệt xuyên suốt các miền kinh doanh, dữ liệu, ứng dụng và công nghệ, nhằm trả lời những câu hỏi cơ bản về kiến trúc:

  • Why (Tại sao) — tại sao kiến trúc lại cần thiết?
  • What (Cái gì) — những chức năng và yêu cầu nào cần được kiến trúc đáp ứng?
  • How (Như thế nào) — chúng ta cấu trúc các chức năng đó ra sao?
  • With what (Bằng cái gì) — chúng ta sẽ sử dụng những tài sản nào để triển khai cấu trúc này?

Note

Lưu ý rằng các thuật ngữ tại sao, cái gì và như thế nào trong ngữ cảnh này không liên quan đến cách sử dụng của chúng trong Khung Kiến trúc Doanh nghiệp Zachman® (Zachman® Enterprise Architecture Framework).

3.7.1. Cấp độ trừu tượng hóa bối cảnh (Contextual Abstraction Level)

  • Tập trung vào việc hiểu môi trường mà một doanh nghiệp hoạt động và bối cảnh mà công việc kiến trúc được lên kế hoạch và thực hiện.
  • Trả lời câu hỏi "tại sao" (Why) một doanh nghiệp thực hiện công việc kiến trúc, phạm vi công việc là gì, và động lực về mục tiêu, yếu tố thúc đẩy và mục đích.

3.7.2. Cấp độ trừu tượng hóa khái niệm (Conceptual Abstraction Level)

  • Tập trung vào việc phân tách các yêu cầu để hiểu vấn đề và những gì cần thiết để giải quyết vấn đề, mà không tập trung quá mức vào cách kiến trúc sẽ được hiện thực hóa.
  • Trả lời câu hỏi "cái gì" (What) là cần thiết để hiện thực hóa các yêu cầu và thường được mô hình hóa bằng cách sử dụng các mô hình dịch vụ (dịch vụ kinh doanh, dịch vụ ứng dụng, dịch vụ công nghệ) đại diện cho hành vi mong muốn.
  • Cấp độ trừu tượng hóa này cũng có thể được gọi là trừu tượng hóa dịch vụ hoặc trừu tượng hóa hành vi.

3.7.3. Cấp độ trừu tượng hóa Logic (Logical Abstraction Level)

  • Tập trung vào việc xác định các loại thành phần kinh doanh, dữ liệu, ứng dụng và công nghệ cần thiết để đạt được các dịch vụ được xác định ở cấp độ khái niệm.

  • Trả lời câu hỏi "làm thế nào" (How) kiến trúc có thể được tổ chức và cấu trúc, một cách độc lập với việc triển khai.

  • Có thể có một số cách để nhóm các dịch vụ thành các thành phần logic, dựa trên các nguyên tắc và các tiêu chí nhóm khác, cung cấp các giải pháp logic thay thế khác nhau.

3.7.4. Cấp độ trừu tượng hóa vật lý (Physical Abstraction Level)

  • Quản lý việc phân bổ và triển khai các thành phần vật lý để đáp ứng các thành phần logic đã xác định.
  • Trả lời câu hỏi "Bằng cái gì" (With what) các thành phần cấp độ logic có thể được hiện thực hóa bằng các thành phần vật lý.
  • Có thể có nhiều cách để sử dụng các thành phần vật lý để hiện thực hóa các thành phần logic, dựa trên các nguyên tắc và các tiêu chí nhóm khác, cung cấp các giải pháp vật lý thay thế khác nhau

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

Nguyên tắc là những quy tắc và hướng dẫn chung, có tính lâu dài và hiếm khi được sửa đổi, nhằm định hướng và hỗ trợ cách thức một tổ chức thực hiện sứ mệnh của mình.

Tùy theo từng tổ chức, các nguyên tắc có thể được thiết lập trong các miền (domain) khác nhau và ở các cấp độ khác nhau.

Có hai miền chính định hướng việc xây dựng và sử dụng kiến trúc:

3.8.1. Nguyên tắc doanh nghiệp (Enterprise Principles)

  • Cung cấp nền tảng cho việc ra quyết định trên toàn doanh nghiệp và định hướng cách tổ chức thực hiện sứ mệnh của mình.
  • Xác định các quy tắc và hướng dẫn chung về việc sử dụng và triển khai tất cả nguồn lực và tài sản trong toàn doanh nghiệp.
  • Phản ánh mức độ đồng thuận giữa các bộ phận khác nhau trong doanh nghiệp.
  • Thường được sử dụng để hài hòa hóa quá trình ra quyết định trong toàn tổ chức. Đây là một yếu tố then chốt để triển khai thành công chiến lược Quản trị kiến trúc (Architecture Governance) (xem TOGAF Standard — EA Capability and Governance).

Trong phạm vi rộng của nguyên tắc Doanh nghiệp, thường sẽ có các nguyên tắc phụ thuộc trong từng đơn vị kinh doanh hoặc đơn vị tổ chức; ví dụ: nguyên tắc dành riêng cho CNTT, Nhân sự (HR), hoạt động trong nước hoặc hoạt động quốc tế. Các nguyên tắc này hỗ trợ quá trình ra quyết định trong phạm vi của đơn vị đó, và định hướng phát triển kiến trúc trong miền này. Cần đảm bảo các nguyên tắc dùng để định hướng phát triển kiến trúc phải phù hợp với bối cảnh tổ chức của năng lực kiến trúc (Architecture Capability).

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

  • Là tập hợp các nguyên tắc liên quan đến công việc kiến trúc.
  • Phản ánh mức độ đồng thuận trên toàn doanh nghiệp và thể hiện tinh thần, tư duy của các nguyên tắc Doanh nghiệp hiện có.
  • Điều chỉnh quá trình kiến trúc, ảnh hưởng đến việc phát triển, duy trì và sử dụng kiến trúc Doanh nghiệp.

Trong một doanh nghiệp, hệ thống phân cấp nguyên tắc bắt đầu từ nguyên tắc Doanh nghiệp. Các nguyên tắc cấp dưới phải tồn tại trong phạm vi của các nguyên tắc cấp trên, và không được vượt quá giới hạn đó. Ở mỗi cấp độ, các nguyên tắc sẽ được xây dựng dựa trên và làm rõ hơn các nguyên tắc kế thừa từ cấp trên.

Nguyên tắc Kiến trúc có thể diễn đạt lại các hướng dẫn của doanh nghiệp bằng hình thức và ngôn từ giúp định hướng hiệu quả cho quá trình phát triển kiến trúc.

Kiến trúc cần thể hiện rõ mối liên hệ với các nguyên tắc này để đảm bảo cách thức thực hiện mục tiêu luôn phù hợp với các động lực (drivers) đã xác định.

Các Nguyên tắc Kiến trúc được giải thích chi tiết hơn trong TOGAF Standard — ADM Techniques.

3.9. Khả năng Tương tác (Interoperability)

Định nghĩa: Khả năng tương tác là "khả năng chia sẻ thông tin và dịch vụ". Việc xác định mức độ mà thông tin và dịch vụ được hoặc không được chia sẻ là một yêu cầu kiến trúc rất hữu ích, đặc biệt trong một tổ chức phức tạp và/hoặc doanh nghiệp mở rộng (extended enterprise).

Quá trình xác định khả năng tương tác xuất hiện xuyên suốt phương pháp Phát triển Kiến trúc (Architecture Development Method — ADM) như sau:

  • Giai đoạn A — Tầm nhìn Kiến trúc (Architecture Vision): Xác định bản chất và các yếu tố bảo mật của việc trao đổi thông tin và dịch vụ, thường xuất hiện trong các kịch bản kinh doanh (business scenarios).
  • Giai đoạn B — Kiến trúc Kinh doanh (Business Architecture): Xác định chi tiết hơn việc trao đổi thông tin và dịch vụ ở cấp độ nghiệp vụ.
  • Giai đoạn C — Kiến trúc Dữ liệu (Data Architecture): Mô tả chi tiết nội dung trao đổi thông tin dựa trên mô hình dữ liệu hoặc mô hình trao đổi thông tin của tổ chức.
  • Giai đoạn C — Kiến trúc Ứng dụng (Application Architecture): Xác định cách các ứng dụng sẽ chia sẻ thông tin và dịch vụ.
  • Giai đoạn D — Kiến trúc Công nghệ (Technology Architecture): Xác định cơ chế kỹ thuật phù hợp để cho phép việc trao đổi thông tin và dịch vụ.
  • Giai đoạn E — Cơ hội & Giải pháp (Opportunities & Solutions): Lựa chọn các giải pháp thực tế (ví dụ: phần mềm đóng gói thương mại — COTS).
  • Giai đoạn F — Lập kế hoạch Chuyển đổi (Migration Planning): Thực hiện khả năng tương tác ở mức logic.

Có nhiều cách để định nghĩa khả năng tương tác, nhưng mục tiêu là áp dụng một định nghĩa thống nhất trong cả doanh nghiệp và doanh nghiệp mở rộng. Tốt nhất là cả hai đều sử dụng cùng một định nghĩa.

Nhiều tổ chức thấy hữu ích khi phân loại khả năng tương tác như sau:

  1. Khả năng tương tác Vận hành hoặc Kinh doanh (Operational or Business Interoperability)
    Xác định cách các bộ phận khác nhau trong doanh nghiệp phối hợp với nhau ở cấp độ nghiệp vụ.

  2. Khả năng tương tác Thông tin (Information Interoperability)
    Xác định cách thức chia sẻ thông tin.

  3. Khả năng tương tác Kỹ thuật (Technical Interoperability)
    Xác định cách thức chia sẻ hoặc ít nhất là kết nối các nguồn lực kỹ thuật với nhau.

Từ góc nhìn CNTT, khả năng tương tác cũng có thể được tiếp cận tương tự như Tích hợp Ứng dụng Doanh nghiệp (Enterprise Application Integration — EAI), cụ thể:

  • Tích hợp/Khả năng tương tác ở lớp Giao diện (Presentation Integration/Interoperability):

    Sử dụng giao diện thống nhất (thường dạng portal) để cung cấp trải nghiệm đồng nhất cho người dùng, hướng dẫn họ truy cập vào chức năng của các hệ thống bên dưới.

  • Tích hợp/Khả năng tương tác ở lớp Thông tin (Information Integration/Interoperability):

    Dữ liệu doanh nghiệp được chia sẻ liền mạch giữa các ứng dụng, ví dụ: dùng chung một bộ thông tin khách hàng thống nhất.

    Thường dựa trên hệ thống phân loại và định nghĩa dữ liệu doanh nghiệp (corporate ontology) được thống nhất, cùng với dịch vụ chia sẻ cho cấu trúc, chất lượng, truy cập và bảo mật/thông tin cá nhân.

  • Tích hợp/Khả năng tương tác ở lớp Ứng dụng (Application Integration/Interoperability):

    Các chức năng của doanh nghiệp được tích hợp và dùng chung, tránh trùng lặp (ví dụ: chỉ có một dịch vụ thay đổi địa chỉ duy nhất thay vì mỗi ứng dụng một bản). Các ứng dụng được liên kết mượt mà, thường thông qua các tính năng như workflow.

    Điều này ảnh hưởng đến cả ứng dụng nghiệp vụ và hạ tầng, đồng thời liên quan chặt chẽ đến việc thống nhất quy trình nghiệp vụ.

  • Tích hợp/Khả năng tương tác ở lớp Kỹ thuật (Technical Integration/Interoperability):

    Sử dụng các phương thức chung và dịch vụ chia sẻ để truyền thông, lưu trữ, xử lý và truy cập dữ liệu, chủ yếu trong các miền nền tảng ứng dụng và hạ tầng truyền thông.

Các vấn đề về Khả năng tương tác và Yêu cầu về khả năng tương tác được trình bày chi tiết trong TOGAF Standard — ADM Techniques.

3.10. Enterprise Continuum

Enterprise Continuum là một khái niệm quan trọng trong kiến trúc doanh nghiệp, đặc biệt là trong khuôn khổ TOGAF (The Open Group Architecture Framework). Enterprise Continuum là một hệ thống phân loại cho các tài sản được lưu giữ trong Kho Lưu trữ Doanh nghiệp (Enterprise Repositories), cung cấp các phương pháp phân loại tài sản, bao gồm các sản phẩm kiến trúc (architectural artifacts) và giải pháp (solution artifacts), khi chúng phát triển từ Kiến trúc Nền tảng (Foundation Architectures) mang tính tổng quát đến Kiến trúc Cụ thể của Tổ chức (Organization-Specific Architectures).

Mục đích chính của Enterprise Continuum là giúp các kiến trúc sư doanh nghiệp quản lý và hiểu rõ sự phát triển của kiến trúc, từ những ý tưởng tổng quát, trừu tượng đến các giải pháp cụ thể, chi tiết.

Enterprise Continuum bao gồm hai phần chính:

  • Architecture Continuum (Chuỗi Kiến trúc): Phần này tập trung vào việc phân loại và phát triển các tài sản kiến trúc. Nó sắp xếp các kiến trúc theo một chuỗi liên tục, từ những kiến trúc nền tảng, chung chung, không phụ thuộc vào ngành nghề cụ thể (như kiến trúc cơ bản của một hệ thống máy tính) đến các kiến trúc cụ thể hơn, dành riêng cho từng lĩnh vực kinh doanh hoặc tổ chức.

  • Solutions Continuum (Chuỗi Giải pháp): Phần này bổ sung cho Architecture Continuum bằng cách cung cấp một cái nhìn về cách các giải pháp thực tế được phát triển và triển khai. Nó mô tả sự tiến hóa của các giải pháp, từ những giải pháp chung chung, có thể tái sử dụng (như các sản phẩm phần mềm thương mại) đến các giải pháp tùy chỉnh, được xây dựng riêng cho từng tổ chức.

Enterprise Continuum là một công cụ giúp các kiến trúc sư doanh nghiệp có một "bức tranh toàn cảnh" về các tài sản kiến trúc và giải pháp của tổ chức, từ đó giúp họ:

  • Tổ chức và quản lý hiệu quả các tài sản kiến trúc.
  • Tái sử dụng các thành phần kiến trúc và giải pháp đã có.
  • Giảm thiểu rủi ro và chi phí khi phát triển các hệ thống mới.
  • Tăng cường sự nhất quán và linh hoạt trong toàn bộ kiến trúc doanh nghiệp.

Enterprise Continuum được mô tả chi tiết trong Tiêu chuẩn TOGAF — Nội dung Kiến trúc (TOGAF Standard — Architecture Content).

Tổng quan về cấu trúc và bối cảnh của Enterprise Continuum được minh họa trong Hình 3-4.

Hình 3-4:Enterprise Continuum

3.10.1. Kho lưu trữ Kiến trúc (Architecture Repository)

Kho lưu trữ Kiến trúc (Architecture Repository) là một khái niệm trung tâm, hỗ trợ chặt chẽ cho Enterprise Continuum. Nó là nơi lưu trữ tất cả các sản phẩm kiến trúc được tạo ra trong quá trình áp dụng ADM, từ khái niệm tổng quát cho đến thiết kế chi tiết. Mỗi loại sản phẩm có thể ở một mức độ trừu tượng khác nhau. Bằng cách này, Tiêu chuẩn TOGAF tạo điều kiện cho sự hiểu biết và hợp tác giữa các bên liên quan và những người thực hành ở các cấp độ khác nhau.

Thông qua Enterprise Continuum và Kho lưu trữ Kiến trúc, các kiến trúc sư được khuyến khích tận dụng tất cả các tài nguyên và tài sản kiến trúc có liên quan khác khi phát triển Kiến trúc Đặc thù Tổ chức (Organization-Specific Architecture).

Nói đơn giản, Enterprise Continuum ta "bức tranh toàn cảnh" của kiến trúc, còn Kho lưu trữ Kiến trúc là "nơi cất giữ" tất cả khối xây dựng (cấu thành) (building blocks), mô hình, và quy tắc để từ đó xây dựng kiến trúc đặc thù cho tổ chức.

Cấu trúc chi tiết của Kho lưu trữ Kiến trúc TOGAF được thể hiện ở Hình 3-5.

Hình 3-5: Cấu trúc của Kho lưu trữ kiến trúc

Kho lưu trữ Kiến trúc TOGAF có một cấu trúc cụ thể, bao gồm các thành phần chính sau:

  • Architecture Metamodel (Metamodel Kiến trúc): Mô tả ứng dụng được điều chỉnh theo tổ chức của một khuôn khổ kiến trúc, bao gồm cả metamodel cho nội dung kiến trúc.
  • Architecture Capability (Năng lực Kiến trúc): Xác định các thông số, cấu trúc và quy trình hỗ trợ quản trị Kho lưu trữ Kiến trúc.
  • Architecture Landscape (Bức tranh Kiến trúc): Là biểu diễn kiến trúc của các tài sản đang được sử dụng, hoặc được lên kế hoạch, bởi doanh nghiệp tại một thời điểm cụ thể. Bức tranh này có khả năng tồn tại ở nhiều mức độ trừu tượng khác nhau để phù hợp với các mục tiêu kiến trúc khác nhau.
  • Standards Library (Thư viện Tiêu chuẩn): Ghi lại các tiêu chuẩn mà các kiến trúc mới phải tuân thủ, có thể bao gồm các tiêu chuẩn ngành, các sản phẩm và dịch vụ được chọn từ các nhà cung cấp, hoặc các dịch vụ dùng chung đã được triển khai trong tổ chức.
  • Reference Library (Thư viện Tham chiếu): Cung cấp các hướng dẫn, mẫu, mô hình (patterns) và các dạng tài liệu tham khảo khác có thể được tận dụng để tăng tốc việc tạo ra các kiến trúc mới cho doanh nghiệp. TOGAF Library là một Thư viện Tham chiếu chứa các hướng dẫn, mẫu, mô hình, và các tài liệu tham khảo khác để đẩy nhanh việc tạo ra các kiến trúc mới cho doanh nghiệp.
  • Governance Repository (Kho lưu trữ Quản trị): Cung cấp một bản ghi về hoạt động quản trị trên toàn doanh nghiệp.
  • Architecture Requirements Repository (Kho lưu trữ Yêu cầu Kiến trúc): Cung cấp một cái nhìn tổng thể về tất cả các yêu cầu kiến trúc được ủy quyền đã được Hội đồng Kiến trúc đồng ý.
  • Solutions Landscape (Bức tranh Giải pháp): Trình bày một biểu diễn kiến trúc của các Khối xây dựng Giải pháp (SBBs) hỗ trợ cho Bức tranh Kiến trúc, vốn đã được doanh nghiệp lên kế hoạch hoặc triển khai.

Kho lưu trữ Kiến trúc TOGAF được mô tả chi tiết trong tài liệu The TOGAF Standard — Architecture Content

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

3.11.1. Tổng quan

Phương pháp phát triển kiến trúc (ADM) của TOGAF giúp quản lý vòng đời của kiến trúc trong doanh nghiệp. Ở mỗi giai đoạn, ADM chỉ rõ đầu vào, đầu ra và các bước thực hiện, tạo ra nhiều sản phẩm kiến trúc (work products).

Khi bắt đầu xây dựng năng lực kiến trúc doanh nghiệp riêng (giai đoạn Preliminary của ADM), cần xác định:

  1. Khung nội dung (Content Framework) – cách phân loại và tổ chức mô tả kiến trúc, các sản phẩm và mô hình kiến trúc.
  2. Siêu mô hình Doanh nghiệp (Enterprise Metamodel) – mô tả các loại thực thể trong doanh nghiệp và mối quan hệ giữa chúng dưới dạng mô hình chính thức.
  3. Các sản phẩm kiến trúc cụ thể sẽ được phát triển (tham khảo mục 3.6 - Deliverables, Artifacts, and Building Blocks).

Việc chọn khung nội dung sẽ phụ thuộc vào:

  • Khung kiến trúc đượ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 hỗ trợ hoạt động này.

3.11.2. Khung nội dung (Content Framework)

Khung nội dung (Content Framework)* xác định một khung phân loại được sử dụng để mô tả các *khối cấu thành (building blocks) và các tạo phẩm kiến trúc (artifacts) phản ánh những quyết định đã được đưa ra trong quá trình tạo ra các tài liệu bàn giao kiến trúc tổng thể.

Kho lưu trữ kiến trúc (Architecture Repository)*, được giải thích ở Mục 3.10.1, được cấu trúc để lưu trữ các tạo phẩm kiến trúc và *các sản phẩm (work product) được xác định trong Khung nội dung. Khung nội dung là một yếu tố của Khung kiến trúc đặc thù doanh nghiệp (Enterprise-Specific Architecture Framework).

Có nhiều khung nội dung thay thế khác nhau (ví dụ: Khung nội dung TOGAF, Khung Zachman, DoDAF, NAF, v.v.). Việc lựa chọn một khung nội dung là điều cần thiết, mặc dù lựa chọn cụ thể không quan trọng bằng việc phải có một khung nội dung. Khung nội dung cuối cùng thường đượ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.
  • Đảm bảo tính nhất quán trong các đầu ra được tạo ra khi tuân theo Phương pháp Phát triển Kiến trúc (ADM).
  • Cung cấp một danh sách kiểm tra toàn diện về các đầu ra kiến trúc có thể được tạo ra.
  • Giảm thiểu rủi ro về các khoảng trống (gaps) trong bộ sản phẩm kiến trúc cuối cùng.
  • Giúp một doanh nghiệp chuẩn hóa các khái niệm, thuật ngữ và sản phẩm kiến trúc

Ở cấp cao nhất, TOGAF Content Framework (xem Hình 3-6) được tổ chức tương ứng với các giai đoạn của ADM.

Hình 3-6

  • Các mô hình Nguyên tắc Kiến trúc (Architecture Principles), Tầm nhìn (Vision), Động lực (Motivation) và Yêu cầu (Requirements) được dùng để nắm bắt bối cảnh bao quanh 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 tổng quát, bối cảnh chiến lược làm đầu vào cho việc xây dựng mô hình kiến trúc, và các yêu cầu đượ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 — những yếu tố đã dẫn đến yêu cầu thực hiện công việc kiến trúc — thường được nghiên cứu, tinh chỉnh, xác minh và ghi lại trong các giai đoạn Sơ bộ (Preliminary) và Tầm nhìn Kiến trúc (Architecture Vision).

  • Kiến trúc Kinh doanh (Business Architecture) nắm bắt các mô hình kiến trúc của doanh nghiệp, tập trung vào các yếu tố thúc đẩy doanh nghiệp, cấu trúc của nó, và các năng lực của nó.
  • Kiến trúc Hệ thống Thông tin (Information Systems Architecture) nắm bắt các mô hình kiến trúc của hệ thống CNTT, xem xét các ứng dụng và dữ liệu phù hợp với các giai đoạn ADM của TOGAF.
  • Kiến trúc Công nghệ (Technology Architecture) nắm bắt các tài sản công nghệ đượ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.
  • Các mô hình Hiện thực hóa/Chuyển đổi Kiến trúc (Architecture Realization/Transformation models) nắm bắt lộ trình thay đổi (roadmaps) thể hiện sự chuyển tiếp giữa các trạng thái kiến trúc và các tuyên bố ràng buộc được sử dụng để định hướng và quản trị việc triển khai kiến trúc.
  • Cá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), cả bên trong và bên ngoài, tác động đến Kiến trúc Doanh nghiệp và việc tạo ra các yêu cầu hành động.

Khung Nội dung TOGAF được mô tả chi tiết trong TOGAF Standard — Architecture Content.

3.11.3. Mô hình siêu dữ liệu doanh nghiệp (Enterprise Metamodel)

Tiêu chuẩn TOGAF khuyến khích việc phát triển Mô hình Siêu dữ liệu Doanh nghiệp (Enterprise Metamodel), mô hình này định nghĩa các loại thực thể (entity types) sẽ xuất hiện trong các mô hình mô tả doanh nghiệp, cùng với mối quan hệ giữa các thực thể này.

Ví dụ: một loại thực thể trong Enterprise Metamodel có thể là Vai trò (Role). Khi đó, các mô hình Kiến trúc Kinh doanh (Business Architecture) của doanh nghiệp có thể bao gồm các ví dụ về Vai trò như: giao dịch viên (Teller), phi công (Pilot), quản lý (Manager), tình nguyện viên (Volunteer), khách hàng (Customer), hoặc lính cứu hỏa (Firefighter). Tất nhiên, sẽ rất hiếm có doanh nghiệp nào lại sở hữu tất cả các vai trò này cùng lúc.

Enterprise Metamodel mang lại giá trị theo nhiều cách:

  • 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 quát trong mô hình của họ.

  • 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) hoặc mô hình siêu dữ liệu kiến trúc (architecture metamodel) nào được đề xuất sử dụng trong doanh nghiệp.

  • Cụ thể: ngôn ngữ hoặc metamodel này xử lý đầy đủ đến đâu các loại thực thể trong Enterprise Metamodel và 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)?

Enterprise Metamodel có thể giúp đảm bảo:

  • Tính nhất quán (Consistency)
  • Tính đầy đủ (Completeness)
  • Khả năng truy xuất nguồn gốc (Traceability)

Lưu ý: Tiêu chuẩn TOGAF không nhằm ràng buộc doanh nghiệp trong việc:

  • Lựa chọn tạo phẩm kiến trúc (artifacts)
  • Lựa chọn ký hiệu mô hình (modeling notation)

TOGAF có thể sử dụng nhiều ngôn ngữ mô hình khác nhau, ví dụ:

  • ArchiMate®
  • Business Process Model and Notation™ (BPMN™)
  • Unified Modeling Language™ (UML®)
  • Sơ đồ quan hệ thực thể (Entity Relationship Diagram)
  • Lưu đồ (Flowchart)
  • Hoặc bất kỳ ký pháp nào khác có thể thể hiện được các ý tưởng trong TOGAF.

Các loại thực thể trong doanh nghiệp và mối quan hệ giữa chúng là đặc thù của từng doanh nghiệp. Việc phát triển một metamodel chất lượng cao là một phần quan trọng trong quá trình thiết lập Năng lực Kiến trúc Doanh nghiệp (Enterprise Architecture Capability).

3.11.4. Phát triển Mô hình Siêu dữ liệu Doanh nghiệp (Enterprise Metamodel)

Enterprise Metamodel là một phần quan trọng của Khung Kiến trúc đặc thù tổ chức (Organization-Specific Architecture Framework), như được nhấn mạnh tại đây. Hình 3-7 cho thấy cách Enterprise Continuum (xem Mục 3.10. Enterprise Continuum) cung cấp một phương pháp để xem xét các nguồn lực trên một thang đo từ mức tổng quát nhất (Foundation) đến mức đặc thù tổ chức nhất (Organization-Specific):

Hình 3-7: Áp dụng Enterprise Continuum

Để hỗ trợ quá trình phát triển metamodel của doanh nghiệp, Thư viện TOGAF (TOGAF Library) bao gồm một Mô hình Siêu dữ liệu Doanh nghiệp Cốt lõi ở mức Foundation (Foundation-level Core Enterprise Metamodel), được mô tả chi tiết trong TOGAF Standard — Architecture Content.

Mô hình này thể hiện các loại thực thể (types of entity) và mối quan hệ (relationships) giữa chúng, vốn có khả năng được yêu cầu trong quá trình mô hình hóa phần lớn doanh nghiệp, đồng thời cung cấp bối cảnh cho các tạo phẩm kiến trúc(artifacts) được đề xuất trong ADM.

Mô hình Siêu dữ liệu Doanh nghiệp ở mức Foundation (Foundation Enterprise Metamodel) được minh họa trong Hình 3-8.

Hình 3-8: The TOGAF Core Enterprise Metamodel

3.12. Thiết lập và Duy trì Năng lực Kiến trúc Doanh nghiệp

Để thực hiện các hoạt động kiến trúc một cách hiệu quả trong doanh nghiệp, cần thiết lập một năng lực kinh doanh phù hợp cho công tác kiến trúc (business capability for architecture) thông qua:

  • Cơ cấu tổ chức (organization structures)
  • Vai trò (roles)
  • Trách nhiệm (responsibilities)
  • Kỹ năng (skills)
  • Quy trình (processes)

Tổng quan về Năng lực Kiến trúc TOGAF (TOGAF Architecture Capability) được minh họa trong Hình 3-9.

Hình 3-9: Tổng quan năng lực kiến trúc TOGAF

3.13. Thiết lập Năng lực Kiến trúc như một Thực thể Vận hành

Ngoại trừ các Năng lực Kiến trúc (Architecture Capability) được thiết lập chỉ để hỗ trợ các chương trình triển khai thay đổi, ngày càng có sự đồng thuận rằng một thực hành Kiến trúc Doanh nghiệp thành công phải được xây dựng trên nền tảng vận hành vững chắc.

Thực tế, một bộ phận Kiến trúc Doanh nghiệp cần được vận hành như bất kỳ đơn vị vận hành nào khác trong doanh nghiệp — nghĩa là phải được quản lý như một doanh nghiệp.

Vì vậy, bên cạnh các quy trình cốt lõi được định nghĩa trong ADM, bộ phận Kiến trúc Doanh nghiệp nên thiết lập năng lực trong các lĩnh vực sau:

  • Quản lý tài chính (Financial Management)
  • Quản lý hiệu suất (Performance Management)
  • Quản lý dịch vụ (Service Management)
  • Quản lý rủi ro và cơ hội (Risk and Opportunity Management)
  • Quản lý nguồn lực (Resource Management)
  • Quản lý truyền thông và các bên liên quan (Communications and Stakeholder Management)
  • Quản lý chất lượng (Quality Management)
  • Quản lý nhà cung cấp (Supplier Management)
  • Quản lý cấu hình (Configuration Management)
  • Quản lý môi trường (Environment Management)

Cốt lõi của việc vận hành kiến trúc lâu dài là thực hiện quản trị (governance) một cách rõ ràng và hiệu quả, đảm bảo mọi hoạt động quan trọng về mặt kiến trúc đều được kiểm soát và điều phối trong một khung thống nhất.

Khi quản trị trở thành yêu cầu ngày càng rõ ràng đối với quản lý tổ chức, việc đưa yếu tố quản trị vào Tiêu chuẩn TOGAF không chỉ giúp khung này phù hợp với thực tiễn quản trị doanh nghiệp hiện đại, mà còn đảm bảo mức độ minh bạch, hướng dẫn và kiểm soát đáp ứng nhu cầu và nghĩa vụ của tất cả các bên liên quan đến kiến trúc.

Lợi ích của Quản trị Kiến trúc (Architecture Governance):

  • Tăng tính minh bạch về trách nhiệm và ủy quyền có căn cứ
  • Quản lý rủi ro và cơ hội một cách chủ động
  • Bảo vệ tài sản hiện có bằng cách tối đa hóa tái sử dụng các thành phần kiến trúc đã tồn tại
  • Thiết lập cơ chế kiểm soát, giám sát và quản lý chủ động
  • Tái sử dụng quy trình, khái niệm và thành phần trên mọi đơn vị kinh doanh của tổ chức
  • Tạo giá trị thông qua theo dõi, đo lường, đánh giá và phản hồi
  • Tăng tính minh bạch, hỗ trợ quy trình nội bộ và yêu cầu của các bên bên ngoài; đặc biệt là đảm bảo giám sát thích hợp đối với các quyết định có thể ảnh hưởng chiến lược lâu dài
  • Tăng giá trị cho cổ đông; trong đó, Kiến trúc Doanh nghiệp ngày càng được coi là tài sản trí tuệ cốt lõi của tổ chức — nhiều nghiên cứu đã chỉ ra mối liên hệ giữa giá trị cổ đông gia tăng và quản trị doanh nghiệp tốt
  • Tích hợp với các quy trình và phương pháp hiện có, đồng thời bổ sung khả năng kiểm soát

Chi tiết hơn về việc thiết lập Năng lực Kiến trúc Doanh nghiệp có thể tham khảo trong TOGAF Standard — EA Capability and Governance.

3.14. Sử dụng TOGAF cùng các khung khác

Một khung kiến trúc doanh nghiệp (EA framework) thường có 2 yếu tố chính:

  1. Danh sách sản phẩm/deliverables mà hoạt động kiến trúc cần tạo ra.
  2. Phương pháp để tạo ra các sản phẩm đó.

Nhiều framework EA chỉ tập trung vào (1) mà ít hoặc không mô tả (2).

TOGAF là khung tổng quát, linh hoạt và có thể mở rộng. Nó cung cấp bộ deliverables chung nhưng cho phép:

  • Sử dụng nguyên bản TOGAF với các deliverables mặc định.
  • Hoặc thay thế/mở rộng deliverables bằng bộ cụ thể hơn từ framework khác.

Người kiến trúc sư có thể tùy chỉnh TOGAF để phù hợp với quy trình và cơ cấu tổ chức của doanh nghiệp, bằng cách:

  • Kết hợp các phần từ framework khác (ITIL, CMMI, COBIT, PRINCE2, PMBOK, MSP, IT4IT, …).
  • Điều chỉnh phương pháp ADM theo hướng dẫn trong TOGAF Standard — ADM Techniques.

Điểm mạnh của TOGAF là có thể tích hợp với các khung dọc (theo ngành), khung ngang (theo công nghệ) hoặc khung theo ứng dụng để tạo lợi thế cạnh tranh.

3.15. Sử dụng Khung TOGAF với các phong cách kiến trúc Khác nhau

TOGAF được thiết kế linh hoạt để dùng với nhiều phong cách kiến trúc (architectural styles) khác nhau — mỗi phong cách có trọng tâm, hình thức, kỹ thuật, tài liệu và thời điểm áp dụng riêng.

Một tổ chức thường có nhiều phong cách kiến trúc song song trong Architecture Landscape. TOGAF đảm bảo rằng mọi nhu cầu của các bên liên quan (stakeholders) được giải quyết hài hòa.

Cách áp dụng TOGAF cho một phong cách kiến trúc cụ thể:

  • Xác định đặc trưng của phong cách đó.
  • Điều chỉnh cách tiếp cận: không thay đổi lớn TOGAF, mà điều chỉnh mô hình, quan điểm, công cụ cho phù hợp.

Trong Phase B, C, D:

  • Chọn tài nguyên (models, viewpoints, tools) phù hợp để mô tả kiến trúc và đáp ứng yêu cầu stakeholder.
  • Có thể bổ sung yếu tố mới, nhấn mạnh yếu tố có sẵn, đổi ký hiệu, hoặc tập trung vào nhóm stakeholder đặc biệt.

Việc điều chỉnh thường liên quan đến:

  • Mở rộng Architecture Content Metamodel.
  • Sử dụng ký hiệu hoặc kỹ thuật mô hình đặc thù.
  • Thêm viewpoints phù hợp.

Nếu một phong cách chiếm ưu thế, có thể cần quay lại Preliminary Phase để điều chỉnh Architecture Capability hoặc phạm vi ADM.

Công cụ hỗ trợ phổ biến: reference model, maturity model theo phong cách.

Ví dụ về phong cách và hướng dẫn liên quan:

  • Service-Oriented Architecture (SOA) với TOGAF.
  • Tích hợp Risk & Security vào TOGAF.
  • TOGAF + SABSA.
  • TOGAF + BIAN + ArchiMate cho ngành ngân hàng.
  • TOGAF + Frameworx.
  • TOGAF + DoDAF 2.0.

Các tài liệu chi tiết nằm trong TOGAF Library.

3.16. Các Khung Nhìn (Architecture Views) và Quan điểm (Viewpoints)

Khả năng tạo ra các "khung nhìn" (views) cụ thể của từng phần trong một kiến trúc phức tạp là yếu tố nền tảng để có thể giao tiếp và xoa dịu những mối quan tâm của các bên liên quan (stakeholders) hoặc nhóm các bên liên quan.

Để đạt được sự hiểu biết đầy đủ và sự ủng hộ từ các bên liên quan, cần trình bày thông tin theo hình thức mà từng bên liên quan có thể liên hệ và hiểu được.

Vai trò của các khung nhìn kiến trúc được thể hiện trong Hình 3-10, đượ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-10:

3.17. Sự linh hoạt của doanh nghiệp (Enterprise Agility)

"Sự linh hoạt của doanh nghiệp" (Enterprise agility) là một thuật ngữ được sử dụng rộng rãi, nhưng định nghĩa chính xác thì khác nhau giữa các chuyên gia.
Dù định nghĩa thế nào, đây vẫn là yếu tố quan trọng vì nó giúp doanh nghiệp phản ứng tốt hơn trước thay đổi bằng cách:

  • Tập trung hơn vào khách hàng và sản phẩm
  • Hoạt động hiệu quả hơn
  • Đảm bảo tuân thủ các quy định một cách tốt hơn

Thuật ngữ "Agile" thường gắn liền với các quy trình phát triển phần mềm Agile, được nêu trong Tuyên ngôn Agile cho Phát triển Phần mềm (Manifesto for Agile Software Development).

Mặc dù các nguyên tắc và kỹ thuật "Agile" này có thể được áp dụng để điều chỉnh khung TOGAF, nhưng sự linh hoạt của doanh nghiệp là một khái niệm rộng hơn so với phát triển phần mềm Agile.
Vì vậy, khi điều chỉnh khung TOGAF cho một doanh nghiệp linh hoạt, cần áp dụng thêm nhiều kỹ thuật khác.

Kiến trúc doanh nghiệp cung cấp một khung cho sự thay đổi, gắn liền với cả định hướng chiến lược và giá trị kinh doanh.
Nó cho phép có một cái nhìn đầy đủ về tổ chức để:

  • Quản lý sự phức tạp
  • Hỗ trợ thay đổi liên tục
  • Quản lý rủi ro của những hậu quả ngoài dự kiến

Khung TOGAF đã đáp ứng yêu cầu này thông qua khái niệm "phân vùng" (partitions) và "cấp độ" (levels):

  • Phân vùng: xác định cách chia nhỏ công việc thành nhiều sáng kiến kiến trúc khác nhau
  • Cấp độ: xác định cách phát triển kiến trúc tổng thể ở các mức độ chi tiết khác nhau

Ngoài ra, TOGAF ADM còn hỗ trợ nhiều khái niệm đặc trưng cho vòng lặp (iteration).

Chi tiết hơn về cách điều chỉnh TOGAF ADM để hỗ trợ sự linh hoạt của doanh nghiệp được trình bày trong:

  • TOGAF® Series Guide: Applying the TOGAF® ADM using Agile Sprints
  • TOGAF® Series Guide: Enabling Enterprise Agility
  • The Open Agile Architecture™ Standard

3.18. Quản lý rủi ro (Risk Management)

Trong bất kỳ nỗ lực chuyển đổi kiến trúc/doanh nghiệp nào cũng luôn tồn tại rủi ro.
Điều quan trọng là xác định, phân loại và giảm thiểu các rủi ro này trước khi bắt đầu, để có thể theo dõi chúng trong suốt quá trình chuyển đổi.

Việc giảm thiểu rủi ro là một công việc liên tục và nhiều khi nguồn kích hoạt rủi ro có thể nằm ngoài phạm vi kiểm soát của nhóm lập kế hoạch chuyển đổi (ví dụ: sáp nhập, mua lại), do đó các nhà lập kế hoạch cần liên tục giám sát bối cảnh chuyển đổi.

Ngoài ra, cần lưu ý rằng Kiến trúc sư doanh nghiệp có thể nhận diện và giảm thiểu một số rủi ro, nhưng trong khuôn khổ quản trị, rủi ro cần phải được chấp nhận trước, rồi mới được quản lý.

Có hai mức rủi ro cần xem xét:

  1. Mức rủi ro ban đầu: phân loại rủi ro trước khi xác định và thực hiện các hành động giảm thiểu
  2. Mức rủi ro còn lại: phân loại rủi ro sau khi đã thực hiện các hành động giảm thiểu (nếu có)

Quy trình quản lý rủi ro gồm các hoạt động:

  • Phân loại rủi ro
  • Nhận diện rủi ro
  • Đánh giá rủi ro ban đầu
  • Giảm thiểu rủi ro và đánh giá rủi ro còn lại
  • Giám sát rủi ro

Phương pháp định tính để quản lý rủi ro được mô tả trong TOGAF Standard — ADM Techniques.

Các khái niệm về rủi ro cũng được tích hợp trong Kiến trúc bảo mật doanh nghiệp (Enterprise Security Architecture) được mô tả trong TOGAF® Series Guide: Integrating Risk and Security within a TOGAF® Enterprise Architecture.

Phương pháp định lượng nghiêm ngặt hơn được mô tả trong Open FAIR™ Body of Knowledge, bao gồm hai tiêu chuẩn của The Open Group:

  • Open Risk Taxonomy (O-RT)
  • Open Risk Analysis (O-RA)