Skip to content

TOGAF® Standard — Architecture Development Method

1. Giới thiệu

Chương này giới thiệu về chu trình Phương pháp phát triển kiến trúc (Architecture Development Method - ADM), việc điều chỉnh ADM, phạm vi kiến trúc và tích hợp kiến trúc.

1.1. Tổng quan về ADM

TOGAF® ADM mô tả một phương pháp để phát triển và quản lý vòng đời của Kiến trúc Doanh nghiệp, và là phần cốt lõi của Tiêu chuẩn TOGAF.

Nó tích hợp các thành phần của Tiêu chuẩn TOGAF, cũng như các tài sản kiến trúc khác có sẵn, nhằm đáp ứng nhu cầu kinh doanh của tổ chức.

1.1.1. ADM, Enterprise Continuum và Kho lưu trữ Kiến trúc

Enterprise Continuum cung cấp một khung và bối cảnh để hỗ trợ tận dụng các tài sản kiến trúc liên quan khi thực thi ADM. Những tài sản này có thể bao gồm Mô tả Kiến trúc, mô hình và các mẫu lấy từ nhiều nguồn khác nhau, như được giải thích trong Tiêu chuẩn TOGAF — Nội dung Kiến trúc.

Enterprise Continuum phân loại các tài liệu nguồn kiến trúc — bao gồm cả nội dung của các kho lưu trữ kiến trúc nội bộ của tổ chức và tập hợp các mô hình tham chiếu, tiêu chuẩn liên quan có sẵn trong ngành.

Việc triển khai thực tiễn Enterprise Continuum thường sẽ dưới dạng một Kho lưu trữ Kiến trúc (xem Tiêu chuẩn TOGAF — Nội dung Kiến trúc) bao gồm các kiến trúc tham chiếu, mô hình và mẫu đã được chấp nhận sử dụng trong doanh nghiệp, cùng với các công việc kiến trúc thực tế đã thực hiện trước đó trong doanh nghiệp. Kiến trúc sư sẽ cố gắng tái sử dụng tối đa từ Kho lưu trữ Kiến trúc những gì phù hợp với dự án đang thực hiện. (Bên cạnh tập hợp tài liệu nguồn kiến trúc, kho lưu trữ này cũng sẽ chứa các công việc phát triển kiến trúc đang trong tiến trình.)

Ở những điểm thích hợp trong suốt quá trình ADM có các nhắc nhở để cân nhắc xem kiến trúc sư nên sử dụng tài sản kiến trúc nào (nếu có) từ Kho lưu trữ Kiến trúc. Trong một số trường hợp — ví dụ, khi phát triển Kiến trúc Công nghệ — đó có thể là Kiến trúc Nền tảng TOGAF (TOGAF Foundation Architecture). Trong các trường hợp khác — ví dụ, khi phát triển Kiến trúc Kinh doanh — có thể là một mô hình tham chiếu thương mại điện tử được lấy từ ngành công nghiệp chung.

Tiêu chí đưa tài liệu nguồn vào Kho lưu trữ Kiến trúc của tổ chức thường sẽ là một phần của quy trình Quản trị Kiến trúc Doanh nghiệp. Các quy trình quản trị này nên xem xét các nguồn lực có sẵn cả bên trong và bên ngoài doanh nghiệp nhằm xác định khi nào các nguồn lực chung có thể được điều chỉnh cho phù hợp với nhu cầu doanh nghiệp cụ thể, đồng thời xác định khi nào các giải pháp cụ thể có thể được tổng quát hóa để hỗ trợ tái sử dụng rộng rãi hơn.

Trong khi sử dụng ADM, kiến trúc sư đang phát triển một bản chụp nhanh các quyết định của doanh nghiệp và các hệ quả của chúng tại các thời điểm cụ thể. Mỗi lần lặp lại của ADM sẽ điền đầy một bức tranh tổng thể đặc thù của tổ chức với tất cả các tài sản kiến trúc được nhận diện và tận dụng qua quá trình, bao gồm kiến trúc cuối cùng đặc thù cho tổ chức được giao.

Phát triển kiến trúc là một quá trình liên tục, có tính chu kỳ, và khi thực thi ADM nhiều lần theo thời gian, kiến trúc sư dần dần bổ sung thêm nhiều nội dung vào Kho lưu trữ Kiến trúc của tổ chức. Mặc dù trọng tâm chính của ADM là phát triển kiến trúc đặc thù cho doanh nghiệp, trong bối cảnh rộng hơn, ADM cũng có thể được xem như quá trình điền đầy Kho lưu trữ Kiến trúc của doanh nghiệp với các thành phần xây dựng có thể tái sử dụng, được lấy từ phía "bên trái" — phần mang tính chung hơn của Enterprise Continuum.

Thực tế, lần thực thi đầu tiên của ADM thường là khó khăn nhất, vì các tài sản kiến trúc có sẵn để tái sử dụng sẽ còn khá ít ỏi. Tuy nhiên, ngay cả trong giai đoạn phát triển này, vẫn có các tài sản kiến trúc từ các nguồn bên ngoài như Tiêu chuẩn TOGAF cũng như ngành công nghiệp CNTT nói chung có thể được tận dụng để hỗ trợ.

Các lần thực thi tiếp theo sẽ dễ dàng hơn khi ngày càng nhiều tài sản kiến trúc được nhận diện, được sử dụng để điền đầy Kho lưu trữ Kiến trúc của tổ chức, và do đó sẵn sàng cho việc tái sử dụng trong tương lai.

1.1.2. ADM và Kiến trúc Nền tảng

ADM cũng hữu ích trong việc xây dựng Kiến trúc Nền tảng của một doanh nghiệp. Các yêu cầu kinh doanh của doanh nghiệp có thể được sử dụng để xác định các định nghĩa và lựa chọn cần thiết trong Kiến trúc Nền tảng. Điều này có thể là một tập hợp các mô hình chung có thể tái sử dụng, các định nghĩa về chính sách và quản trị, hoặc thậm chí cụ thể đến mức ghi đè lựa chọn công nghệ (ví dụ, nếu được quy định bởi pháp luật). Việc xây dựng Kiến trúc Nền tảng tuân theo các nguyên tắc tương tự như đối với Kiến trúc Doanh nghiệp, với điểm khác biệt là các yêu cầu cho toàn bộ doanh nghiệp bị giới hạn trong những mối quan tâm tổng thể và do đó ít đầy đủ hơn so với một doanh nghiệp cụ thể.

Điều quan trọng cần nhận thức là các mô hình hiện có từ các nguồn khác nhau này, khi được tích hợp, có thể không nhất thiết tạo ra một Kiến trúc Doanh nghiệp nhất quán. Vấn đề "khả năng tích hợp" của các Mô tả Kiến trúc được xem xét trong Mục 1.7, "Tích hợp Kiến trúc".

1.1.3. ADM và các Hướng dẫn cũng như Kỹ thuật Hỗ trợ

Việc áp dụng TOGAF ADM được hỗ trợ bởi một tập hợp tài nguyên mở rộng — bao gồm các hướng dẫn, mẫu, danh sách kiểm tra và các tài liệu chi tiết khác. Những tài nguyên này được bao gồm trong:

  • Tiêu chuẩn TOGAF — Kỹ thuật ADM
  • Hướng dẫn Chuỗi TOGAF — phần Hướng dẫn của Tiêu chuẩn (tài liệu hướng dẫn về cách sử dụng và điều chỉnh Tiêu chuẩn TOGAF cho các nhu cầu cụ thể)
  • Các White Paper và Hướng dẫn do The Open Group công bố, được phân loại và tham chiếu trong Thư viện TOGAF (xem www.opengroup.org/togaf-library)

Các hướng dẫn và kỹ thuật riêng lẻ được mô tả riêng biệt để có thể tham chiếu từ những điểm thích hợp trong ADM khi cần thiết, thay vì để văn bản chi tiết làm rối phần mô tả chính của ADM.

1.2. Chu trình phát triển Kiến trúc

1.2.1. Những điểm chính

Dưới đây là những điểm chính về ADM:

  • ADM mang tính lặp đi lặp lại, trong suốt toàn bộ quá trình, giữa các pha và trong từng pha (xem Tiêu chuẩn TOGAF — Kỹ thuật ADM).
  • Với mỗi lần lặp của ADM, cần phải đưa ra quyết định mới về:
  • Phạm vi bao phủ của doanh nghiệp sẽ được định nghĩa
  • Mức độ chi tiết sẽ được xác định
  • Phạm vi thời gian nhắm tới, bao gồm số lượng và phạm vi của bất kỳ khoảng thời gian trung gian nào

  • Các tài sản kiến trúc sẽ được tận dụng, bao gồm:

    • Tài sản được tạo ra trong các lần lặp trước của chu trình ADM trong nội bộ doanh nghiệp
    • Tài sản có sẵn ở các nơi khác trong ngành (các framework khác, mô hình hệ thống, mô hình ngành dọc, v.v.)

  • Những quyết định này nên dựa trên việc đánh giá thực tế về nguồn lực và năng lực có sẵn, cũng như giá trị có thể kỳ vọng thực tế mà doanh nghiệp thu được từ phạm vi công việc kiến trúc được chọn.

  • Là một phương pháp tổng quát, ADM được thiết kế để được sử dụng bởi các doanh nghiệp ở nhiều vùng địa lý khác nhau và áp dụng trong các ngành/lĩnh vực dọc khác nhau.
  • Do vậy, nó có thể, nhưng không nhất thiết phải, được điều chỉnh cho phù hợp với nhu cầu cụ thể. Ví dụ, nó có thể được sử dụng kết hợp với bộ sản phẩm đầu ra của một framework khác, nếu bộ sản phẩm đó được đánh giá là phù hợp hơn cho một tổ chức cụ thể. (Ví dụ, nhiều cơ quan Liên bang Hoa Kỳ đã phát triển các framework riêng định nghĩa các sản phẩm đầu ra phù hợp với nhu cầu phòng ban cụ thể của họ.)
  • Những vấn đề này được xem xét chi tiết trong Mục 1.3, "Điều chỉnh ADM".

1.2.2. Cấu trúc cơ bản

Cấu trúc cơ bản của ADM được minh họa trong Hình 1-1, "Chu trình Phát triển Kiến trúc".

Trong suốt chu trình ADM, cần thường xuyên xác thực kết quả với các kỳ vọng ban đầu, cả những kỳ vọng cho toàn bộ chu trình ADM và cho từng pha cụ thể của quá trình.

Hình 1-1. Chu trình Phát triển Kiến trúc

Các pha trong chu trình ADM được chia nhỏ thành các bước, được định nghĩa trong phần mô tả chi tiết của từng pha.

Pha Quản lý Yêu cầu (Requirements Management) là pha liên tục, đảm bảo mọi thay đổi về yêu cầu đều được xử lý qua các quy trình quản trị thích hợp và được phản ánh trong tất cả các pha khác. Một doanh nghiệp có thể lựa chọn ghi lại tất cả các yêu cầu mới, bao gồm cả những yêu cầu nằm trong phạm vi của Báo cáo Công việc Kiến trúc hiện tại, thông qua một Kho Yêu cầu duy nhất.

Các pha của chu trình được mô tả chi tiết trong các chương tiếp theo.

Lưu ý rằng sản phẩm đầu ra được tạo ra xuyên suốt quá trình, và sản phẩm đầu ra từ pha sớm có thể được chỉnh sửa trong pha sau. Trong ADM, trạng thái của các sản phẩm đầu ra ở mỗi giai đoạn được xác định rõ. Vòng đời của các sản phẩm đầu ra phải được quản lý thông qua chính sách đánh số phiên bản, do kiến trúc sư điều chỉnh để đáp ứng yêu cầu của tổ chức và phù hợp với công cụ và kho lưu trữ kiến trúc mà tổ chức sử dụng.

Trong ADM, các tài liệu đang trong quá trình phát triển và chưa qua bất kỳ quy trình rà soát và phê duyệt chính thức nào được gọi là "bản nháp" (draft). Các tài liệu đã được rà soát và phê duyệt được gọi là "đã phê duyệt" (approved) theo quy trình quản trị của tổ chức. "Đã phê duyệt" không nhất thiết có nghĩa là tài liệu đã hoàn tất. Các tài liệu có thể tiếp tục phát triển trong các pha tiếp theo nhưng chỉ được phép thay đổi thông qua quy trình kiểm soát thay đổi và quản trị thích hợp. Điều này đặc biệt được áp dụng trong ADM để minh họa sự phát triển của Định nghĩa Kiến trúc Cơ sở (Baseline) và Kiến trúc Mục tiêu (Target Architecture).

1.3. Điều chỉnh ADM

ADM là một phương pháp tổng quát để phát triển kiến trúc, được thiết kế để xử lý hầu hết các yêu cầu về hệ thống và tổ chức. Tuy nhiên, thường sẽ cần thiết phải sửa đổi hoặc mở rộng ADM để phù hợp với những nhu cầu cụ thể. Một trong những nhiệm vụ trước khi áp dụng ADM là xem xét các thành phần của nó để đánh giá tính áp dụng, sau đó điều chỉnh cho phù hợp với hoàn cảnh của từng doanh nghiệp riêng biệt. Hoạt động này có thể tạo ra một "ADM đặc thù cho doanh nghiệp".

Một lý do quan trọng để điều chỉnh ADM là thứ tự các pha trong ADM phần nào phụ thuộc vào mức độ trưởng thành của lĩnh vực kiến trúc trong doanh nghiệp. Ví dụ, nếu việc làm kiến trúc không được công nhận rõ ràng về mặt kinh doanh, thì việc tạo ra Tầm nhìn Kiến trúc hầu như luôn là điều cần thiết; và một Kiến trúc Kinh doanh chi tiết thường cần đến ngay sau đó, nhằm làm nền tảng cho Tầm nhìn Kiến trúc, cụ thể hóa lý do kinh doanh cho các công việc kiến trúc còn lại, và đảm bảo sự tham gia tích cực của các bên liên quan chủ chốt trong công việc đó. Trong những trường hợp khác, thứ tự có thể hơi khác; ví dụ, có thể thực hiện một kiểm kê chi tiết môi trường cơ sở (baseline) trước khi tiến hành Kiến trúc Kinh doanh.

Thứ tự các pha cũng có thể được xác định bởi các Nguyên tắc Kiến trúc và nguyên tắc kinh doanh của doanh nghiệp. Ví dụ, nguyên tắc kinh doanh có thể quy định doanh nghiệp phải sẵn sàng điều chỉnh các quy trình kinh doanh của mình để đáp ứng nhu cầu của một giải pháp đóng gói (packaged solution), nhằm triển khai nhanh chóng để có phản ứng nhanh với sự thay đổi của thị trường. Trong trường hợp đó, Kiến trúc Kinh doanh (hoặc ít nhất là việc hoàn thành nó) có thể diễn ra sau khi hoàn thành Kiến trúc Hệ thống Thông tin hoặc Kiến trúc Công nghệ.

Một lý do khác để điều chỉnh ADM là nếu framework TOGAF cần được tích hợp với một framework doanh nghiệp khác (như đã giải thích trong Tiêu chuẩn TOGAF — Phần Giới thiệu và Các Khái niệm Cơ bản). Ví dụ, một doanh nghiệp có thể muốn sử dụng framework TOGAF và ADM tổng quát của nó kết hợp với Zachman® Framework, hoặc một framework Kiến trúc Doanh nghiệp khác có bộ sản phẩm đầu ra được định nghĩa rõ ràng cho một ngành dọc cụ thể: Chính phủ, Quốc phòng, Thương mại điện tử, Viễn thông, v.v. ADM đã được thiết kế đặc biệt với khả năng tích hợp tiềm năng này.

Các lý do khác có thể muốn điều chỉnh ADM bao gồm:

  • ADM là một trong nhiều quy trình doanh nghiệp cấu thành mô hình quản trị doanh nghiệp
  • Nó bổ trợ và hỗ trợ các quy trình quản lý chương trình tiêu chuẩn khác, như các quy trình về cấp phép, quản lý rủi ro, lập kế hoạch kinh doanh và ngân sách, lập kế hoạch phát triển, phát triển hệ thống và mua sắm.
  • ADM được chỉ định bắt buộc sử dụng bởi nhà thầu chính hoặc nhà thầu dẫn đầu trong trường hợp thuê ngoài (outsourcing), và cần được điều chỉnh để đạt được sự thỏa hiệp phù hợp giữa thực tiễn hiện có của nhà thầu và yêu cầu của doanh nghiệp thuê thầu.
  • Doanh nghiệp là doanh nghiệp nhỏ hoặc vừa, và muốn sử dụng một phương pháp "rút gọn" phù hợp hơn với mức độ tài nguyên và độ phức tạp hệ thống giảm so với môi trường điển hình.
  • Doanh nghiệp rất lớn và phức tạp, bao gồm nhiều "doanh nghiệp" riêng biệt nhưng liên kết với nhau trong một khung kinh doanh hợp tác tổng thể, và phương pháp kiến trúc cần được điều chỉnh để nhận biết điều này.

Các cách tiếp cận khác nhau về lập kế hoạch và tích hợp có thể được sử dụng trong những trường hợp này, bao gồm (có thể kết hợp):

  • Lập kế hoạch và phát triển từ trên xuống — thiết kế toàn bộ siêu doanh nghiệp kết nối với nhau như một thực thể duy nhất (một công việc thường thử thách giới hạn thực tiễn)
  • Phát triển một kiến trúc "chung" hoặc "tham chiếu", điển hình cho các doanh nghiệp trong tổ chức, nhưng không đại diện cho bất kỳ doanh nghiệp cụ thể nào, mà từng doanh nghiệp riêng biệt sẽ điều chỉnh để tạo ra một "bản kiến trúc" phù hợp với doanh nghiệp đó
  • Sao chép — phát triển một kiến trúc cụ thể cho một doanh nghiệp, triển khai nó như một mô hình thử nghiệm, rồi sử dụng kiến trúc đó như "kiến trúc tham chiếu" để nhân bản cho các doanh nghiệp khác

Trong môi trường nhà cung cấp hoặc sản xuất, một kiến trúc chung cho một dòng sản phẩm liên quan thường được gọi là "Kiến trúc Dòng Sản phẩm" (Product Line Architecture), và quy trình tương tự như trên được gọi là "Kỹ thuật Dòng Sản phẩm (dựa trên kiến trúc)". ADM chủ yếu hướng tới các kiến trúc sư trong các doanh nghiệp người dùng CNTT, nhưng một tổ chức nhà cung cấp có sản phẩm dựa trên CNTT cũng có thể muốn điều chỉnh nó như một phương pháp tổng quát để phát triển Kiến trúc Dòng Sản phẩm.

Các mô tả về các pha của ADM chứa danh sách các sản phẩm đầu ra và các vật phẩm có thể áp dụng cho bất kỳ doanh nghiệp nào. Điều quan trọng là điều chỉnh các sản phẩm đầu ra và vật phẩm để phản ánh nhu cầu cụ thể của doanh nghiệp đối với kiến trúc cần thiết.

Việc điều chỉnh Khung Nội dung và Mô hình Doanh nghiệp, định nghĩa các sản phẩm đầu ra và vật phẩm đặc thù cho tổ chức, cùng với mô tả chi tiết các sản phẩm đầu ra và vật phẩm cụ thể được tham chiếu trong mô tả các pha ADM có thể được tìm thấy trong Tiêu chuẩn TOGAF — Nội dung Kiến trúc.

ADM cũng có thể được điều chỉnh để hỗ trợ phong cách triển khai Kiến trúc Doanh nghiệp theo Agile cũng như để tăng tính linh hoạt cho doanh nghiệp. Hướng dẫn chi tiết về cách điều chỉnh ADM có thể được tìm thấy trong các tài liệu sau:

  • TOGAF Series Guide: Enabling Enterprise Agility
  • TOGAF® Series Guide: Applying the TOGAF® ADM using Agile Sprints

1.4. Quản trị Kiến trúc

ADM, dù được tổ chức điều chỉnh hay sử dụng nguyên bản như trong tài liệu này, là một quy trình quan trọng cần được quản lý tương tự như các hiện vật kiến trúc khác được phân loại thông qua Enterprise Continuum và lưu trữ trong Kho lưu trữ kiến trúc (Architecture Repository). Hội đồng Kiến trúc (Architecture Board) cần đảm bảo rằng phương pháp này được áp dụng đúng đắn trên tất cả các giai đoạn của một vòng phát triển kiến trúc. Việc tuân thủ ADM là yếu tố nền tảng của quản trị kiến trúc, nhằm đảm bảo tất cả các yếu tố đều được xem xét và mọi sản phẩm bàn giao cần thiết đều được tạo ra.

Việc quản lý tất cả các hiện vật kiến trúc, quy trình quản trị, và các quy trình liên quan cần được hỗ trợ bởi một môi trường kiểm soát. Thông thường, môi trường này sẽ dựa trên một hoặc nhiều kho lưu trữ (repository) hỗ trợ các đối tượng có phiên bản, kiểm soát quy trình và trạng thái.

Các lĩnh vực thông tin chính được quản lý bởi một governance repository nên bao gồm các loại thông tin sau:

  • Dữ liệu tham chiếu (Reference Data): (tài liệu từ các kho lưu trữ nội bộ hoặc từ Enterprise Continuum của tổ chức, bao gồm dữ liệu bên ngoài; ví dụ: COBIT®, IT4IT® Reference Architecture) được sử dụng cho mục đích hướng dẫn và chỉ đạo trong quá trình triển khai dự án.
    Điều này bao gồm chi tiết về các thủ tục quản trị. Dữ liệu tham chiếu cũng bao gồm mô tả về chính các quy trình quản trị.

  • Trạng thái quy trình (Process Status): tất cả thông tin liên quan đến trạng thái của bất kỳ quy trình quản trị nào sẽ được quản lý.
    Ví dụ: các yêu cầu tuân thủ còn tồn đọng, các yêu cầu miễn trừ, và các cuộc điều tra đánh giá tuân thủ.

  • Thông tin kiểm toán (Audit Information): ghi lại tất cả các hành động của quy trình quản trị đã hoàn tất và được sử dụng để:

  • Lưu trữ các quyết định quan trọng và người chịu trách nhiệm cho bất kỳ dự án kiến trúc nào đã được phê duyệt thông qua quy trình quản trị.
  • Làm tài liệu tham khảo cho các phát triển kiến trúc và quy trình hỗ trợ trong tương lai, cung cấp hướng dẫn và tiền lệ.

Các hiện vật quản trị và quy trình quản trị bản thân chúng cũng là một phần nội dung của Architecture Repository.

Quản trị kiến trúc được đề cập chi tiết trong TOGAF Standard — EA Capability and Governance.

1.5. Xác định phạm vi Kiến trúc

Có nhiều lý do để giới hạn (hoặc ràng buộc) phạm vi của hoạt động kiến trúc sẽ được thực hiện, hầu hết liên quan đến giới hạn về:

  • Thẩm quyền tổ chức của nhóm xây dựng kiến trúc.
  • Mục tiêu và mối quan tâm của các bên liên quan cần được giải quyết trong kiến trúc.
  • Nguồn lực: nhân sự, tài chính, và các tài nguyên khác

Phạm vi được lựa chọn cho hoạt động kiến trúc, lý tưởng nhất, nên cho phép công việc của tất cả các kiến trúc sư trong tổ chức được quản trị và tích hợp hiệu quả. Điều này đòi hỏi phải có một tập hợp các "phân vùng kiến trúc" (architecture partitions) được liên kết, đảm bảo rằng các kiến trúc sư không làm việc trùng lặp hoặc mâu thuẫn. Ngoài ra, cần xác định mối quan hệ tái sử dụng và tuân thủ giữa các phân vùng kiến trúc.

Việc phân chia tổ chức và hoạt động liên quan đến kiến trúc được trình bày chi tiết hơn trong TOGAF Standard — Applying the ADM.

Thông thường, bốn chiều được sử dụng để xác định và giới hạn phạm vi của một kiến trúc:

  1. Chiều rộng (Breadth): toàn bộ phạm vi của doanh nghiệp là gì, và phần nào trong phạm vi đó mà nỗ lực kiến trúc này sẽ xử lý?
  2. Nhiều doanh nghiệp có quy mô rất lớn, về cơ bản bao gồm một liên minh các đơn vị tổ chức mà mỗi đơn vị có thể được coi là một doanh nghiệp độc lập.

  3. Doanh nghiệp hiện đại ngày càng mở rộng ra ngoài các ranh giới truyền thống của nó, để bao gồm một sự kết hợp không rõ ràng giữa doanh nghiệp kinh doanh truyền thống với các nhà cung cấp, khách hàng và đối tác.

  4. Chiều sâu (Depth): mức độ chi tiết mà nỗ lực kiến trúc nên đạt đến là bao nhiêu?

  5. Bao nhiêu kiến trúc là "đủ"? Ranh giới thích hợp giữa nỗ lực kiến trúc và các hoạt động liên quan khác (thiết kế hệ thống, kỹ thuật hệ thống, phát triển hệ thống) là gì?

  6. Khoảng thời gian (Time Period): khoảng thời gian nào cần được trình bày cho Tầm nhìn Kiến trúc (Architecture Vision), và liệu có hợp lý (về mặt tính khả thi và nguồn lực) để cùng khoảng thời gian đó được bao quát trong Mô tả Kiến trúc (Architecture Description) chi tiết hay không?

  7. Nếu không, cần xác định bao nhiêu Kiến trúc Chuyển tiếp (Transition Architectures), và khoảng thời gian của chúng là bao nhiêu?

  8. Các miền kiến trúc (Architecture Domains): một Mô tả Kiến trúc Doanh nghiệp đầy đủ nên bao gồm cả bốn miền kiến trúc: Kinh doanh (Business), Dữ liệu (Data), Ứng dụng (Application) và Công nghệ (Technology).

  9. Tuy nhiên, thực tế về giới hạn nguồn lực và thời gian thường có nghĩa là không có đủ thời gian, kinh phí, hoặc nguồn lực để xây dựng một Mô tả Kiến trúc từ trên xuống, bao quát tất cả bốn miền kiến trúc, ngay cả khi phạm vi doanh nghiệp được chọn nhỏ hơn toàn bộ phạm vi của doanh nghiệp.

Thông thường, phạm vi của một kiến trúc trước tiên được thể hiện theo chiều rộng, chiều sâu và thời gian. Khi các chiều này đã được hiểu rõ, có thể lựa chọn một tổ hợp phù hợp các miền kiến trúc tương ứng với vấn đề cần giải quyết. Các kỹ thuật sử dụng ADM để phát triển nhiều kiến trúc có liên quan được thảo luận trong TOGAF Standard — Applying the ADM.

Lưu ý quan trọng

Bốn chiều của phạm vi kiến trúc được khám phá chi tiết ở phần sau. Trong mỗi trường hợp, đặc biệt là trong các môi trường quy mô lớn nơi kiến trúc bắt buộc phải được phát triển theo phương thức liên bang (federated), luôn tồn tại nguy cơ các kiến trúc sư tối ưu hóa trong phạm vi hoạt động của riêng họ thay vì ở cấp độ toàn doanh nghiệp. Thường thì cần phải tối ưu hóa cục bộ trong một khu vực cụ thể để tối ưu hóa ở cấp độ doanh nghiệp. Mục tiêu luôn nên là tìm kiếm mức độ tương đồng cao nhất và tập trung vào các mô-đun có thể mở rộng và tái sử dụng, nhằm tối đa hóa việc tái sử dụng ở cấp độ doanh nghiệp.

1.5.1. Chiều rộng (Breadth)

Một trong những quyết định quan trọng là xác định trọng tâm của nỗ lực kiến trúc, xét theo chiều rộng của toàn bộ hoạt động doanh nghiệp sẽ được bao phủ (bao gồm những lĩnh vực kinh doanh cụ thể nào, các chức năng, tổ chức, khu vực địa lý, v.v.).

Thường thì cần phải có nhiều kiến trúc khác nhau tồn tại trong toàn doanh nghiệp, tập trung vào các khung thời gian cụ thể, các chức năng kinh doanh riêng, hoặc những yêu cầu nghiệp vụ nhất định.

Đối với các doanh nghiệp lớn và phức tạp, kiến trúc liên bang (federated architectures) — tức các kiến trúc được phát triển, duy trì và quản lý một cách độc lập, sau đó được tích hợp trong một khung tích hợp — là điều thường gặp. Khung tích hợp này xác định các nguyên tắc về khả năng tương tác, di trú, và tuân thủ. Cách tiếp cận này cho phép các đơn vị kinh doanh cụ thể có kiến trúc riêng, được phát triển và quản trị như những dự án kiến trúc độc lập. Thông tin chi tiết và hướng dẫn về việc xác định yêu cầu khả năng tương tác cho các giải pháp khác nhau có thể tham khảo trong TOGAF Standard — ADM Techniques.

Tính khả thi của một kiến trúc chung toàn doanh nghiệp cho mọi chức năng hoặc mục đích có thể bị loại bỏ vì quá phức tạp và cồng kềnh. Trong những trường hợp như vậy, nên có nhiều Kiến trúc Doanh nghiệp khác nhau tồn tại trong doanh nghiệp. Những kiến trúc này tập trung vào các khung thời gian, phân khúc hoặc chức năng kinh doanh, và các yêu cầu tổ chức cụ thể. Khi đó, cần xây dựng Kiến trúc Doanh nghiệp tổng thể như một "liên bang" của các Kiến trúc Doanh nghiệp này.

Một cách hiệu quả để quản lý và khai thác những Kiến trúc Doanh nghiệp này là áp dụng mô hình xuất bản-và-đăng ký (publish-and-subscribe), cho phép kiến trúc được đưa vào trong khung quản trị. Trong mô hình này, những người phát triển kiến trúc và những người tiêu thụ kiến trúc trong các dự án (tức là phía cung và cầu của công việc kiến trúc) đăng ký tham gia vào một khung quản trị mang lại lợi ích chung, đảm bảo rằng:

  • Tài liệu kiến trúc có chất lượng tốt, được cập nhật, phù hợp mục đích và được công bố (đã được rà soát và đồng ý cho công bố).
  • Việc sử dụng tài liệu kiến trúc có thể được giám sát, và việc tuân thủ các tiêu chuẩn, mô hình, và nguyên tắc có thể được thể hiện thông qua:
  • Quy trình Đánh giá Tuân thủ (Compliance Assessment) mô tả nội dung mà người sử dụng đăng ký, và đánh giá mức độ tuân thủ của họ.
  • Quy trình miễn trừ (dispensation process) có thể cấp phép miễn trừ việc tuân thủ các tiêu chuẩn và hướng dẫn kiến trúc trong những trường hợp cụ thể (thường là khi có lý do kinh doanh mạnh mẽ).

Kỹ thuật xuất bản-và-đăng ký đang được phát triển như một phần của quản trị CNTT nói chung, và đặc biệt trong lĩnh vực Quốc phòng.

1.5.2. Chiều sâu (Depth)

Cần thận trọng khi đánh giá mức độ chi tiết phù hợp cần được ghi nhận, dựa trên mục đích sử dụng của Kiến trúc Doanh nghiệp và các quyết định sẽ được đưa ra dựa trên đó.

Điều quan trọng là phải đảm bảo rằng một mức độ chi tiết nhất quán và đồng đều được hoàn thiện trong từng miền kiến trúc (Kinh doanh, Dữ liệu, Ứng dụng, Công nghệ) được bao gồm trong nỗ lực kiến trúc.

Nếu các chi tiết liên quan bị bỏ sót, kiến trúc có thể trở nên vô dụng. Ngược lại, nếu bao gồm các chi tiết không cần thiết, nỗ lực kiến trúc có thể vượt quá thời gian và nguồn lực sẵn có, và/hoặc kiến trúc kết quả có thể trở nên rối rắm hoặc khó hiểu. Việc phát triển kiến trúc ở các mức độ chi tiết khác nhau trong một doanh nghiệp được bàn sâu hơn trong TOGAF Standard — Applying the ADM.

Ngoài ra, điều quan trọng là cần dự đoán các mục đích sử dụng trong tương lai của kiến trúc để, trong phạm vi giới hạn nguồn lực, có thể cấu trúc kiến trúc sao cho phù hợp cho việc tùy chỉnh, mở rộng hoặc tái sử dụng sau này.
Mức độ chi tiết của Kiến trúc Doanh nghiệp cần đủ để phục vụ mục đích của nó, và không hơn.

Các vòng lặp của ADM sẽ xây dựng dựa trên các tạo phẩm kiến trúc (artifacts) và năng lực đã được tạo ra trong các vòng lặp trước đó.

Cần phải ghi lại tất cả các mô hình trong doanh nghiệp, ở mức độ chi tiết phù hợp với nhu cầu của chu trình ADM hiện tại.
Điểm mấu chốt là cần hiểu rõ trạng thái công việc kiến trúc của doanh nghiệp và những gì có thể thực hiện được một cách thực tế với nguồn lực và năng lực hiện có, rồi tập trung vào việc xác định và cung cấp giá trị khả thi.
Giá trị cho các bên liên quan là yếu tố trọng tâm: phạm vi quá rộng có thể làm nản lòng một số bên liên quan (vì không thấy được lợi tức đầu tư).

1.5.3. Khoảng thời gian (Time Period)

ADM được mô tả theo một vòng lặp duy nhất của Tầm nhìn Kiến trúc (Architecture Vision), cùng với một tập hợp Kiến trúc Mục tiêu (Target Architectures) (Kinh doanh, Dữ liệu, Ứng dụng, Công nghệ) cho phép hiện thực hóa tầm nhìn đó.

Trong một số trường hợp, có thể áp dụng một cách tiếp cận rộng hơn, theo đó doanh nghiệp được biểu diễn bởi nhiều phiên bản kiến trúc khác nhau (ví dụ: chiến lược, phân đoạn, năng lực), mỗi phiên bản đại diện cho doanh nghiệp tại một thời điểm nhất định. Một phiên bản kiến trúc sẽ thể hiện trạng thái hiện tại của doanh nghiệp ("as-is" hay kiến trúc gốc/baseline). Một phiên bản kiến trúc khác, có thể chỉ được xác định một phần, sẽ thể hiện trạng thái mục tiêu cuối cùng ("vision"). Ở giữa, có thể xác định các phiên bản Kiến trúc Chuyển tiếp (Transition Architecture), mỗi phiên bản bao gồm tập hợp riêng các mô tả Kiến trúc Mục tiêu của nó. Ví dụ về cách thực hiện điều này được nêu trong TOGAF Standard — ADM Techniques.

Với cách tiếp cận này, công việc xây dựng Kiến trúc Mục tiêu được chia thành hai hoặc nhiều giai đoạn riêng biệt:

  1. Phát triển các mô tả Kiến trúc Mục tiêu cho toàn bộ hệ thống (quy mô lớn), thể hiện cách đáp ứng các mục tiêu và mối quan tâm của các bên liên quan cho một khung thời gian tương đối xa (ví dụ: 6 năm).
  2. Phát triển một hoặc nhiều mô tả Kiến trúc Chuyển tiếp, đóng vai trò như các bước tăng trưởng hoặc các "cao nguyên" (plateaus), mỗi mô tả phù hợp và hội tụ vào Kiến trúc Mục tiêu, đồng thời mô tả chi tiết các yếu tố cụ thể của giai đoạn tăng trưởng đó.

Trong cách tiếp cận này:

  • Kiến trúc Mục tiêu mang tính tiến hóa, cần được rà soát và cập nhật định kỳ theo yêu cầu kinh doanh và sự phát triển công nghệ.
  • Kiến trúc Chuyển tiếp mang tính tăng trưởng từng bước, và về nguyên tắc không nên thay đổi trong giai đoạn triển khai của bước đó, nhằm tránh hiện tượng "mục tiêu di động" (moving target). Điều này chỉ khả thi nếu lịch triển khai được kiểm soát chặt chẽ và tương đối ngắn (thường dưới 2 năm).

Kiến trúc Mục tiêu thường mang tính tổng quát, nên ít bị lỗi thời hơn Kiến trúc Chuyển tiếp.
Chúng chỉ chứa các quyết định chiến lược kiến trúc then chốt, vốn cần được các bên liên quan phê duyệt ngay từ đầu.
Ngược lại, các quyết định chi tiết trong Kiến trúc Chuyển tiếp được cố tình trì hoãn càng lâu càng tốt (tức là ngay trước khi triển khai) để tăng khả năng phản ứng trước công nghệ và sản phẩm mới.

Doanh nghiệp sẽ tiến hóa bằng cách di chuyển lần lượt qua từng Kiến trúc Chuyển tiếp. Khi mỗi Kiến trúc Chuyển tiếp được triển khai, doanh nghiệp sẽ đạt được trạng thái vận hành ổn định trên hành trình hướng tới tầm nhìn cuối cùng.
Tuy nhiên, tầm nhìn này sẽ được cập nhật định kỳ để phản ánh những thay đổi trong môi trường kinh doanh và công nghệ, và trên thực tế có thể không bao giờ đạt được đúng như mô tả ban đầu. Toàn bộ quá trình này tiếp tục miễn là doanh nghiệp vẫn tồn tại và thay đổi.

Việc phân tách Mô tả Kiến trúc thành một tập hợp các sản phẩm kiến trúc liên quan tất nhiên đòi hỏi quản lý hiệu quả tập hợp này và các mối quan hệ của chúng.

1.5.4. Các miền kiến trúc (Architecture Domains)

Một Kiến trúc Doanh nghiệp (Enterprise Architecture) đầy đủ nên bao gồm cả bốn miền kiến trúc:

  1. Kiến trúc Nghiệp vụ (Business Architecture)
  2. Kiến trúc Dữ liệu (Data Architecture)
  3. Kiến trúc Ứng dụng (Application Architecture)
  4. Kiến trúc Công nghệ (Technology Architecture)

Tuy nhiên, thực tế về hạn chế nguồn lực và thời gian thường đồng nghĩa với việc không đủ thời gian, kinh phí, hoặc nguồn lực để xây dựng một Mô tả Kiến trúc (Architecture Description) theo hướng top-down bao quát toàn bộ cả bốn miền kiến trúc.

Các Mô tả Kiến trúc thường được xây dựng với mục đích cụ thể — tức là một tập hợp động lực kinh doanh (business drivers) nhất định thúc đẩy việc phát triển kiến trúc.
Việc làm rõ các vấn đề cụ thể mà Mô tả Kiến trúc nhằm hỗ trợ khám phá, và các câu hỏi mà nó cần giúp trả lời, là phần quan trọng của giai đoạn đầu trong ADM.

Ví dụ: nếu mục tiêu của một nỗ lực kiến trúc cụ thể là xác định và xem xét các lựa chọn công nghệ để đạt được một năng lực cụ thể, và các quy trình kinh doanh cốt lõi không được phép thay đổi, thì việc xây dựng đầy đủ Kiến trúc Nghiệp vụ có thể không cần thiết.
Tuy nhiên, vì Kiến trúc Dữ liệu, Ứng dụng và Công nghệ được xây dựng dựa trên Kiến trúc Nghiệp vụ, nên vẫn cần phải xem xét và hiểu rõ Kiến trúc Kinh doanh.

Mặc dù hoàn cảnh đôi khi có thể buộc phải xây dựng một Mô tả Kiến trúc không bao gồm cả bốn miền kiến trúc, cần hiểu rằng kiến trúc như vậy, theo định nghĩa, sẽ không phải là một Kiến trúc Doanh nghiệp hoàn chỉnh.
Một trong những rủi ro là thiếu tính nhất quán, và do đó khó tích hợp.
Việc tích hợp có thể phải thực hiện sau này — với chi phí và rủi ro riêng — hoặc các rủi ro và đánh đổi phát sinh khi không phát triển một kiến trúc đầy đủ và tích hợp cần được kiến trúc sư làm rõ, đồng thời truyền đạt và đảm bảo doanh nghiệp hiểu.

1.6. Các phương án Kiến trúc

Thường sẽ có nhiều hơn một Kiến trúc Mục tiêu khả thi đáp ứng Tầm nhìn Kiến trúc, Các Nguyên tắc Kiến trúc, và Các Yêu cầu. Việc xác định các phương án Kiến trúc Mục tiêu thay thế, xây dựng sự hiểu biết về các khả năng khác nhau, và nhận diện các đánh đổi giữa các phương án là rất quan trọng. Việc tạo ra một kiến trúc thường đòi hỏi phải cân nhắc đánh đổi giữa các lực tác động cạnh tranh. Việc trình bày các phương án và đánh đổi khác nhau cho các bên liên quan giúp kiến trúc sư khám phá những mục tiêu tiềm ẩn, nguyên tắc, và yêu cầu có thể ảnh hưởng đến Kiến trúc Mục tiêu cuối cùng.

1.6.1. Phương pháp (Method)

Thông thường, sẽ không tồn tại một phương án duy nhất có thể đáp ứng tất cả các mối quan tâm của các bên liên quan. Tiêu chuẩn TOGAF (xem TOGAF Standard — ADM Techniques: Architecture Alternatives and Trade-offs) cung cấp một kỹ thuật để nghiên cứu các phương án khác nhau và thảo luận các phương án này với các bên liên quan.

Thông thường, các phương án được xác định theo từng miền kiến trúc. Cách làm này nhằm đơn giản hóa việc phân tích các phương án khác nhau. Tất nhiên, các phương án theo từng miền có thể được tổng hợp lại thành một phân tích tổng thể cho toàn bộ kiến trúc. Cách tiếp cận này được minh họa trong Hình 1-2, "Phương pháp Các phương án Kiến trúc". 8 Hình 1-2: Phương pháp Các phương án Kiến trúc

  • Bước 1: Sử dụng tầm nhìn, nguyên tắc, yêu cầu và các thông tin khác để chọn các bộ tiêu chí phù hợp cho các phương án khác nhau.
  • Bước 2: Xác định các phương án dựa trên các tiêu chí và xây dựng sự hiểu biết về từng phương án.
  • Bước 3: Lựa chọn một trong các phương án, hoặc kết hợp các tính năng từ nhiều phương án để tạo ra phương án đề xuất. Các hoạt động trong bước này cần được thực hiện với đủ chi tiết để hỗ trợ quyết định đó.

Phương pháp này có thể được sử dụng cho bất kỳ pha nào ở bất kỳ cấp độ nào của kiến trúc.

1.7. Tích hợp Kiến trúc (Architecture Integration)

Các kiến trúc được tạo ra nhằm giải quyết một tập hợp con các vấn đề trong một doanh nghiệp cần có một khung tham chiếu nhất quán để có thể được xem xét như một nhóm thống nhất cũng như các sản phẩm bàn giao riêng lẻ.

Các chiều được sử dụng để xác định ranh giới phạm vi của một kiến trúc (ví dụ: mức độ chi tiết, miền kiến trúc, v.v.) thường cũng là các chiều cần được xem xét khi tính đến việc tích hợp nhiều kiến trúc. Hình 1-3, “Tích hợp các tạp phẩm Kiến trúc” minh họa cách các loại kiến trúc khác nhau cần cùng tồn tại.

Hình 1-3, “Tích hợp các tạp phẩm Kiến trúc

Hiện tại, việc tích hợp kiến trúc chỉ có thể được thực hiện ở mức độ thấp hơn của phổ khả năng tích hợp.
Các yếu tố chính cần xem xét bao gồm:

  • Độ chi tiết và mức độ hạt (granularity) trong mỗi hiện vật kiến trúc.
  • Mức độ trưởng thành của các tiêu chuẩn để trao đổi mô tả kiến trúc.

Khi các tổ chức giải quyết các chủ đề chung (chẳng hạn như Kiến trúc hướng dịch vụ (SOA) và hạ tầng thông tin tích hợp) và khi các mô hình dữ liệu phổ quát cùng cấu trúc dữ liệu tiêu chuẩn xuất hiện, việc tích hợp ở mức cao hơn của phổ khả năng tích hợp sẽ được thúc đẩy.
Tuy nhiên, sẽ luôn tồn tại những thách thức trong việc tích hợp đầy đủ do sự đa dạng của nhu cầu kinh doanh, môi trường công nghệ, và mức độ trưởng thành khác nhau của các giải pháp.

1.8. Tóm tắt (Summary)

TOGAF ADM xác định một trình tự khuyến nghị cho các giai đoạn và bước khác nhau liên quan đến việc phát triển kiến trúc, nhưng không thể đưa ra khuyến nghị về phạm vi — điều này phải do chính tổ chức quyết định.
Cần lưu ý rằng trình tự phát triển được khuyến nghị trong quy trình ADM là mang tính lặp (iterative), với phạm vi chiều sâu, chiều rộng và các sản phẩm bàn giao tăng dần theo từng vòng lặp. Mỗi vòng lặp sẽ bổ sung tài nguyên vào Kho lưu trữ Kiến trúc (Architecture Repository) của tổ chức.

Mặc dù việc có một khung hoàn chỉnh là hữu ích (và thực tế là cần thiết) để hướng tới như mục tiêu dài hạn, nhưng trên thực tế cần phải đưa ra một quyết định then chốt về phạm vi của từng nỗ lực Kiến trúc Doanh nghiệp cụ thể.
Do đó, điều quan trọng là phải hiểu rõ cơ sở để đưa ra các quyết định về phạm vi và thiết lập kỳ vọng rõ ràng cho mục tiêu của nỗ lực này.

Nguyên tắc hướng dẫn chính là tập trung vào những gì tạo ra giá trị cho doanh nghiệp, đồng thời lựa chọn phạm vi ngang, phạm vi dọc và khoảng thời gian phù hợp.
Dù đây có phải là lần đầu tiên thực hiện hay không, cần hiểu rằng bài tập này sẽ được lặp lại và các vòng lặp trong tương lai sẽ xây dựng dựa trên những gì được tạo ra trong nỗ lực hiện tại, bổ sung thêm cả chiều rộng và chiều sâu.