Best practices a principy modelování

Jak je z kapitoly výše patrné, tvorba modelu nespočívá v kreslení diagramů, nýbrž v budování systému elementů a vazeb, které mají definovaný konkrétní význam podle předepsaných pravidel. Tato pravidla umožňují čtenáři pochopení obsahu vizualizovaných částí modelu, aniž by modelář musel všechny informace vypisovat v textové podobě. Pravidla NAR a této metodiky stanovují nejen význam elementů a vazeb daného typu, ale říkají i, jak lze elementy mezi sebou propojovat, a definují jejich možné využití. Dále ukazují vazby v různých perspektivách. Tím, že model umožňuje použít jeden element či vazbu pro více pohledů, je eliminováno duplikování informací, což bývá zásadní problém pro jeho dlouhodobou udržitelnost a rozvoj.

Modelování dle předem dohodnutých pravidel zajišťuje, že uložené informace v modelu budou pro čtenáře pochopitelné a model bude možné dlouhodobě udržovat a rozvíjet.

Obecně platné principy pro dobrý model jsou popsané níže.

Výše popsané principy lze uplatnit na jednotlivé prvky modelu. Základními prvky modelu jsou elementy, vazby, atributy a pohledy. Dále je detailněji popsáno, které principy jsou na nich uplatněné a jakou jsou uplatněny formou.

Element modelu reprezentuje jednu konkrétní část reality z pohledu její struktury či chování a popisuje její vlastnosti. Je to základní stavební prvek modelu.

Při modelování elementů doporučujeme mít na paměti následující:

Propojuje elementy a říká jakým způsobem spolu dané elementy souvisejí. Pro vazbu jsou zásadní následující aspekty:

Elementy, vazby i strukturní prvky v modelu mohou nést doplňkové informace, které je často vhodné držet ve strukturované podobě. Tyto údaje jsou označené jako atributy. Základními atributy jsou název a popis, k nim se ale přidávají další. Atributy lze roztřídit do skupin dle využití (profilů).

Nejdůležitějšími a nejčastěji použitými atributy elementů i vazeb jsou název, popis a jednoznačný identifikátor.

Název prvku by měl být lidsky čitelný, a proto je důležité zvolit vhodný jazyk. Dále by měl být co nejkratší a výstižný. Tato metodika v souladu s ArchiMate definuje pro jednotlivé typy elementů formu jakou by měl název mít:

• Behaviorální elementy musí být nazývány průběhovým časem (musí být patrná činnost/chování) (na příklad "Poskytování katalogu služeb", "Editování údajů". "Prodej zboží").
• Pasivní elementy jsou nazývány podstatným jménem ("Dokument", "Faktura").
• Aktivní elementy jsou pojmenovány podstatným jménem ("Jan Novák", Oddělení fakturace, Zákon 111/2009 Sb.).

Technický identifikátor slouží pro jednoznačné označení prvku modelu. Obvykle není využíván mimo technický kontext modelovacího nástroje.

Pro účely jednoznačné identifikace prvku v rámci modelování celé státní správy je očekávané zavedení globálního identifikátoru. Globální identifikátor nenahrazuje technický identifikátor, jedná se o další údaj.

Tento identifikátor by byl prvku přiřazován nejspíše po importu modelu úřadu do plánovaného centrálního úložiště.

Atribut bude nutné u daného prvku udržovat i lokálně po opětovném přenosu z centrálního úložiště do místního modelu. Takto budou označené zejména všechny sdílené prvky modelů.

Důležitým obecným profilem je Klasifikace. Klasifikační atributy slouží k jednoznačnému zařazení prvku modelu v kontextu požadované struktury, určení a umístění v centrálním úložišti modelů DIA. Jsou obvykle realizované pomocí Tagů (záleží ale na nástroji).

Klasifikační atributy jsou součástí metainformací o modelu (viz kap. Úrovně detailu).

Pro potřeby sladění očekávání čtenářů a tvůrců modelu a pro tvorbu výstupů z něj je potřeba správně rozhodnout, jak vizualizovat informace v modelu uložené (viz princip Přizpůsobujte výstupy pro konkrétní čtenáře). K tomu pomáhá definice Hledisek popisujících, co daný čtenář očekává, že najde v pohledech na model. Jedno hledisko může být realizované na více pohledech, ale čtenář by měl vždy být schopný najít pro sebe zajímavé informace v plném potřebném kontextu.

V NAR a této metodice pro zjednodušení vždy jednomu hledisku zainteresovaných odpovídá jedna definice pohledu typu Diagram, která pak může mít v jednom modelu více výskytů pohledů, například v různé míře podrobnosti (L0 až L2) nebo se zaměřením na některý konkrétní koncept. Artefakty typu diagram vycházejí ze společných artefaktů typu Katalog.

Katalogy jsou pro každý modelovaný koncept vždy jednotné a unikátní, objektové. Na rozdíl od Diagramů se u Katalogů neuplatní Hlediska.

Hlediska pro očekávané čtenáře definuje NAR: https://archi.gov.cz/nar_dokument:ramec_obsahu_a_vystupu_architektur#hlediska_a_definice_pohledu_narodni_architektury_vs_cr

Pohledy v notaci ArchiMate jsou klíčové pro pochopení různých aspektů podnikové architektury. Každý pohled se zaměřuje na specifickou část architektury a poskytuje různé úhly pohledu na systém. Byznys pohledy se zaměřují na byznys procesy, role, aktéry a produkty. Pomáhají pochopit, jak byznys funguje a jaké jsou jeho hlavní komponenty a vztahy mezi nimi. Aplikační pohledy se zaměřují na aplikační komponenty a jejich interakce. Ukazují, jak aplikace podporují byznys procesy a jak spolu aplikace komunikují. Technologické pohledy se zaměřují na technologickou infrastrukturu, včetně serverů, sítí a dalších technických komponent. Pomáhají pochopit, jak je technologická infrastruktura uspořádána a jak podporuje aplikační a byznys vrstvy. Motivační pohledy se zaměřují na cíle, principy a požadavky, které řídí architekturu. Pomáhají pochopit, proč je architektura navržena určitým způsobem a jaké jsou její hlavní cíle.

Pohledy zobrazují (vizualizují) vybrané části modelu tak, aby naplnily hlediska jeho čtenářů.

Základními typy pohledů jsou:

• Diagram – zobrazuje graficky vybrané elementy, jejich atributy a vazby mezi nimi. Jsou nejobvyklejším druhem pohledu.
• Matice – ukazuje propojenost dvou skupin elementů. Na osách X a Y jsou výčty elementů z vybrané části modelu a na průsečících mezi nimi je indikace existence vazby daného typu a směru. Obvykle jsou použité pro vizualizaci mapování.
• Katalog – je výčet elementů v podobě tabulky. U každého elementu je vypsaná vybraná množina atributů. Katalogový výpis může být uživatelsky filtrovatelný, dle zvolené formy vizualizace.

Využitelné typy pohledů definuje metodika, zároveň určuje jejich roli při tvorbě modelu.

U diagramů je nejdůležitější, aby:

1. Co nejpřesněji vyjadřovaly sdělení (příběh) svého autora, nositele myšlenky;
2. Co nejlépe posloužily potřebě svého čtenáře, úměrně jeho specifickým možnostem vnímání a porozumění.

Dále je třeba věnovat největší pozornost počtu a rozmístění prvků na nich. Správné rozmístění, zarovnání a celková uklizenost diagramu naprosto zásadně zlepšuje schopnost pochopení myšlenek a informací.

Pro diagram jsou zásadní následující aspekty:

Formální

Vizualizace

Matice jsou specifickým vizualizačním prvkem umožňují přehledně ukázat mapování mezi dvěma sadami elementů. Jsou užitečné pro kontrolu a ladění propojenosti, kdy jsou sady elementů ve vztahu m:n. V takovém případě se obtížně tvoří, a hlavně udržuje, podobný diagram.

Matice slouží pro i mapování vazeb mezi objekty napříč vrstvami architektury, což umožňuje čtenáři pochopit provázanost objektů a jejich využívání.

NAR tvorbu a použití matic dosud blíže neupravuje, tato metodika uvádí možné využití matic tam, kde to je efektivní.

Na co myslet při tvorbě matic:

Pozn.: Některé nástroje pro správu modelů matice nepodporují (například Archi).

Katalogy jsou výčty elementů daného typu, zobrazené ve formě tabulky s možností řazení či filtrace a nastavení zobrazených atributů.

Katalogy jsou spolu s maticemi více interaktivní než diagramy a hodí se zejména pro práci přímo v nástroji. Obvykle se katalogem řeší potřeba výčtu elementů s konkrétním řazením a atributy, či pro gap analýzy pomocí filtrace určitých hodnot atributů.

V tištěné dokumentaci je obvykle katalog realizován pomocí šablony pro vygenerování dokumentu pro příslušnou část modelu.

NAR doporučuje používat pro inventarizaci a správu portfolií klíčových konceptů (procesů, rolí, aplikačních a technologických komponent a služeb apod.) katalogy v tabulkovém kalkulátoru nebo ve specializovaných nástrojích, s obsahem podle OHA publikovaných akcelerátorů. Takto připravené tabulkové zdroje je možné hromadně naimportovat do nástroje, čímž se ušetří čas. Pro hromadné úpravy je možné katalog dočasně vyexportovat, upravit vně nástroje a opět naimportovat. Vždy je ale nutné zajistit, že model je primární zdroj katalogů pro potřeby podnikové architektury.

U katalogů jsou zásadní následující aspekty:

Pozn.: Některé nástroje pro správu modelů katalogy nepodporují (například Archi).

Tato metodika modelování platí pro enterprise architekturu celku, domén a segmentů OVS, v mírně omezené míře, respektive aplikovaně, pro enterprise architekturu řešení příležitostí, identifikovaných v doménových nebo segmentových architekturách.

V architektonickém popisu řešení lze pomocí této metodiky odpovídat na existencionální otázky CO? a PROČ? bude obsahovat hledané řešení, nikoli na otázky JAK MÁ FUNGOVAT? Takové modely tzv. solution architektury nejsou upraveny NAR ani touto metodikou, zejména proto, že:

1. Mají jiný účel
2. Jazyk ArchiMate se pro ně málo hodí (spíše UML).

Z hlediska rozsahu modelovaných OVS a jejich korporací, či z hlediska jejich vnitřní struktury dělené na segmenty a schopnosti je tato metodika modelování univerzálně použitelná.

Sem ale patří otázka, kolik má mít jedno OVS modelů. Před každým modelování nějakého katalogu nebo diagramu je nutno rozhodnout do jakého z nich daná informace patří. OVS by mělo být schopno rozlišit a samostatně spravovat modely:

• VLST – Vlastní model architektury úřadu (OVS). Obsahuje prvky a pohledy specifické pro tento kontext. Úřad může obsahovat několik modelů tohoto typu pro své jednotlivé organizace.
• SPOL – Společný model úřadu a všech jím kontrolovaných (a metodicky vedených) organizací (resort, krajská korporace atp.). Zde jsou umístěné pohledy kombinující prvky z několika modelů typu VLST. Mohou zde být i další prvky, spadající jen do kontextu SPOL.
• ROZS – Rozšířený model s prvky od spolupracujících organizací, úřadů, kdekoli v systému veřejné správy (případně soukromé sféry). Zde by měly být pohledy ukazující kontext mimo rámec SPOL, typicky se sdílenými prvky jiných úřadů. DO doby, než bude k dispozici centrální správa sdílených prvků, budou zde uložené jejich kopie, které budou použité pro vazby a pohledy v modelu daného úřadu.

Na obrázku níže je ilustrován princip strukturování modelů těchto typů.

Jednotná struktura modelů významně pomáhá jejich pochopitelnosti a umožňuje zastupitelnost jak na straně čtenářů, tak na straně tvůrců. Dlouhodobě si DIA klade za cíl udržovat modely podnikových architektur úřadů centrálně, což vede také na potřebu jednotného strukturování modelů. Proto v této metodice popisujeme hlavní myšlenky v této oblasti.

Model by měl být strukturován zhruba taktak, jak je vidět na obrázku níže. Struktura počítá s možností hierarchického členění modelu úřadu (prvky „Část úřadu N“). Následuje dělení dle architektonických domén, kde je očekávaná úplná nezávislost obsažených prvků (elementů, vazeb) mezi doménami. Na další úrovni jsou pak elementy sdružené do katalogů a diagramy a matice, na nichž jsou elementy a vazby zobrazené.

Samotné elementy jsou držené buď ve vlastní struktuře, nebo jako součást katalogů – záleží na konkrétním nástroji. To samé platí o uložení vazeb.

Zatímco elementy jsou jasně přiřazené k architektonickým doménám, na pohledech mohou být elementy z více domén současně. Umístění pohledu se pak řídí převažujícím typem elementů, či tím, kam spíše logicky patří. V kapitole 4.64.6 je pak uvedeno zařazení pohledů do jednotlivých architektonických domén.

Nelze zapomenout na pohledy, které jsou striktně průřezové. Pro ně je vhodné vyčlenit uzel struktury „Přehledová hlediska“, který je sdružuje.

Aby byla podpořena myšlenka jednotné granularity informací přes celý model, jsou definované tři úrovně detailnosti modelovaného pohledu na realitu. Tyto úrovně jsou pojmenované L0, L1 a L2 a jsou popsané v tabulce níže.

Detailní informace o konceptu úrovní detailu v NAR najdete na https://archi.gov.cz/nar_dokument:proces_tvorby_architektur?s%5b%5d=l1%2A#rozhodnuti_o_hloubce_obsahu

Vždy musí být možné identifikovat časové období, k němuž se obsah modelu vztahuje. Zejména je důležité být schopný rozlišit, zda modelujeme současný (AsIs) či budoucí (ToBe) stav. Způsob realizace tohoto požadavku je vysoce závislý na způsobu řízení změn v podniku. Tato metodika doporučuje následující přístup:

Pro jednoznačné zařazení dané části modelu pro čtenáře, ale hlavně pro potřeby automatizace zpracování obsahu modelu, vč. např. validace formální správnosti je potřeba jednotlivé prvky modelu doplnit o informace, které toto umožní.

Některé údaje popsané v kapitolách výše jsou elegantně zaznamenány do modelu právě pomocí metainformací.

Metainformace jsou v modelovacích nástrojích obvykle udržované jako specifické atributy, či tagy. Doporučujeme prozkoumat možnosti použitého modelovacího nástroje pro automatizaci a systematizaci jejich vyplňování.

Pro jakoukoli integrovatelnost modelů mezi sebou je nutné metainformace k prvkům modelu udržovat.

Základní metainformace jsou: