Komentarze do TOGAF - metamodel zawartości (cz. I)

Zgodnie ze Słownikiem Języka Polskiego termin “komentarz” oznacza m.in. objaśnienia lub interpretacje tekstu, obrazu, badania naukowego itp., dodawane przez autora lub specjalistę w danej dziedzinie. Wydaje się, że na chwilę obecną brak jest takiego komentarza, dla ram architektonicznych TOGAF. Od kilku lat zajmuję się problematyką wdrażania architektury korporacyjnej. W swojej praktyce bazuję głównie na  TOGAF’ie, ale staram się stosować go  maksymalnie pragmatycznie, a nie dogmatycznie. Oznacza to, że wszędzie tam, gdzie istnieje taka konieczność dopasowuję go do potrzeb i specyfiki Klienta (obejmuje to zarówno terminologię, procesy, role, odpowiedzialności, jaki i produkty oraz metamodel). Jest to zresztą podejście rekomendowane przez twórcę TOGAF’a, czyli The Open Group.

Z drugiej jednak strony, wielu Klientów prosi o interpretację zawartości samej specyfikacji TOGAF, widząc w niej wartość, jako standardu de-facto w zakresie wdrażania architektury korporacyjnej.  Przy okazji zwracają oni uwagę na fakt, iż jest ona napisana mało przyjaznym językiem (niestety muszę się z tym zgodzić).

Dlatego stwierdziłem, że ponieważ nie ma powszechnie dostępnego komentarza do TOGAF’a, warto jest rozpocząć przynajmniej cząstkową pracę w tym zakresie (inspiracją dla mnie były komentarze wydawane do ustaw). Oczywiście będzie to moje autorskie spojrzenie – dlatego będę wdzięczny za Państwa uwagi i komentarze.

Na początek chciałbym odnieść się do jednego z  kluczowych elementów TOGAF’a jakim jest metamodel zawartości (Content Metamodel). Jest on opisany w rozdziale 34 specyfikacji TOGAF. Metamodel ten jest podstawą do definiowania artefaktów architektonicznych (w szczególności określa on, które z tych artefaktów są obowiązkowe, a które opcjonalne).   Metamodel ma postać diagramu klas (bardziej nawet – diagramu dziedziny) – przy czym w formie graficznej składają się na niego jedynie klasy (odzwierciedlające byty występujące następnie na artefaktach architektonicznych) i relacje je łączące (przy czym relacje te mają postać nazwanych asocjacji). W wersji standardowej nie zawiera on:

• liczności asocjacji,
• atrybutów klas.

W jednym z wcześniejszych wpisów zaprezentowałem rozszerzoną wersję metamodelu – zawierającą rekomendowane przez TOGAF atrybuty, które zostały przypisane do poszczególnych klas (atrybuty te zostały zawarte w oddzielnej tabeli, znajdującej się również w rozdziale 34).

W niniejszym wpisie chciałbym przedyskutować szerzej 6 encji tego metamodelu (por. rysunek 1) – tj.:

• Logiczny komponent aplikacji (Logical Application Component) – należący do domeny aplikacji, zgodnie z TOGAF jest to element obowiązkowy.
• Fizyczny komponent aplikacji (Physical Application Component) – należący do domeny aplikacji, zgodnie z TOGAF jest to element nieobowiązkowy, związany z rozszerzeniem konsolidacji infrastruktury (infrastructure consolidation extension).
• Logiczny komponent techniczny (Logical Technology Component) – należący do domeny technicznej, zgodnie z TOGAF jest to element nieobowiązkowy, związany z rozszerzeniem konsolidacji infrastruktury (infrastructure consolidation extension).
• Fizyczny komponent techniczny (Physical Technology Component) – należący do domeny technicznej, zgodnie z TOGAF jest to element obowiązkowy.
• Logiczny komponent danych (Logical Data Component) – należący do domeny danych, zgodnie z TOGAF jest to element nieobowiązkowy, związany z rozszerzeniem danych (data extension).
• Fizyczny komponent danych  (Physical Data Component) – należący do domeny technicznej, zgodnie z TOGAF jest to element nieobowiązkowy, związany z rozszerzeniem danych (data extension).

Uwaga: Na metamodelu zaznaczono encje, które będą podlegać analizie
Rysunek 1. Struktura metamodelu zawartości TOGAF 9.1
Źródło: The Open Group

Poniżej przedstawiam oficjalne definicje The Open Group w/w elementów metamodelu i moje ich interpretacje:
Logiczny komponent techniczny, według TOGAF,  to logiczna reprezentacja infrastruktury technicznej, która jest niezależna od poszczególnych produktów. Jest to klasa produktu technicznego. Fizyczny komponent techniczny zaś to konkretny produkt infrastruktury technicznej lub instancja produktu infrastruktury technicznej.

Przykładem logicznego komponentu technicznego  jest “system operacyjny” (o określonej funkcjonalności), zaś fizycznym komponentem aplikacji jest produkt firmy “X” lub “Y’ – np. IBM AIX.

Jako logiczny komponent techniczny można również potraktować platformę pozwalającą na uruchomienie wewnętrznego intranetu/ekstranetu. Wówczas fizycznym komponentem technicznym byłby np. Sharepoint (lub np. Lotus Notes).

Logiczny komponent aplikacji definiowany jest w TOGAF jako wydzielony zbiór funkcjonalności aplikacji niezależny od sposobu ich implementacji. Natomiast fizyczny komponent aplikacji, zgodnie z TOGAF,  jest to aplikacja, moduł aplikacji, usługa aplikacji lub inny wdrażalny komponent funkcjonalności.

Przykładem logicznego komponentu aplikacji jest “system CRM” (o określonej funkcjonalności), zaś fizycznym komponentem aplikacji jest produkt firmy “X” lub “Y’ – np. Microsoft Dynamics.

Nawiązując do drugiego przykładu  logicznym komponentem aplikacji byłaby np. “aplikacja do rezerwacji sal”, zaś fizycznym komponentem aplikacji – aplikacja webowa napisana w środowisku Sharepoint.

Logiczny komponent danych to, zgodnie z TOGAF, grupa powiązanych encji danych wydzielona w celu utworzenia logicznej lokalizacji ich przechowywania. Natomiast fizyczny komponent danych TOGAF definiuje jako powiązane encje danych przechowywane w fizycznej lokalizacji.

Przykładem logicznego komponentu danych  jest “baza klientów” (zawierająca konkretne encje), zaś fizycznym komponentem danych jest schemat bazy danych klientów w bazie Oracle 11g.

Nawiązując do drugiego przykładu  logicznym komponentem danych byłaby np. “baza danych o salach”, zaś fizycznym komponentem danych – schemat bazy danych w bazie MS SQL Server.

Uwaga: sam motor bazy danych – tj. MS SQL Server, Oracle 11g itp. są traktowane jako fizyczne komponenty techniczne.

Bardzo dużo osób zwraca uwagę na małą intuicyjność formalnych definicji tych elementów metamodelu. Dla części osób używających TOGAF jest to także tworzenie dodatkowych (zbędnych) bytów. O ile mogę zgodzić się, z pierwszą uwagą, o tyle dzięki takiemu rozróżnieniu (byty fizyczne i logiczne) zyskujemy dużą elastyczność opisu organizacji. Proszę zwrócić uwagę, że opis na poziomie komponentów logicznych wraz ze specyfikacją wymagań może być np. doskonałym wsadem do opisu przedmiotu zamówienia.