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:
Využitelné typy pohledů definuje metodika, zároveň určuje jejich roli při tvorbě modelu.
U diagramů je nejdůležitější, aby:
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í
| Soulad s metamodelem | Na diagramu by měly být pouze elementy, vazby a atributy předepsané metamodelem. Zásadní je nesnažit se na diagram zanést všechny informace najednou – nejspíše porušíte metodická pravidla a diagram půjde velmi obtížně naformátovat, číst i aktualizovat |
| Barvy a legenda | metodika předepisuje barevnost elementů a vazeb. Přesto je silně doporučeno doplnit vždy diagram o legendu, která zdůrazní barevný kód. Povinně vždy, pokud děláme složitější barevné schéma, než je zvyklost ArchiMate (žlutý business, modré aplikace, zelená infrastruktura) |
Vizualizace
| Čitelnost | Diagram by měl být snadno čitelný v podobě, v jaké je zobrazen ve výstupu (obvykle dokument formátu A4, či zobrazení na displeji, zařazení do jednoho slide v PowerPointu). Platí pravidlo, že čtenář by měl být schopen význam a hlavní myšlenky diagramu pochopit do 30 sekund. K tomu pomáhají body níže. |
| Rozměr | Diagram by měl být čitelný celý, pokud bude zobrazen v zamýšleném výstupním formátu a pozorovaný z obvyklé vzdálenosti bez potřeby „zoomování“. |
| Počet elementů | Velmi záleží na druhu diagramu a zamýšleném způsobu prezentace. Doporučeno je pro diagramy jiného než přehledového účelu použít do cca 15 elementů. Přehledové diagramy, u nichž je předpoklad tisku na větší formát, mohou mít počet elementů i násobně větší a stále zachovat pochopitelnost. |
| Uspořádání elementů | Elementy na diagramu rozmisťujeme tak, aby byla patrná myšlenka, příběh a vztahy elementů. Vhodnou topologii (umístění) lze čerpat z referenčních modelů, pokud jsou OHA publikovány. |
| Zvýraznění rozměrem | Centrální prvek diagramu může být rozměrově zvětšen, aby upoutal oko, odtud začne čtenář diagram číst. |
| Zobrazení detailů elementu | Využijte možnosti nástroje zobrazit či naopak nezobrazit vybrané atributy elementu, podle zprávy, kterou chceme předat čtenáři a aby se detaily zbytečně neopakovaly na více diagramech. Např. u elementů navázaných na ústřední element diagramu není třeba uvádět všechny detaily, zajímá nás pouze výčet těchto elementů a jejich detailní zobrazení najdeme na diagramu jim dedikovaným. Eliminuje se tím také riziko, že se pracně odladěný diagram rozbije při přidáním nových atributů k elementu. |
| Zobrazení vazeb | Zvažte, zda na diagramu potřebujeme všechny vazby mezi zobrazenými elementy. Často nás zajímají vazby jen na centrální element, ale ne vazby mezi sekundárními elementy. Případně nás zajímají vazby jen vybraných typů. V takovém případě je vhodné nezajímavé vazby na diagramu schovat. Nástroje obvykle podporují možnost jak samotného vypínání viditelnosti vazeb ad-hoc a tak i plošně vypnout zobrazení dané vazby na jiných diagramech (to se hodí v případě, kdy přidáváme novou vazbu a daná kombinace elementů se objevuje i na jiných diagramech). |
| Zarovnání elementů | Doporučujeme věnovat velkou pozornost optimalizaci rozmístění prvků na diagramu tak, aby byly elementy zarovnané (lze např. použít mřížku v modelovacím nástroji) |
| Zarovnání vazeb | Vazby by měly být ideálně zalamované tak, aby se co nejméně křížily a aby neprocházely přes elementy. U přehledových diagramů lze využít zarovnání vazeb do „sběrnice“ kdy vazby vycházejí z jednoho bodu elementu, vedou přes sebe a odbočují k cílovým elementům. |
Příklad čitelného diagramu
Příklad nečitelného diagramu (diagram obsahuje chaoticky rozmístěné elementy, kontrast písma a pozadí je nevhodný a nedodržuje standard, vazby jsou nepřehledné a velikost písma je pro čtenáře příliš malá)
Příklad uspořádaného diagramu
Příklad neuspořádaného diagramu (elementy nejsou zarovnány, vazby se překrývají a nejsou přehledné, velikost rámečků není jednotná a font, velikost a barva písma je zvolená bezmyšlenkovitě – není obsažena legenda)
Příklad diagramu s uklizenými a vyfiltrovanými vazbami
Příklad diagramu se všemi vazbami, navíc bez zarovnání
Příklad centrického elementu v diagramu
Příklad přehledového diagramu
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:
| Počet elementů na osách | Při velkém počtu elementů může být při tisku na obvyklé formáty papíru mapa příliš jemná a nečitelná. Doporučujeme zvážit rozpad na více matic |
| Aktualizace matice | Při průběžné tvorbě obsahu se výčet elementů na osách matice mění. Proto je vhodné matici aktualizovat, aby ukázala vždy platný seznam elementů. Totéž se týká sledovaných vazeb. |
| Vytvoření vazby v matici vs. v diagramech | Pokud vytváříte vazby přímo přes matici, zkontrolujte, zda se nechtěně neobjeví na diagramech s danou kombinací elementů. |
Pozn.: Některé nástroje pro správu modelů matice nepodporují (například Archi).
Ukázka matice přímo v nástroji Sparx Enterprise Archtect
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:
| Definice typů elementů | Definice typů elementů v jednom katalogu – je vhodné členit katalogy dle typu elementu podle metodiky |
| Řazení elementů | Řazení elementů v katalogu – obvyklé je výchozí řazení abecední dle názvu, přičemž je možné při vizualizaci katalogu volit řazení dle libovolného zobrazeného atributu. |
| Vnitřní strukturování katalogu | Vnitřní strukturování katalogu – s ohledem na očekávané množství položek a použitý způsob vizualizace lze někdy doporučit katalog vnitřně členit, např. dle modulů. Obvyklejší je ale ponechat seznam lineární a veškerou filtraci a řazení ponechat na vizualizačním nástroji pro katalog. |
Pozn.: Některé nástroje pro správu modelů katalogy nepodporují (například Archi).
Ukázka katalogu přímo v nástroji Sparx Enterprise Architect