Poziomy szczegółowości metamodelu zawartości TOGAF

W TOGAF 9 po raz pierwszy oficjalnie wprowadzono metamodel zawartości (Content Metamodel). We wcześniejszych wersjach TOGAF przygotowywano go zazwyczaj w ramach kastomizacji ram architektonicznych. Odbywało się to w fazie wstępnej cyklu TOGAF ADM i była to tzw. praca konsultancka, a nie oficjalne podejście, zatwierdzone przez  The Open Group.

Gdyby chcieć określić jaki jest cel stworzenia metamodelu zawartości – to w syntetyczny sposób można byłoby go przedstawić jako: precyzyjny sposób definiowania kluczowych pojęć występujących na modelach architektonicznych i relacji między nimi. Metamodel ten obejmuje wszystkie cztery domeny architektoniczne (biznesową, danych, aplikacji i techniczną). Dzięki niemu można precyzyjnie wskazać, co to znaczy np. że organizacja będzie miała opisaną architekturę biznesową (jakie informacje muszą znaleźć się w modelach opisujących tą domenę architektoniczną), lub jakie są związki pomiędzy architekturą aplikacji a architekturą techniczną itd.

Wbrew pozorom, mimo zniechęcającej nazwy (wiejącej tzw. „akademickością”), metamodel zawartości największą korzyść przynosi zamawiającemu architekturę korporacyjną (jeżeli zleci on ją do wykonania firmie trzeciej). Metamodel zawartości można bowiem uznać za formalną specyfikację wymagań na produkty architektoniczne – na jego podstawie będzie można w prosty sposób zweryfikować kompletność i spójność dostarczonych modeli (przy czym kompletność w kontekście metamodelu, a nie opisu problemu).

Metamodel zawartości ma postać diagramu klas sporządzonego w notacji UML– poszczególne klasy oznaczają byty występujące na modelach architektonicznych, asocjacje pomiędzy nimi odzwierciedlają związki występujące pomiędzy tymi bytami. Przy czym związki te występują zarówno pomiędzy bytami z tej samej domeny architektonicznej (np. w ramach architektury danych: encja danych i komponent logiczny danych) jak i pomiędzy różnymi domenami architektonicznymi (np. usługa biznesowa z domeny architektury biznesowej z usługą systemu informatycznego z domeny architektury aplikacji).

Dodatkowo każda z klas metamodelu oznaczona jest odpowiednim kolorem, który wskazuje, czy byty odpowiadające danej klasie muszą być zidentyfikowane podczas tworzenia modeli architektonicznych (wówczas klasa ta oznaczona jest na metamodelu białym kolorem), czy mogą być zidentyfikowane (wówczas klasa jest oznaczono kolorem różnym od białego). Jest to praktyczna realizacja tzw. mechanizmu rozszerzeń – wprowadzonego w TOGAF 9. Określa on pewien minimalny zbiór informacji, który każdorazowo trzeba zebrać, aby opisać architekturę korporacyjną. Informacje wykraczające poza ten zbiór są zbierane, jeżeli wystąpi taka potrzeba (np. informacje o lokalizacji siedzib organizacji są opcjonalne i zbierane tylko wówczas, gdy architektura korporacyjna jest wykorzystywana podczas konsolidacji IT).

W specyfikacji TOGAF występuje kilka poziomów szczegółowości opisu metamodelu zawartości. Każdy z nich ma różny stopień skomplikowania i różny cel.

Pierwszy z nich obejmuje same klasy (bez relacji) przypisane do poszczególnych domen architektonicznych. Charakteryzuje się on niskim stopniem skomplikowania, jest prosty do wytłumaczenia odbiorcom nie mającym doświadczenia z architekturą korporacyjną.

Rysunek 1. Ogólna struktura metamodelu zwartości
Uwaga: Proszę kliknąć, aby powiększyć.
Źródło: The Open Group

Drugi poziom szczegółowości – to klasy z relacjami (relacje są nazwane, ale bez określenia ich liczności). Tutaj trzeba poświęcić dłuższą chwilę, aby odkryć wszystkie niuanse i zrozumieć konsekwencje występowania określonych relacji (zwłaszcza jaką pracę one generują podczas tworzenia i aktualizacji modeli).

Rysunek 2. Struktura metamodelu zwartości z relacjami
Uwaga: Proszę kliknąć, aby powiększyć.
Źródło: The Open Group

Trzeci poziom szczegółowości, który nie występuje w sposób jawny, obejmuje klasy z relacjami i dodatkowo z referencyjnymi atrybutami. Takiego diagramu nie ma explicite zawartego w specyfikacji TOGAF. Przygotowałem go na bazie informacji „zaszytych” w opis poszczególnych klas metamodelu. To, co należy podkreślić, to atrybuty te mają charakter przykładowy i należy dostosować je do potrzeb tworzenia konkretnej architektury korporacyjnej. Ten poziom wykorzystywany jest na wewnętrzne potrzeby prac zespołu architektonicznego i ew. zlecania części zadań na zewnątrz (oraz późniejszego ich odbioru).

Rysunek 3. Struktura metamodelu zwartości z relacjami i atrybutami 
Uwaga: Proszę kliknąć, aby powiększyć.
Źródło: Opracowanie własne na podstawie materiałów The Open Group

Wprowadzenie referencyjnych atrybutów do metamodelu zawartości jest jego wyróżnikiem – chociażby w kontekście metamodelu dla języka ArchiMate. Przy opracowywaniu wersji 2.0 tego standardu rozważano taką możliwość, ale ostatecznie nie zdecydowano się na nią.