3 Cấu trúc Ngôn ngữ

Chương này mô tả cấu trúc của ngôn ngữ mô hình hóa Kiến trúc Doanh nghiệp ArchiMate. Định nghĩa chi tiết và các ví dụ về tập hợp các phần tử và mối quan hệ chuẩn của nó sẽ được trình bày trong Chương 4 đến Chương 1

3.1 Các cân nhắc về thiết kế ngôn ngữ

Một thách thức chính trong việc phát triển một mô hình siêu tổng quát cho Kiến trúc Doanh nghiệp là tìm được sự cân bằng giữa tính cụ thể của các ngôn ngữ dành cho từng lĩnh vực kiến trúc riêng lẻ và một tập hợp các khái niệm kiến trúc rất tổng quát, phản ánh quan điểm về hệ thống như một tập hợp đơn thuần các thực thể liên quan lẫn nhau.

Thiết kế của ngôn ngữ ArchiMate bắt đầu từ một tập hợp các khái niệm tương đối tổng quát. Những khái niệm này đã được chuyên biệt hóa để áp dụng ở các tầng kiến trúc khác nhau, như được giải thích trong các phần tiếp theo. Rào cản thiết kế quan trọng nhất đối với ngôn ngữ này là nó đã được thiết kế rõ ràng để nhỏ nhất có thể, nhưng vẫn đủ dùng cho phần lớn các nhiệm vụ mô hình hóa Kiến trúc Doanh nghiệp. Nhiều ngôn ngữ khác cố gắng đáp ứng nhu cầu của tất cả người dùng có thể. Vì lợi ích về sự đơn giản trong học tập và sử dụng, ngôn ngữ ArchiMate đã được giới hạn ở những khái niệm đủ để mô hình hóa 80% các trường hợp thực tế phổ biến.

Tiêu chuẩn này không mô tả chi tiết lý do đằng sau việc thiết kế ngôn ngữ ArchiMate. Người quan tâm được tham khảo [1], [2] và [3], cung cấp mô tả chi tiết về việc xây dựng ngôn ngữ và các cân nhắc thiết kế.

3.2 Cấu trúc cấp cao nhất của ngôn ngữ

Hình 1 nêu rõ cấu trúc phân cấp cấp cao nhất của ngôn ngữ:

• Một mô hình là một tập hợp của các khái niệm – một khái niệm là một trong hai phần tử hoặc một mối quan hệ
• Một phần tử là một phần tử hành vi, phần tử cấu trúc, phần tử động cơ hoặc phần tử tổng hợp

Lưu ý rằng đây là các khái niệm trừu tượng khái niệm; chúng không nhằm mục đích được sử dụng trực tiếp trong các mô hình. Để biểu thị điều này, chúng được thể hiện bằng màu trắng với nhãn in nghiêng. Xem Chương 4 để giải thích về ký hiệu được sử dụng trong Hình 1.

Hình 1: Cấu trúc phân cấp cấp cao nhất của các khái niệm ArchiMate

3.3 Tầng lớp của ngôn ngữ ArchiMate

Ngôn ngữ cốt lõi ArchiMate định nghĩa một cấu trúc gồm các phần tử phổ quát và các mối quan hệ của chúng, có thể được chuyên biệt hóa ở các tầng khác nhau. Ba tầng được xác định trong ngôn ngữ cốt lõi ArchiMate như sau:

1. Cấp Tầng Kinh doanh miêu tả các dịch vụ kinh doanh được cung cấp cho khách hàng, được thực hiện trong tổ chức thông qua các quy trình kinh doanh do các tác nhân kinh doanh thực hiện.
2. Cấp Tầng Ứng dụng miêu tả các dịch vụ ứng dụng hỗ trợ hoạt động kinh doanh, và các ứng dụng thực hiện chúng.
3. Cấp Tầng Công nghệ bao gồm cả công nghệ thông tin và công nghệ vận hành. Bạn có thể mô hình hóa, ví dụ, công nghệ xử lý, lưu trữ và truyền thông để hỗ trợ thế giới ứng dụng và các tầng Kinh doanh, và mô hình hóa công nghệ vận hành hoặc công nghệ vật lý bằng các cơ sở hạ tầng, thiết bị vật lý, vật liệu và mạng phân phối.

Cấu trúc chung của các mô hình trong các tầng khác nhau là tương tự. Các loại phần tử và mối quan hệ giống nhau được sử dụng, mặc dù bản chất và mức độ chi tiết cụ thể khác nhau. Trong chương tiếp theo, cấu trúc của metamodel phổ quát được trình bày. Trong Chương 8, Chương 9 và Chương 10, các phần tử này được chuyên biệt hóa để tạo ra các phần tử cụ thể cho một tầng nhất định.

Phù hợp với định hướng dịch vụ, mối quan hệ quan trọng nhất giữa các tầng được tạo thành bởi mối quan hệ “cung cấp dịch vụ”[1] mối quan hệ, cho thấy cách các phần tử trong một tầng được cung cấp dịch vụ bởi các dịch vụ của các tầng khác. (Lưu ý rằng, tuy nhiên, các dịch vụ không chỉ cung cấp dịch vụ cho các phần tử ở tầng khác, mà còn có thể cung cấp dịch vụ cho các phần tử ở cùng một tầng.) Một loại liên kết thứ hai được tạo thành bởi các mối quan hệ thực hiện: các phần tử ở các tầng thấp hơn có thể thực hiện các phần tử tương đương ở các tầng cao hơn; ví dụ, một

“đối tượng dữ liệu” (Tầng Ứng dụng) có thể thực hiện một “đối tượng kinh doanh” (Tầng Kinh doanh); hoặc một

“thành phần” (Tầng Công nghệ) có thể thực hiện hoặc một “đối tượng dữ liệu” hoặc một “thành phần ứng dụng” (Tầng Ứng dụng).

3.4 Khung cốt lõi ArchiMate

Khung cốt lõi ArchiMate là một khung gồm chín ô dùng để phân loại các phần tử của ngôn ngữ cốt lõi ArchiMate. Nó bao gồm ba khía cạnh và ba tầng, như minh họa trong Hình 2. Đây được gọi là Khung cốt lõi ArchiMate.

Rất quan trọng là phải hiểu rằng việc phân loại các phần tử dựa trên các khía cạnh và tầng chỉ mang tính tổng quát. Các phần tử kiến trúc thực tế không nhất thiết phải bị giới hạn nghiêm ngặt trong một khía cạnh hay tầng nào đó, vì các phần tử kết nối các khía cạnh và tầng khác nhau đóng vai trò trung tâm trong mô tả kiến trúc mạch lạc. Ví dụ, đi trước một chút so với các thảo luận khái niệm sau này, các vai trò kinh doanh đóng vai trò là các phần tử trung gian giữa các phần tử “thuần về hành vi” và các phần tử “thuần về cấu trúc”, và việc một phần mềm nhất định có được coi là một phần của Tầng Ứng dụng hay Tầng Công nghệ có thể phụ thuộc vào ngữ cảnh.

Hình 2: Khung chính của ArchiMate

Cấu trúc của khung cho phép mô hình hóa doanh nghiệp từ các góc nhìn khác nhau, trong đó vị trí trong các ô nhấn mạnh các vấn đề của bên liên quan. Thường thì một bên liên quan có thể có các vấn đề bao quát nhiều ô.

Các chiều của khung như sau:

• Các lớp – ba mức độ mà một doanh nghiệp có thể được mô hình hóa trong ArchiMate – Kinh doanh, Ứng dụng và Công nghệ (như được mô tả trong Phần 3.3)
• Các khía cạnh:

—Khía cạnh cấu trúc chủ động, đại diện cho các yếu tố cấu trúc (các tác nhân kinh doanh, các thành phần ứng dụng và các thiết bị thể hiện hành vi thực tế; tức là các

“chủ thể” của hoạt động)

—Khía cạnh hành vi, đại diện cho hành vi (quy trình, chức năng, sự kiện và dịch vụ) được thực hiện bởi các tác nhân; các yếu tố cấu trúc được gán cho các yếu tố hành vi, để chỉ ra ai hoặc cái gì thể hiện hành vi

—Khía cạnh cấu trúc bị động, đại diện cho các đối tượng mà hành vi được thực hiện lên đó; thường là các đối tượng thông tin trong lớp Kinh doanh và các đối tượng dữ liệu trong lớp Ứng dụng, nhưng cũng có thể được sử dụng để đại diện cho các đối tượng vật lý

Ba khía cạnh này được lấy cảm hứng từ ngôn ngữ tự nhiên, nơi một câu có một chủ ngữ (cấu trúc chủ động), một động từ (hành vi) và một tân ngữ (cấu trúc bị động). Bằng cách sử dụng các cấu trúc tương tự như những gì con người quen thuộc trong ngôn ngữ của chính họ, ngôn ngữ ArchiMate trở nên dễ học và dễ đọc hơn.

Vì ký hiệu ArchiMate là mộtngôn ngữ đồ họangôn ngữ trong đó các yếu tố được tổ chức theo không gian, thứ tự này không có ảnh hưởng gì trong mô hình hóa.

Một yếu tố tổng hợp, như được hiển thị trong Hình 1, là một yếu tố không nhất thiết phải phù hợp với một khía cạnh (cột) duy nhất của khung, mà có thể kết hợp hai hoặc nhiều khía cạnh.

Lưu ý rằng ngôn ngữ ArchiMate không yêu cầu người mô hình hóa phải sử dụng bất kỳ bố cục nào cụ thể như cấu trúc của khung này; nó chỉ đơn thuần là một cách phân loại các yếu tố ngôn ngữ.

3.5 Khung ArchiMate đầy đủ

Khung ArchiMate đầy đủ, như được mô tả trong phiên bản chuẩn này, bổ sung một số lớp và một khía cạnh vào Khung Chính. Các yếu tố vật lý được bao gồm trong Lớp Công nghệ để mô hình hóa các cơ sở vật chất và thiết bị, mạng phân phối và vật liệu. Như vậy, chúng cũng là các yếu tố cốt lõi. Các yếu tố chiến lược được giới thiệu để mô hình hóa định hướng chiến lược và các lựa chọn. Chúng được mô tả trong Chương 7. Khía cạnh động lực được giới thiệu ở cấp độ chung trong chương tiếp theo và được mô tả chi tiết trong Chương 6. Các yếu tố triển khai và di chuyển được mô tả trong Chương 12. Khung ArchiMate đầy đủ kết quả được hiển thị trong Hình 3.

Hình 3: Khung ArchiMate đầy đủ

Ngôn ngữ ArchiMate không định nghĩa một lớp cụ thể cho thông tin; tuy nhiên, các yếu tố từ khía cạnh cấu trúc thụ động như đối tượng kinh doanh, đối tượng dữ liệu và tài sản được sử dụng để biểu diễn các thực thể thông tin. Mô hình hóa thông tin được hỗ trợ trên các lớp ArchiMate khác nhau.

3.6 Trừu tượng trong ngôn ngữ ArchiMate

Cấu trúc của ngôn ngữ ArchiMate dung nạp một số hình thức trừu tượng và tinh chỉnh quen thuộc. Trước hết, sự phân biệt giữa quan điểm bên ngoài (hộp đen, trừu tượng hóa từ nội dung bên trong hộp) và quan điểm bên trong (hộp trắng) là phổ biến trong thiết kế hệ thống. Quan điểm bên ngoài mô tả điều mà hệ thống phải làm cho môi trường của nó, trong khi quan điểm bên trong mô tả cách thức thực hiện điều đó.

Thứ hai, sự phân biệt giữa hành vi và cấu trúc chủ động thường được sử dụng để tách biệt điều mà hệ thống phải làm và cách thức hệ thống thực hiện điều đó khỏi các thành phần của hệ thống (con người, ứng dụng và cơ sở hạ tầng) thực hiện nó. Trong việc mô hình hóa các hệ thống mới, thường hữu ích khi bắt đầu bằng các hành vi mà hệ thống phải thực hiện, trong khi trong việc mô hình hóa các hệ thống hiện có, thường hữu ích khi bắt đầu bằng con người, ứng dụng và cơ sở hạ tầng tạo nên hệ thống, sau đó phân tích chi tiết các hành vi được thực hiện bởi các cấu trúc chủ động này.

Sự phân biệt thứ ba là giữa các mức độ trừu tượng khái niệm, logic và vật lý. Điều này bắt nguồn từ mô hình hóa dữ liệu: các yếu tố khái niệm biểu diễn thông tin mà doanh nghiệp coi là quan trọng; các yếu tố logic cung cấp cấu trúc logic cho thông tin này để hệ thống thông tin có thể thao tác; các yếu tố vật lý mô tả cách lưu trữ thông tin này; ví dụ dưới dạng tệp hoặc bảng cơ sở dữ liệu. Trong ngôn ngữ ArchiMate, điều này tương ứng với các đối tượng kinh doanh, đối tượng dữ liệu và tài sản, cùng với các mối quan hệ thực hiện giữa chúng.

Sự phân biệt giữa các yếu tố logic và vật lý cũng được áp dụng trong mô tả ứng dụng. Mô hình doanh nghiệp TOGAF [4] bao gồm một tập hợp các thực thể mô tả các thành phần và dịch vụ kinh doanh, dữ liệu, ứng dụng và công nghệ để mô tả các khái niệm kiến trúc. Các thành phần logic là các bao bọc độc lập với triển khai hoặc sản phẩm của dữ liệu hoặc chức năng, trong khi các thành phần vật lý là các thành phần phần mềm hữu hình, thiết bị, v.v. Sự phân biệt này được ghi nhận trong khung TOGAF dưới dạng các khối xây dựng kiến trúc (ABBs) và các khối xây dựng giải pháp (SBBs). Sự phân biệt này một lần nữa hữu ích trong việc tiến triển các kiến trúc doanh nghiệp từ các mô tả cấp cao, trừu tượng đến các thiết kế cụ thể, cấp triển khai. Lưu ý rằng các khối xây dựng có thể chứa nhiều yếu tố, thường được mô hình hóa bằng khái niệm nhóm trong ngôn ngữ ArchiMate.

Ngôn ngữ ArchiMate có ba cách để mô hình hóa các dạng trừu tượng này. Thứ nhất, như được mô tả trong [6], các yếu tố hành vi như chức năng ứng dụng và chức năng công nghệ có thể được sử dụng để mô hình hóa các thành phần logic, vì chúng biểu diễn các bao bọc độc lập với triển khai về chức năng. Các thành phần vật lý tương ứng sau đó có thể được mô hình hóa bằng các yếu tố cấu trúc chủ động như thành phần ứng dụng và nút, được gán vào các yếu tố hành vi. Thứ hai, ngôn ngữ ArchiMate hỗ trợ khái niệm thực hiện. Điều này có thể được mô tả tốt nhất bằng cách làm việc từ Lớp Công nghệ trở lên. Lớp Công nghệ định nghĩa các tác phẩm vật lý và phần mềm thực hiện một thành phần ứng dụng. Nó cũng cung cấp bản đồ đến các khái niệm vật lý khác như thiết bị, mạng, v.v. cần thiết để thực hiện một hệ thống thông tin. Mối quan hệ thực hiện cũng được sử dụng để mô hình hóa các dạng trừu tượng hơn của thực hiện, chẳng hạn như mối quan hệ giữa một (cần cầu cụ thể hơn) và một (nguyên tắc tổng quát hơn), trong đó việc đáp ứng yêu cầu ngụ ý tuân thủ nguyên tắc. Thực hiện cũng được cho phép giữa các thành phần ứng dụng và giữa các nút. Như vậy, bạn có thể mô hình hóa một thành phần ứng dụng hoặc công nghệ vật lý thực hiện một thành phần ứng dụng hoặc công nghệ logic, tương ứng. Thứ ba, các thành phần ứng dụng logic và vật lý có thể được định nghĩa là các đặc hóa ở cấp độ mô hình dữ liệu của yếu tố thành phần ứng dụng, như được mô tả trong Chương 14 (xem thêm các ví dụ trong Phần 14.2.2). Điều tương tự cũng đúng với các thành phần công nghệ logic và vật lý của Mô hình Nội dung TOGAF, có thể được định nghĩa là các đặc hóa của yếu tố nút (xem Phần 14.2.3).

Ngôn ngữ ArchiMate một cách có chủ ý không hỗ trợ sự khác biệt giữa kiểu và thể hiện. Ở cấp độ trừu tượng Kiến trúc Doanh nghiệp, thường mô hình hóa kiểu và/hoặc ví dụ thay vì thể hiện. Tương tự, một quy trình kinh doanh trong ngôn ngữ ArchiMate không mô tả một thể hiện cá nhân (tức là một lần thực hiện quy trình đó). Trong phần lớn các trường hợp, một đối tượng kinh doanh được sử dụng để mô hình hóa một kiểu đối tượng (xemmột lớp UML®), trong đó có thể tồn tại nhiều thể hiện trong tổ chức. Ví dụ, mỗi lần thực hiện quy trình ứng dụng bảo hiểm có thể dẫn đến một thể hiện cụ thể của đối tượng kinh doanh chính sách bảo hiểm, nhưng điều này không được mô hình hóa trong Kiến trúc Doanh nghiệp.

3.7 Khái niệm và ký hiệu của chúng

Ngôn ngữ ArchiMate tách biệt các khái niệm ngôn ngữ (tức là các thành phần của mô hình dữ liệu) khỏi ký hiệu của chúng. Các nhóm bên liên quan khác nhau có thể yêu cầu các ký hiệu khác nhau để hiểu được mô hình hoặc quan điểm kiến trúc. Về mặt này, ngôn ngữ ArchiMate khác với các ngôn ngữ như UML hoặc BPMN™, vốn chỉ có một ký hiệu chuẩn hóa duy nhất. Cơ chế quan điểm được giải thích trong Chương 13 cung cấp phương tiện để xác định các hình ảnh hóa hướng đến bên liên quan.

Mặc dù ký hiệu của các khái niệm ArchiMate có thể (và nên) là đặc thù theo bên liên quan, chuẩn cung cấp một ký hiệu đồ họa chung duy nhất có thể được các kiến trúc sư và những người khác phát triển mô hình ArchiMate sử dụng. Ký hiệu này nhắm đến đối tượng quen thuộc với các kỹ thuật mô hình hóa kỹ thuật hiện có như sơ đồ quan hệ thực thể (ERD), UML hoặc BPMN, do đó có sự tương tự với chúng. Trong phần còn lại của tài liệu này, trừ khi có ghi chú khác, các ký hiệu dùng để biểu diễn các khái niệm ngôn ngữ đại diện cho ký hiệu chuẩn ArchiMate. Ký hiệu chuẩn cho phần lớn các yếu tố bao gồm một hình chữ nhật có biểu tượng ở góc trên bên phải. Trong một số trường hợp, biểu tượng này riêng lẻ cũng có thể được sử dụng như một ký hiệu thay thế. Nên ưu tiên sử dụng hệ thống biểu tượng chuẩn này mỗi khi có thể, để bất kỳ ai biết ngôn ngữ ArchiMate đều có thể đọc được các sơ đồ được tạo ra bằng ngôn ngữ này.

3.8 Sử dụng nhúng

Việc nhúng các yếu tố bên trong các yếu tố khác có thể được sử dụng như một ký hiệu đồ họa thay thế để biểu diễn một số mối quan hệ. Điều này được giải thích chi tiết hơn trong Chương 5 và trong định nghĩa của từng mối quan hệ này.

3.9 Sử dụng màu sắc và các dấu hiệu ký hiệu

Trong các hình ảnh metamodel trong tiêu chuẩn này, các tông xám được sử dụng để phân biệt các phần tử thuộc các khía cạnh khác nhau của khung ArchiMate, như sau:

• Màu trắng cho các khái niệm trừu tượng (tức là không thể tạo thể hiện)
• Xám nhạt cho các cấu trúc bị động
• Xám trung bình cho hành vi
• Xám đậm cho các cấu trúc chủ động

Trong các mô hình ArchiMate, không có ngữ nghĩa chính thức nào được gán cho màu sắc và việc sử dụng màu sắc được để lại cho người mô hình hóa. Tuy nhiên, chúng có thể được sử dụng tự do để nhấn mạnh một số khía cạnh trong mô hình. Ví dụ, trong nhiều mô hình ví dụ được trình bày trong tiêu chuẩn này, màu sắc được sử dụng để phân biệt giữa các lớp của Khung ArchiMate Core, như sau:

• Màu vàng cho lớp Kinh doanh
• Màu xanh cho lớp Ứng dụng
• Màu xanh lá cho lớp Công nghệ

Chúng cũng có thể được sử dụng để nhấn mạnh về mặt thị giác. Một tài liệu được khuyến nghị cung cấp hướng dẫn là Chương 6 của [1]. Ngoài màu sắc, các dấu hiệu ký hiệu khác cũng có thể được sử dụng để phân biệt giữa các lớp của khung. Một chữ cái M, S, B, A, T, P hoặc I ở góc trên bên trái của một phần tử có thể được dùng để chỉ một phần tử Motivation, Strategy, Business, Application, Technology, Physical hoặc Implementation & Migration, tương ứng. Một ví dụ về ký hiệu này được minh họa trong Ví dụ 34.

Ký hiệu chuẩn cũng sử dụng một quy ước về hình dạng các góc của các ký hiệu để phân biệt các loại phần tử khác nhau, như sau:

• Các góc vuông được dùng để chỉ các phần tử cấu trúc
• Các góc tròn được dùng để chỉ các phần tử hành vi
• Các góc chéo được dùng để chỉ các phần tử động cơ

[1]Lưu ý rằng trong các phiên bản trước của tiêu chuẩn, điều này được gọi là “được sử dụng bởi”. Vì lý do rõ ràng, tên này đã được thay đổi thành “phục vụ”.

3 Language Structure

This chapter describes the structure of the ArchiMate Enterprise Architecture modeling language. The detailed definition and examples of its standard set of elements and relationships follow in Chapter 4 to Chapter 1

3.1 Language Design Considerations

A key challenge in the development of a general metamodel for Enterprise Architecture is to strike a balance between the specificity of languages for individual architecture domains and a very general set of architecture concepts, which reflects a view of systems as a mere set of inter-related entities.

The design of the ArchiMate language started from a set of relatively generic concepts. These have been specialized towards application at different architectural layers, as explained in the following sections. The most important design restriction on the language is that it has been explicitly designed to be as small as possible, but still usable for most Enterprise Architecture modeling tasks. Many other languages try to accommodate the needs of all possible users. In the interest of simplicity of learning and use, the ArchiMate language has been limited to the concepts that suffice for modeling the proverbial 80% of practical cases.

This standard does not describe the detailed rationale behind the design of the ArchiMate language. The interested reader is referred to [1], [2], and [3], which provide a detailed description of the language construction and design considerations.

3.2 Top-Level Language Structure

Figure 1 outlines the top-level hierarchical structure of the language:

• A model is a collection of concepts – a concept is either an element or a relationship
• An element is either a behavior element, a structure element, a motivation element, or a composite element

Note that these are abstract concepts; they are not intended to be used directly in models. To signify this, they are depicted in white with labels in italics. See Chapter 4 for an explanation of the notation used in Figure 1.

Figure 1: Top-Level Hierarchy of ArchiMate Concepts

3.3 Layering of the ArchiMate Language

The ArchiMate core language defines a structure of generic elements and their relationships, which can be specialized in different layers. Three layers are defined within the ArchiMate core language as follows:

1. The Business Layer depicts business services offered to customers, which are realized in the organization by business processes performed by business actors.
2. The Application Layer depicts application services that support the business, and the applications that realize them.
3. The Technology Layer comprises both information and operational technology. You can model, for example, processing, storage, and communication technology in support of the application world and Business Layers, and model operational or physical technology with facilities, physical equipment, materials, and distribution networks.

The general structure of models within the different layers is similar. The same types of elements and relationships are used, although their exact nature and granularity differ. In the next chapter, the structure of the generic metamodel is presented. In Chapter 8, Chapter 9, and Chapter 10 these elements are specialized to obtain elements specific to a particular layer.

In alignment with service-orientation, the most important relationship between layers is formed by “serving”[1] relationships, which show how the elements in one layer are served by the services of other layers. (Note, however, that services need not only serve elements in another layer, but also can serve elements in the same layer.) A second type of link is formed by realization relationships: elements in lower layers may realize comparable elements in higher layers; e.g., a

“data object” (Application Layer) may realize a “business object” (Business Layer); or an

“artifact” (Technology Layer) may realize either a “data object” or an “application component” (Application Layer).

3.4 The ArchiMate Core Framework

The ArchiMate Core Framework is a framework of nine cells used to classify elements of the ArchiMate core language. It is made up of three aspects and three layers, as illustrated in Figure 2. This is known as the ArchiMate Core Framework.

It is important to understand that the classification of elements based on aspects and layers is only a global one. Real-life architecture elements need not strictly be confined to one aspect or layer because elements that link the different aspects and layers, play a central role in a coherent architectural description. For example, running somewhat ahead of the later conceptual discussions, business roles serve as intermediary elements between “purely behavioral” elements and “purely structural” elements, and it may depend on the context whether a certain piece of software is considered to be part of the Application Layer or the Technology Layer.

Figure 2: ArchiMate Core Framework

The structure of the framework allows for modeling of the enterprise from different viewpoints, where the position within the cells highlights the concerns of the stakeholder. A stakeholder typically can have concerns that cover multiple cells.

The dimensions of the framework are as follows:

• Layers – the three levels at which an enterprise can be modeled in ArchiMate – Business, Application, and Technology (as described in Section 3.3)
• Aspects:

— The Active Structure Aspect, which represents the structural elements (the business actors, application components, and devices that display actual behavior; i.e., the

“subjects” of activity)

— The Behavior Aspect, which represents the behavior (processes, functions, events, and services) performed by the actors; structural elements are assigned to behavioral elements, to show who or what displays the behavior

— The Passive Structure Aspect, which represents the objects on which behavior is performed; these are usually information objects in the Business Layer and data objects in the Application Layer, but they may also be used to represent physical objects

These three aspects were inspired by natural language where a sentence has a subject (active structure), a verb (behavior), and an object (passive structure). By using the same constructs that people are used to in their own languages, the ArchiMate language is easier to learn and read.

Since ArchiMate notation is a graphical language where elements are organized spatially, this order is of no consequence in modeling.

A composite element, as shown in Figure 1, is an element that does not necessarily fit in a single aspect (column) of the framework but may combine two or more aspects.

Note that the ArchiMate language does not require the modeler to use any particular layout such as the structure of this framework; it is merely a categorization of the language elements.

3.5 The ArchiMate Full Framework

The ArchiMate Full Framework, as described in this version of the standard, adds a number of layers and an aspect to the Core Framework_._ The physical elements are included in the Technology Layer for modeling physical facilities and equipment, distribution networks, and materials. As such, these are also core elements. The strategy elements are introduced to model strategic direction and choices. They are described in Chapter 7. The motivation aspect is introduced at a generic level in the next chapter and described in detail in Chapter 6. The implementation and migration elements are described in Chapter 12. The resulting ArchiMate Full Framework is shown in Figure 3.

Figure 3: ArchiMate Full Framework

The ArchiMate language does not define a specific layer for information; however, elements from the passive structure aspect such as business objects, data objects, and artifacts are used to represent information entities. Information modeling is supported across the different ArchiMate layers.

3.6 Abstraction in the ArchiMate Language

The structure of the ArchiMate language accommodates several familiar forms of abstraction and refinement. First of all, the distinction between an external (black-box, abstracting from the contents of the box) and internal (white-box) view is common in systems design. The external view depicts what the system has to do for its environment, while the internal view depicts how it does this.

Second, the distinction between behavior and active structure is commonly used to separate what the system must do and how the system does it from the system constituents (people, applications, and infrastructure) that do it. In modeling new systems, it is often useful to start with the behaviors that the system must perform, while in modeling existing systems, it is often useful to start with the people, applications, and infrastructure that comprise the system, and then analyze in detail the behaviors performed by these active structures.

A third distinction is between conceptual, logical, and physical abstraction levels. This has its roots in data modeling: conceptual elements represent the information the business finds relevant; logical elements provide logical structure to this information for manipulation by information systems; physical elements describe the storage of this information; for example, in the form of files or database tables. In the ArchiMate language, this corresponds with business objects, data objects, and artifacts, along with the realization relationships between them.

The distinction between logical and physical elements has also been carried over to the description of applications. The TOGAF Enterprise Metamodel [4] includes a set of entities that describe business, data, application, and technology components and services to describe architecture concepts. Logical components are implementation or product-independent encapsulations of data or functionality, whereas physical components are tangible software components, devices, etc. This distinction is captured in the TOGAF framework in the form of Architecture Building Blocks (ABBs) and Solution Building Blocks (SBBs). This distinction is again useful in progressing Enterprise Architectures from high-level, abstract descriptions to tangible, implementation-level designs. Note that building blocks may contain multiple elements, which are typically modeled using the grouping concept in the ArchiMate language.

The ArchiMate language has three ways of modeling such abstractions. First, as described in [6], behavior elements such as application and technology functions can be used to model logical components, since they represent implementation-independent encapsulations of functionality. The corresponding physical components can then be modeled using active structure elements such as application components and nodes, assigned to the behavior elements. Second, the ArchiMate language supports the concept of realization. This can best be described by working with the Technology Layer upwards. The Technology Layer defines the physical artifacts and software that realize an application component. It also provides a mapping to other physical concepts such as devices, networks, etc. needed for the realization of an information system. The realization relationship is also used to model more abstract kinds of realization, such as that between a (more specific) requirement and a (more generic) principle, where fulfillment of the requirement implies adherence to the principle. Realization is also allowed between application components and between nodes. This way you can model a physical application or technology component realizing a logical application or technology component, respectively. Third, logical and physical application components can be defined as metamodel-level specializations of the application component element, as described in Chapter 14 (see also the examples in Section 14.2.2). The same holds for the logical and physical technology components of the TOGAF Content Metamodel, which can be defined as specializations of the node element (see Section 14.2.3).

The ArchiMate language intentionally does not support a difference between types and instances. At the Enterprise Architecture abstraction level, it is more common to model types and/or exemplars rather than instances. Similarly, a business process in the ArchiMate language does not describe an individual instance (i.e., one execution of that process). In most cases, a business object is therefore used to model an object type (cf. a UML® class), of which several instances may exist within the organization. For instance, each execution of an insurance application process may result in a specific instance of the insurance policy business object, but that is not modeled in the Enterprise Architecture.

3.7 Concepts and their Notation

The ArchiMate language separates the language concepts (i.e., the constituents of the metamodel) from their notation. Different stakeholder groups may require different notations in order to understand an architecture model or view. In this respect, the ArchiMate language differs from languages such as UML or BPMN™, which have only one standardized notation. The viewpoint mechanism explained in Chapter 13 provides the means for defining such stakeholder-oriented visualizations.

Although the notation of the ArchiMate concepts can (and should) be stakeholder-specific, the standard provides one common graphical notation which can be used by architects and others who develop ArchiMate models. This notation is targeted towards an audience used to existing technical modeling techniques such as Entity Relationship Diagrams (ERDs), UML, or BPMN, and therefore resembles them. In the remainder of this document, unless otherwise noted, the symbols used to depict the language concepts represent the ArchiMate standard notation. This standard notation for most elements consists of a box with an icon in the upper-right corner. In several cases, this icon by itself may also be used as an alternative notation. This standard iconography should be preferred whenever possible so that anyone knowing the ArchiMate language can read the diagrams produced in the language.

3.8 Use of Nesting

Nesting elements inside other elements can be used as an alternative graphical notation to express some relationships. This is explained in more detail in Chapter 5 and in the definition of each of these relationships.

3.9 Use of Colors and Notational Cues

In the metamodel pictures within this standard, shades of grey are used to distinguish elements belonging to the different aspects of the ArchiMate framework, as follows:

• White for abstract (i.e., non-instantiable) concepts
• Light grey for passive structures
• Medium grey for behavior
• Dark grey for active structures

In ArchiMate models, there are no formal semantics assigned to colors and the use of color is left to the modeler. However, they can be used freely to stress certain aspects in models. For instance, in many of the example models presented in this standard, colors are used to distinguish between the layers of the ArchiMate Core Framework, as follows:

• Yellow for the Business Layer
• Blue for the Application Layer
• Green for the Technology Layer

They can also be used for visual emphasis. A recommended text providing guidelines is Chapter 6 of [1]. In addition to the colors, other notational cues can be used to distinguish between the layers of the framework. A letter M, S, B, A, T, P, or I in the top-left corner of an element can be used to denote a Motivation, Strategy, Business, Application, Technology, Physical, or Implementation & Migration element, respectively. An example of this notation is depicted in Example 34.

The standard notation also uses a convention with the shape of the corners of its symbols for different element types, as follows:

• Square corners are used to denote structure elements
• Round corners are used to denote behavior elements
• Diagonal corners are used to denote motivation elements

[1] Note that this was called “used by” in previous versions of the standard. For the sake of clarity, this name has been changed to “serving”.