Rozdíly
Zde můžete vidět rozdíly mezi vybranou verzí a aktuální verzí dané stránky.
| Obě strany předchozí revize Předchozí verze | |||
| playgroud:metodika_ey:metodika [2025/03/07 14:56] – Jaromír Kuželka | playgroud:metodika_ey:metodika [2025/03/26 11:51] (aktuální) – Jaromír Kuželka | ||
|---|---|---|---|
| Řádek 1: | Řádek 1: | ||
| - | ====== Metodika modelování architektury pro potřeby DIA ====== | ||
| - | |||
| - | (pandoc prompt: pandoc -s -f docx -t dokuwiki metodika.docx -o metodika.txt) | ||
| - | |||
| - | |||
| - | EY, 2024-2025 | ||
| - | |||
| - | Verze 0.8 | ||
| - | |||
| - | ====== Obsah ====== | ||
| - | |||
| - | [[# | ||
| - | |||
| - | [[# | ||
| - | |||
| - | [[# | ||
| - | |||
| - | [[# | ||
| - | |||
| - | [[# | ||
| - | |||
| - | [[# | ||
| - | |||
| - | [[# | ||
| - | |||
| - | [[# | ||
| - | |||
| - | [[# | ||
| - | |||
| - | [[# | ||
| - | |||
| - | [[# | ||
| - | |||
| - | [[# | ||
| - | |||
| - | [[# | ||
| - | |||
| - | [[# | ||
| - | |||
| - | [[# | ||
| - | |||
| - | [[# | ||
| - | |||
| - | [[# | ||
| - | |||
| - | [[# | ||
| - | |||
| - | [[# | ||
| - | |||
| - | [[# | ||
| - | |||
| - | [[# | ||
| - | |||
| - | [[# | ||
| - | |||
| - | [[# | ||
| - | |||
| - | [[# | ||
| - | |||
| - | [[# | ||
| - | |||
| - | [[# | ||
| - | |||
| - | [[# | ||
| - | |||
| - | [[# | ||
| - | |||
| - | [[# | ||
| - | |||
| - | [[# | ||
| - | |||
| - | [[# | ||
| - | |||
| - | [[# | ||
| - | |||
| - | [[# | ||
| - | |||
| - | [[# | ||
| - | |||
| - | [[# | ||
| - | |||
| - | [[# | ||
| - | |||
| - | [[# | ||
| - | |||
| - | [[# | ||
| - | |||
| - | [[# | ||
| - | |||
| - | [[# | ||
| - | |||
| - | [[# | ||
| - | |||
| ====== Účel a popis dokumentu ====== | ====== Účel a popis dokumentu ====== | ||
| Řádek 109: | Řádek 16: | ||
| Model reality se vytváří proto, že rozhodování a komunikace nad modelem a prostřednictvím modelu jako zjednodušeného popisu reality je snazší než totéž přímo v realitě. Účelem modelu je, že má být komunikován, | Model reality se vytváří proto, že rozhodování a komunikace nad modelem a prostřednictvím modelu jako zjednodušeného popisu reality je snazší než totéž přímo v realitě. Účelem modelu je, že má být komunikován, | ||
| - | |||
| - | ====== 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, | ||
| - | |||
| - | ===== Tvorba modelu obecně | ||
| - | |||
| - | Obecně platné principy pro dobrý model jsou popsané níže. | ||
| - | |||
| - | ^Princip | ||
| - | |Buďte poctiví | ||
| - | |Buďte věrní | ||
| - | |Buďte výstižní | ||
| - | |Dávejte popis ke každému prvku |Ke každému prvku (strukturní prvky, element, vazba, pohled) vedle jeho názvu navíc doplňte vyčerpávající slovní popis (do příslušného pole – např. Note, Documentation apod.). Pomůže to čtenáři pochopit vaše myšlenky a dále zamezí možnosti nesprávného pochopení. Zejména u diagramů je vhodné čtenáři poskytnout popis jako průvodce zobrazenými elementy a vazbami, aby byly zřejmé prezentované myšlenky. Popisy také zvyšují hustotu informací ve výstupu z modelu a čtenáři pomáhají lépe pochopit kontext. | ||
| - | |Čleňte model dle úrovní detailu | ||
| - | |Buďte konzistentní a dodržujte standardy napříč modelem | ||
| - | |Používejte správné prvky | ||
| - | |Zaveďte a dodržujte jmenné konvence a identifikátory prvků modelu | ||
| - | |Modelování není programování | ||
| - | |Počítejte s budoucím rozšířením modelu | ||
| - | |Přizpůsobujte výstupy pro konkrétní čtenáře | ||
| - | |Ambici pro verzování modelu nastavte na začátku | ||
| - | |Automatizujte tvorbu výstupů | ||
| - | |Zajistěte si podporu od organizace | ||
| - | |||
| - | 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. | ||
| - | |||
| - | ===== Elementy ===== | ||
| - | |||
| - | 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í: | ||
| - | |||
| - | ^Zvolit správný typ elementu | ||
| - | |**Název** | ||
| - | |**Jednoznačný identifikátor**|Zapadající do pravidel pro daný kontext (stereotyp, arch. doména, modul) | ||
| - | |**Dostatečný popis** | ||
| - | |**Relevantní pohledy** | ||
| - | |**Zanořování elementů** | ||
| - | |||
| - | ===== Vazby ===== | ||
| - | |||
| - | Propojuje elementy a říká jakým způsobem spolu dané elementy souvisejí. | ||
| - | |||
| - | Pro vazbu jsou zásadní následující aspekty: | ||
| - | |||
| - | ^Typ ^Musí být v souladu s metamodele příslušné arch. domény a úrovní detailu) | ||
| - | |**Název** | ||
| - | |**Popis vazby** | ||
| - | |**Směrovost vazby** | ||
| - | |**Vlastnosti koncových bodů vazby**|V případě datového modelování je velmi přínosné doplnit k danému koncovému bodu vazby. | ||
| - | |||
| - | ===== Atributy a doplňkové informace ===== | ||
| - | |||
| - | 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ů). | ||
| - | |||
| - | ==== Základní atributy a jmenná konvence ==== | ||
| - | |||
| - | 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 === | ||
| - | |||
| - | 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/ | ||
| - | * Pasivní elementy jsou nazývány podstatným jménem (" | ||
| - | * Aktivní elementy jsou pojmenovány podstatným jménem ("Jan Novák", | ||
| - | |||
| - | === Technický identifikátor === | ||
| - | |||
| - | Technický identifikátor slouží pro jednoznačné označení prvku modelu. Obvykle není využíván mimo technický kontext modelovacího nástroje. | ||
| - | |||
| - | === Globální identifikátor === | ||
| - | |||
| - | Pro účely jednoznačné identifikace prvku v rámci modelování celé státní správy je očekávané zavedení // | ||
| - | |||
| - | 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ů. | ||
| - | |||
| - | ==== Klasifikační atributy ==== | ||
| - | |||
| - | 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. 3.6.3). | ||
| - | |||
| - | Klasifikační atributy přes všechny prvky modelů jsou uvedené v externím dokumentu [[https:// | ||
| - | |||
| - | ===== Hlediska a pohledy ===== | ||
| - | |||
| - | ==== Hlediska ==== | ||
| - | |||
| - | 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, | ||
| - | |||
| - | 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:// | ||
| - | |||
| - | ==== Druhy pohledů ==== | ||
| - | |||
| - | 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, | ||
| - | |||
| - | 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ý, | ||
| - | |||
| - | Využitelné typy pohledů definuje metodika, zároveň určuje jejich roli při tvorbě modelu. | ||
| - | |||
| - | === Diagramy === | ||
| - | |||
| - | U diagramů je nejdůležitější, | ||
| - | |||
| - | - Co nejpřesněji vyjadřovaly sdělení (příběh) svého autora, nositele myšlenky; | ||
| - | - 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í, | ||
| - | |||
| - | Pro diagram jsou zásadní následující aspekty: | ||
| - | |||
| - | **Formální** | ||
| - | |||
| - | ^Soulad s metamodelem | ||
| - | |Barvy a legenda | ||
| - | |||
| - | **Vizualizace** | ||
| - | |||
| - | ^Čitelnost | ||
| - | |Rozměr | ||
| - | |Počet elementů | ||
| - | |Uspořádání elementů | ||
| - | |Zvýraznění rozměrem | ||
| - | |Zobrazení detailů elementu | ||
| - | |Zobrazení vazeb | ||
| - | |Zarovnání elementů | ||
| - | |Zarovnání vazeb | ||
| - | |||
| - | {{media/ | ||
| - | |||
| - | Příklad čitelného diagramu | ||
| - | {{ : | ||
| - | {{media/ | ||
| - | |||
| - | 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á) | ||
| - | |||
| - | {{media/ | ||
| - | |||
| - | Příklad uspořádaného diagramu | ||
| - | |||
| - | {{media/ | ||
| - | |||
| - | Příklad neuspořádaného diagramu (elementy nejsou zarovnány, vazby se překrývají a nejsou přehledné, | ||
| - | |||
| - | {{media/ | ||
| - | |||
| - | Příklad diagramu s uklizenými a vyfiltrovanými vazbami | ||
| - | |||
| - | {{media/ | ||
| - | |||
| - | Příklad diagramu se všemi vazbami, navíc bez zarovnání | ||
| - | |||
| - | {{media/ | ||
| - | |||
| - | Příklad centrického elementu v diagramu | ||
| - | |||
| - | {{media/ | ||
| - | |||
| - | Příklad přehledového diagramu | ||
| - | |||
| - | === Matice === | ||
| - | |||
| - | 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, | ||
| - | |||
| - | 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 | ||
| - | |Aktualizace matice | ||
| - | |Vytvoření vazby v matici vs. v diagramech | ||
| - | |||
| - | //Pozn.:// //Některé nástroje pro správu modelů matice nepodporují (například Archi).// | ||
| - | |||
| - | {{media/ | ||
| - | |||
| - | Ukázka matice přímo v nástroji Sparx Enterprise Archtect | ||
| - | |||
| - | === Katalogy === | ||
| - | |||
| - | 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, | ||
| - | |||
| - | U katalogů jsou zásadní následující aspekty: | ||
| - | |||
| - | ^Definice typů elementů | ||
| - | |**Řazení elementů** | ||
| - | |**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).// | ||
| - | |||
| - | {{media/ | ||
| - | |||
| - | Ukázka katalogu přímo v nástroji Sparx Enterprise Archtect | ||
| - | |||
| - | ===== Členění modelu ===== | ||
| - | |||
| - | Tato metodika modelování platí pro enterprise architekturu celku, domén a segmentů OVS, v mírně omezené míře, respektive aplikovaně, | ||
| - | |||
| - | 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: | ||
| - | |||
| - | - Mají jiný účel | ||
| - | - Jazyk ArchiMate se pro ně málo hodí (spíše UML). | ||
| - | |||
| - | ==== Segmentace | ||
| - | |||
| - | 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í, | ||
| - | |||
| - | Na obrázku níže je ilustrován princip strukturování modelů těchto typů. | ||
| - | |||
| - | Ilustrace segmentace modelu z pohledu jednoho úřadu | ||
| - | |||
| - | ==== Struktura modelu ==== | ||
| - | |||
| - | Jednotná struktura modelů významně pomáhá jejich pochopitelnosti a umožňuje zastupitelnost jak na straně čtenářů, | ||
| - | |||
| - | 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“, | ||
| - | |||
| - | Princip strukturování modelu úřadu | ||
| - | |||
| - | ^Prvek | ||
| - | |Kořenový uzel | ||
| - | |Část úřadu | ||
| - | |Architektonická doména|Modelovaná vrstva/ | ||
| - | |Katalogy elementů | ||
| - | |Pohledy | ||
| - | |Přehledová hlediska | ||
| - | |||
| - | ==== Úrovně detailu ==== | ||
| - | |||
| - | 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. | ||
| - | |||
| - | ^ ^Název | ||
| - | |L0|**Přehledová**|Ukazuje principy a podstatu. Dává celkový přehled, celkový pohled na systém v dané doméně/ | ||
| - | |L1|**Základní** | ||
| - | |L2|**Detailní** | ||
| - | |||
| - | Detailní informace o konceptu úrovní detailu v NAR najdete na [[https:// | ||
| - | |||
| - | {{media/ | ||
| - | |||
| - | Přehledová úroveň L0 | ||
| - | |||
| - | {{media/ | ||
| - | |||
| - | Základní úroveň L1 (červený rámeček ukazuje proces rozpracovaný na úrovni L2) | ||
| - | |||
| - | {{media/ | ||
| - | |||
| - | Detailní úroveň L2 | ||
| - | |||
| - | ==== Modelování časové dimenze ==== | ||
| - | |||
| - | 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: | ||
| - | |||
| - | ^Model aktuální situace je základ | ||
| - | |Vývojové varianty modelujte odděleně od hlavního modelu | ||
| - | |Časový vývoj modelujte s pomocí vrstvy Implementace a migrace | ||
| - | |V případě potřeby doplňte interval platnosti k prvkům a udržujte jej aktuální | ||
| - | |Označujte model datem platnosti | ||
| - | |Archivujte časové řezy | ||
| - | |||
| - | {{media/ | ||
| - | |||
| - | ==== Metainformace ==== | ||
| - | |||
| - | 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: | ||
| - | |||
| - | ^Metainformace | ||
| - | |Datum platnosti | ||
| - | |Autor/ | ||
| - | |Datum poslední aktualizace | ||
| - | |Vrstva architektury | ||
| - | |Úroveň detailu | ||
| - | |Reference na příslušnou část metamodelu|Určení, | ||
| - | |||
| - | ====== Modelování dle NAR ====== | ||
| - | |||
| - | ===== Architektonické domény ===== | ||
| - | |||
| - | Domény se podle NAR dělí na základní horizontální domény (Core), tzv. vrstvy, které představují výkon veřejné správy a provozu OVS a k tomu potřebné zdroje. Vertikální motivační domény určují důvody, proč základní domény obsahují, co obsahují, nebo proč by se měly změnit. Nakonec doména Implementace a migrace podporuje modelování té části reality OVS, kterou představují plánované a realizované změny v základních vrstvách (i změny a balíčky práce-projekty jsou součástí reality OVS). | ||
| - | |||
| - | {{media/ | ||
| - | |||
| - | Detailně jsou architektonické domény NAR popsané přímo ve zdrojovém materiálu: | ||
| - | |||
| - | https:// | ||
| - | |||
| - | ===== Metamodel | ||
| - | |||
| - | Metamodel v ArchiMate slouží jako základní rámec pro modelování podnikové architektury. Definuje možné elementy a vztahy, čímž zajišťuje konzistenci a srozumitelnost napříč různými modely a organizacemi. Použití metamodelu zajišťuje kompatibilitu a snadné sdílení modelů vytvořených různými týmy nebo nástroji, což podporuje spolupráci a výměnu informací. Díky němu lze také automatizovat správu modelů a kontrolovat jejich kvalitu. | ||
| - | |||
| - | Z pohledu modeláře je metamodel nejdůležitější referencí při tvorbě modelů. | ||
| - | |||
| - | ==== Povinnost využití prvků metamodelu ==== | ||
| - | |||
| - | Tento obecný dokument stanovuje „co je možné“ a neříká, které prvky je nutné použít. Informace o povinných využitých prvcích je popsaná v metodikách pro jednotlivá architektonická angažmá (případy užití). | ||
| - | |||
| - | ==== Metamodely dle komplexity ==== | ||
| - | |||
| - | Pro potřeby metodiky modelování architektury v DIA definováno několik úrovní metamodelu, podle očekávané míry detailu obsažených informací v daném modelu. Ukazují také, které elementy by měly být v jádru modelu (Zjednodušený metamodel) a které se hodí pro popis sloužitějších detailnějších konstrukcí (až po Maximální metamodel). | ||
| - | |||
| - | === Maximální === | ||
| - | |||
| - | Maximální metamodel ukazuje celkovou množinu prvků a vazeb, použitelných při vytváření modelů pro DIA. Kromě prvků definovaných ArchiMate je tento metamodel rozšířený o prvky z TOGAF a o specifické prvky pro DIA. | ||
| - | |||
| - | Tento metamodel není doporučen k přímému použití ale spíše k vymezení možností v případě velmi komplexních modelů a edukovaných čtenářů. | ||
| - | |||
| - | === Základní === | ||
| - | |||
| - | Tento metamodel je oproti Maximálnímu zjednodušen do podoby, kterou lze očekávat, že bude využívána u modelů obvyklého rozsahu, zejména u tzv. povinných angažmá. Tato metodika modelování dále pracuje se základním metamodelem. | ||
| - | |||
| - | === Zjednodušený === | ||
| - | |||
| - | Zjednodušený metamodel ukazuje pouze zásadní elementy. Jeho účelem je hlavně pochopit hlavní myšlenky a koncepce modelů pro DIA. | ||
| - | |||
| - | Pro ilustraci je níže uveden Základní metamodel v podobě, v jaké je prezentován v NARu. | ||
| - | |||
| - | {{media/ | ||
| - | |||
| - | Základní metamodel dle NAR pro ilustraci | ||
| - | |||
| - | Detailně jsou metamodely na jednotlivých úrovních popsány v NARu: | ||
| - | |||
| - | https:// | ||
| - | |||
| - | ==== Doménové metamodely | ||
| - | |||
| - | Každá doména v této metodice má vlastní detailní metamodel, který je ale vždy součást celkového metamodelu. Cílem je ukázat výčet elementů a vazeb použitelných pro modelování v dané doméně. | ||
| - | |||
| - | Kompletní informaci o jednotlivých metamodelech najdete v NAR: https:// | ||
| - | |||
| - | ===== Elementy a vazby ===== | ||
| - | |||
| - | Metodika NAR přebírá elementy a vazby ze standardu ArchiMate, přičemž ale tvoří jejich nadstavbu. U některých z nich upřesňuje český název a/nebo význam a dále definuje vlastní elementy, byť využívající jako základy typy dle ArchiMate. | ||
| - | |||
| - | Elementy a vazby, které mohou být využity v modelech postavených na metamodelu výše jsou specifikované v NARu: https:// | ||
| - | |||
| - | ===== Vizuální konvence prvků modelů ===== | ||
| - | |||
| - | Tato metodika respektuje definovaný vzhled, barevnost a pravidla vizualizace dle standardu ArchiMate. Tato pravidla je třeba dodržet. Obvyklé modelovací nástroje vizuální standard ArchiMate implementují a splňují, není v nich proto třeba v této oblasti nic specifického nastavovat. | ||
| - | |||
| - | Detailní popis použitého vizuálního standardu najdete v NARu: https:// | ||
| - | |||
| - | ===== Přehled výstupů ===== | ||
| - | |||
| - | {{media/ | ||
| - | |||
| - | Přehled výstupů v jednotlivých architektnických doménách dle NAR | ||
| - | |||
| - | ===== Tvorba modelu v jednotlivých doménách ===== | ||
| - | |||
| - | Jak je popsáno v kap. 4.14.1, pracuje tato metodika s deseti architektonickými doménami. Níže je po jednotlivých architektonických doménách v NAR popsán způsob tvorby modelu a příslušných artefaktů. Předpokládá se situace, kdy je architekt jako modelář postaven před úkol zmapovat aktuální situaci v úřadu, tedy že systematický model ještě neexistuje. Na závěr kapitoly jsou uvedena pravidla pro přehledové a průřezové artefakty (katalogy a diagramy), výrazně se vymykající jednotlivým doménám a přesahující je. | ||
| - | |||
| - | ==== Byznys architektura výkonu a provozu veřejné správy ==== | ||
| - | |||
| - | Základní modelovaný obsah byznys reality OVS slouží pro lepší pochopení požadavků byznysu na aplikační podporu. Proto potřebujeme poznat a pochopit, jaké má úřad agendy a činnosti (funkce a procesy), jestli jsou vykonávány jako služby, a dále kým, pro koho a jak, kterým obslužným kanálem, s jakými daty a dokumenty. | ||
| - | |||
| - | === Doporučení pro modelování prvků BA === | ||
| - | |||
| - | Následující kapitoly vysvětlují, | ||
| - | |||
| - | == Jak modelovat agendy a činnosti VS == | ||
| - | |||
| - | Agendy a agendové činnosti jsou základními elementy pro modelování náplně práce úřadu. Jsou primárně definované a udržované v Registru Práv a Povinností((https: | ||
| - | )), kde je také uvedeno přiřazení k jednotlivým úřadům. | ||
| - | |||
| - | Je vhodné zmapovat agendy a činnosti nezávisle na RPP, aby byly dokumentované i neohlášené agendy, které v RPP nejsou, ale úřad je vykonává. Možným zdrojem informací může být Organizační řád úřadu a komunikace s příslušnými Ohlašovateli agend a referenty. | ||
| - | |||
| - | Agenda i agendová činnost jsou modelovány pomocí elementů „Agenda“ a „Agendová činnost“ (Business function dle ArchiMate). Při modelování je převzat oficiální název a identifikátor agendy a činnosti z RPP. Popis by pak měl obsahovat specifika realizace dané agendy či činnosti v daném úřadě, aby nedocházelo k duplikování informací z RPP. | ||
| - | |||
| - | {{media/ | ||
| - | |||
| - | Identifikace elementů a vazeb pro tuto oblast v metamodelu | ||
| - | |||
| - | == Jak modelovat služby a úkony z Katalogu služeb VS == | ||
| - | |||
| - | Služby veřejné správy jsou detailnějším rozpadem agend. Popisují, jak agendy slouží klientům úřadu a jak jsou navázané na produkty, smlouvy, předpisy a jakými obslužnými kanály je poskytovaná. | ||
| - | |||
| - | Zdrojem pro výčet služeb je Katalog služeb veřejné správy((Informace o katalogu: https: | ||
| - | )), který je členěn i dle poskytovatelů služby (úřad, který danou službu poskytuje). | ||
| - | |||
| - | Je vhodné zmapovat služby nezávisle na KSVS, aby byly dokumentované i realizované služby neohlášených agend, interní služby poskytované úřady navzájem a služby pokrývané externími dodavateli (typicky služby IT podpory, správa budov, apod,). | ||
| - | |||
| - | Služby mají velmi různorodou granularitu a celkové množství služeb je značné, proto je vhodné některé menší služby seskupovat pod jeden element postihující celou množinu. Informaci o jednotlivých pokrytých službách pak je možné zadat do popisu. | ||
| - | |||
| - | Služby veřejné správy jsou modelované pomocí elementu „Služba veřejné správy“ (Business service dle ArchiMate). Při modelování je převzat oficiální název a identifikátor agendy a činnosti z KSVS. Popis by pak měl obsahovat specifika realizace dané agendy či činnosti v daném úřadě, aby nedocházelo k duplikování informací z KSVS. | ||
| - | |||
| - | {{media/ | ||
| - | |||
| - | Identifikace elementů a vazeb na okolí pro tuto oblast v metamodelu | ||
| - | |||
| - | == Jak modelovat životní události a životní situace == | ||
| - | |||
| - | Životní události a situace mají velký význam pro konzumenty služeb – klienty úřadů. Popisují významné změny a stavy v jejich životě a často bývají spouštěči či důsledky využití služeb úřadů. Při modelování jsou využité často jako vstupní body do interakcí občana s IS úřadů – tedy obvykle při návrhu řešení IS. | ||
| - | |||
| - | Pro modelování podnikové architektury ale obvykle zásadní nejsou, neboť pro identifikaci služeb a procesů jsou použité jiné stabilní zdroje informací. | ||
| - | |||
| - | Životní události jsou modelované pomocí elementu „Životní událost“ (Business event dle ArchiMate). Obvykle jsou napojené na procesy či funkce realizující jednotlivé obchodní služby, jako jejich spouštěče či důsledky. Mohou být případně navázané na samotné Služby VS pro evidenci jejich pokrytí. | ||
| - | |||
| - | {{media/ | ||
| - | |||
| - | Identifikace elementů a vazeb na okolí pro tuto oblast v metamodelu | ||
| - | |||
| - | == Jak modelovat organizační jednotky a pracovní pozice == | ||
| - | |||
| - | Struktura organizace je vyjádřena stromovou strukturou útvarů, případně i konkrétních pracovních pozic. Při modelování podnikové architektury se tyto prvky používají pro mapování vztahu daného útvaru na služby, kanály, či jiné části, např. pro vyjádření vlastnictví, | ||
| - | |||
| - | Informace o organizační struktuře úřadu je primárně udržovaná v Organizačním řádu. Není tedy nezbytně nutné ji modelovat samu o sobě. | ||
| - | |||
| - | Organizační jednotky a pracovní pozice jsou modelované pomocí elementů „Útvar“, | ||
| - | |||
| - | {{media/ | ||
| - | |||
| - | Identifikace elementů a vazeb na okolí pro tuto oblast v metamodelu | ||
| - | |||
| - | == Jak modelovat zákony, vyhlášky a vnitřní předpisy == | ||
| - | |||
| - | Předpisy v různé podobě (zákon, vyhláška, vnitřní předpis, …) jsou často důvodem pro existenci dané služby či formují její fungování. Z toho důvodu je zajímavé je modelovat na úrovni podnikové architektury, | ||
| - | |||
| - | Předpisy jsou modelované pomocí elementů „Předpis“ a „Smlouva, SLA služeb VS“ (Contract dle ArchiMate). Obvykle jsou navázané na Službu VS či Produkt VS. | ||
| - | |||
| - | {{media/ | ||
| - | |||
| - | Identifikace elementů a vazeb na okolí pro tuto oblast v metamodelu | ||
| - | |||
| - | == Jak modelovat obslužné kanály == | ||
| - | |||
| - | Obslužný kanál popisuje rozhraní, skrz které klient či pracovník úřadu přistupuje k jeho službám. Kanál je často předepsán legislativně (typicky ze zákona o právu na digitální službu). Obslužný kanál je modelovaný pomocí elementu „Obslužný kanál VS“ (Business interface dle ArchiMate). Obvykle je vázán jako mezičlánek mezi Službu VS a Účastníka interakce s VS. | ||
| - | |||
| - | == Jak modelovat procesy == | ||
| - | |||
| - | Procesy jsou obvykle nejdetailnější úrovní popisu obchodní vrstvy v podnikové architektuře. Cílem je identifikovat: | ||
| - | |||
| - | Na této úrovni lze popsat i obchodní funkce. Obchodní funkce je obecnější pojem než proces. Proces je z pohledu NAR vnímán jako specifický druh obchodní funkce, který má charakteristiku procesu: má jasného vlastníka, je řízený jako proces a chová se jako proces. | ||
| - | |||
| - | Procesy i obchodní funkce jsou modelované pomocí elementů „Předpis“ a „Smlouva, SLA služeb VS“ (Contract dle ArchiMate). Hlavní vazbou je realizace příslušné Služby VS. Pokud je to vhodné, je možné navázat funkci/ | ||
| - | |||
| - | {{media/ | ||
| - | |||
| - | Identifikace elementů a vazeb na okolí pro tuto oblast v metamodelu | ||
| - | |||
| - | === Hlediska a pohledy === | ||
| - | |||
| - | Důležitými čtenáři byznys architektury jsou business architekti, datoví/ | ||
| - | |||
| - | * Hledisko portfolia (klasifikace) byznys funkcí, procesů a služeb | ||
| - | * Hledisko funkcí veřejné správy | ||
| - | * Produktové hledisko | ||
| - | * Hledisko spolupráce byznys procesů | ||
| - | * Hledisko organizační struktury | ||
| - | * Hledisko spolupráce aktérů | ||
| - | |||
| - | == Katalogy == | ||
| - | |||
| - | Každý modelovaný typ elementu by měl mít vlastní katalog, jelikož společně s maticí představují výchozí předpoklad pro jeho správné grafické vyjádření. Nejdůležitější pro čtenáře výše bývají následující: | ||
| - | |||
| - | * Katalog agend, činností (funkcí a procesů) | ||
| - | * Katalog služeb a úkonů veřejné správy | ||
| - | * Katalog aktérů (jejich typů) a jejich rolí | ||
| - | * Katalog obslužných rozhraní veřejné správy | ||
| - | * Katalog typů subjektů a objektů (konceptuální sémantický katalog)((Katalog je základem datové domény architektury, | ||
| - | |||
| - | Dále to mohou být například: | ||
| - | |||
| - | * Katalog organizačních jednotek, útvarů a pozic | ||
| - | * Katalog životních událostí, uplatnitelných vůči OVS | ||
| - | * Katalog formulářů a výstupů OVS | ||
| - | |||
| - | == Diagramy == | ||
| - | |||
| - | Zajímavé diagramy pro tuto vrstvu jsou uvedeny v tabulce níže. | ||
| - | |||
| - | ^Diagram | ||
| - | |Organizační struktura((https: | ||
| - | |Přehled (mapa) schopností úřadu((https: | ||
| - | |Mapa agend |Přehled agend úřadu | ||
| - | |Mapa služeb VS |Přehled služeb | ||
| - | |Mapa procesů a funkcí | ||
| - | |Spolupráce procesů((https: | ||
| - | |Proces((https: | ||
| - | |Diagram informačních objektů | ||
| - | |||
| - | === Na co si dát pozor === | ||
| - | |||
| - | ^Zajistěte si podporu organizace | ||
| - | |**Nezabředněte do příliš velkého detailu** | ||
| - | |||
| - | === Reference === | ||
| - | |||
| - | Přesnou definici prvků a metamodel pro obchodní vrstvu najdete v NARu: https:// | ||
| - | |||
| - | ==== Aplikační architektura IS a datová architektura ==== | ||
| - | |||
| - | Architektura aplikací a dat je stěžejní částí architektonických modelů, neboť drtivá většina agend z byznys architektury je realizovaná právě službami aplikací. V této oblasti se zaměřujeme na zmapování portfolia aplikací v úřadu a způsob, jakým spolu aplikace interagují pomocí rozhraní a s jakými daty pracují. Dále nás zajímá mapování na prvky z úrovně byznys architektury, | ||
| - | |||
| - | Doporučená redukce metamodelu NAR pro aplikační úroveň je vyobrazená na následujícím schématu. | ||
| - | |||
| - | {{media/ | ||
| - | |||
| - | Doporučená redukce metamodelu aplikační architektury | ||
| - | |||
| - | === Doporučení pro modelování prvků AA === | ||
| - | |||
| - | == Jak modelovat aplikační komponenty == | ||
| - | |||
| - | Aplikační komponenta je nejvýraznější element aplikační architektury. Reprezentuje jednotlivé IT systémy, aplikace, nebo jejich části (pokud je to z pohledu podnikové architektury zajímavý detail) v podniku. Katalog aplikačních komponent je základním prvkem podnikové architektury, | ||
| - | |||
| - | Základními atributy aplikačních komponent by měly být: | ||
| - | |||
| - | * Název | ||
| - | * Identifikátor | ||
| - | * Vlastník z byznysu (tzv. Věcný správce ISVS, určuje účel aplikace a její funkčnosti) | ||
| - | * Technický vlastník (tzv. Technický správce ISVS, navrhuje řešení a stará se, aby aplikace fungovala) | ||
| - | * Kategorizace | ||
| - | * Kritičnost pro fungování podniku | ||
| - | |||
| - | Doporučených atributů, užitečných pro správu aplikačního portfolia jsou desítky, viz přiložený soubor. | ||
| - | |||
| - | {{media/ | ||
| - | |||
| - | Zdrojem informací o aplikačních komponentách je typicky portfolio udržovaných aplikací a systémů evidované provozními týmy IT. | ||
| - | |||
| - | Zásadní informace u aplikační komponenty jsou vazby na okolí: | ||
| - | |||
| - | * Jaké aplikační funkce a služby realizuje | ||
| - | * Jaká aplikační rozhraní poskytuje a konzumuje | ||
| - | * S jakými Datovými objekty pracuje | ||
| - | |||
| - | > Situace je ilustrována na následujícím obrázku. Podrobněji je o těchto elementech a vazbách pojednáno níže. | ||
| - | |||
| - | {{media/ | ||
| - | |||
| - | Identifikace elementů a vazeb na okolí pro tuto oblast v metamodelu | ||
| - | |||
| - | == Jak modelovat aplikační služby == | ||
| - | |||
| - | Aplikační služba realizuje Službu veřejné správy skrze využití ve Funkci/ | ||
| - | |||
| - | Aplikační služby lze chápat jako požadavky na funkce IT aplikace, které definuje vlastník příslušných procesů a služeb na byznys úrovni. Aplikační služba je pak realizována sadou Aplikačních funkcí, které poskytuje příslušná Aplikační komponenta. | ||
| - | |||
| - | Aplikační služby by měly vyplývat z potřeb prováděných Funkcí/ | ||
| - | |||
| - | {{media/ | ||
| - | |||
| - | Fragment metamodelu NAR ilustrující kontext Aplikační služby | ||
| - | |||
| - | == Jak modelovat aplikační rozhraní == | ||
| - | |||
| - | Aplikační rozhraní je bod, kde jsou aplikační služby zpřístupněny uživatelům, | ||
| - | |||
| - | Význam evidence Aplikačních rozhraní je hlavně v systematizaci komunikace mezi aplikacemi a vůči uživatelům. Díky zmapování rozhraní je možné identifikovat vzory komunikace mezi aplikačními komponentami a je snadné přepoužívat existující rozhraní s vědomím dopadu změny. Velmi důležitá je evidence rozhraní k aplikačním službám, které jsou sdílené externě (mezi úřady). | ||
| - | |||
| - | Obvyklým zdrojem informací o existujících rozhraních je obchodní proces, kde jej identifikované použití rozhraní na aplikační úrovni. Dále je možné identifikovat existenci rozhraní ze solution architektury a/nebo z technické dokumentace aplikací. Dobrým zdrojem je i celofiremní integrační komponenta typu ESB (Enterprise Service Bus), či podobná, kde jsou často využívaná rozhraní koncentrována. | ||
| - | |||
| - | Aplikační rozhraní je vždy vlastněno vybranou aplikační komponentou, | ||
| - | |||
| - | K aplikačnímu rozhraní je možné namapovat Datové objekty, které jsou jím přenášené. | ||
| - | |||
| - | K aplikačním rozhraním je vhodné udržovat dle potřeby následující atributy: | ||
| - | |||
| - | * Technologie (REST, XML, proprietární, | ||
| - | * Typ komunikace (sync, async, batch) | ||
| - | * Reference na detailní dokumentaci k rozhraní | ||
| - | |||
| - | {{media/ | ||
| - | |||
| - | Identifikace elementů a vazeb na okolí pro tuto oblast v metamodelu | ||
| - | |||
| - | == Jak modelovat datové objekty == | ||
| - | |||
| - | Datové objekty reprezentují realizaci Objektů VS (Business Object) na aplikační úrovni, tj. Na úrovni obrazů skutečných věcí z BA v datech informačních systémů. Případně jsou to reprezentace jiných pasivních prvků evidovaných na úrovni aplikační architektury. Jejich granularita je obvykle jemnější než u Objektů VS, aby na ně bylo možno jednoznačně navázat dalšími prvky v aplikační vrstvě. | ||
| - | |||
| - | Zdrojem pro model Datových objektů jsou konceptuální a logické datové modely příslušných aplikací, ideálně získané z datového katalogu úřadu((https:// | ||
| - | )). Abychom předešli duplikaci informací mezi datovým katalogem a modelem podnikové architektury, | ||
| - | |||
| - | Modelujeme hlavně ty Datové objekty, které jsou reprezentací Objektů VS a jsou sdílené mezi aplikacemi. Je vhodné vždy rozmyslet, zda daný objekt potřebujeme v modelu mít, abychom předešli zvyšování komplexity modelu, přílišné náročnosti údržby aktuálního stavu a zaručili konzistentní granularitu skrz model. | ||
| - | |||
| - | Někdy může být užitečné, | ||
| - | |||
| - | {{media/ | ||
| - | |||
| - | Identifikace elementů a vazeb na okolí pro tuto oblast v metamodelu | ||
| - | |||
| - | === Hlediska a pohledy === | ||
| - | |||
| - | Důležitými čtenáři aplikační architektury jsou solution architekti, datoví/ | ||
| - | |||
| - | * Hledisko aplikačního portfolia (Mapa) | ||
| - | * Hledisko struktury informací | ||
| - | * Hledisko struktury aplikací | ||
| - | * Hledisko chování aplikací | ||
| - | * Hledisko spolupráce aplikací | ||
| - | * Hledisko využití aplikací | ||
| - | * Hledisko realizace požadavků aplikacemi | ||
| - | |||
| - | == Katalogy == | ||
| - | |||
| - | Každý modelovaný typ elementu by měl mít vlastní katalog, jelikož společně s maticí představují výchozí předpoklad pro jeho správné grafické vyjádření. Nejdůležitější pro čtenáře výše bývají následující: | ||
| - | |||
| - | * Katalog aplikačních komponent | ||
| - | |||
| - | Dále to mohou být například: | ||
| - | |||
| - | * Katalog aplikačních služeb | ||
| - | * Katalog rozhraní | ||
| - | * Katalog datových objektů | ||
| - | |||
| - | == Diagramy == | ||
| - | |||
| - | Zajímavé diagramy pro tuto vrstvu jsou uvedeny v tabulce níže. | ||
| - | |||
| - | ^Diagram | ||
| - | |Mapa aplikačních komponent((https: | ||
| - | |Diagram struktury aplikací((https: | ||
| - | |Diagram datových objektů< | ||
| - | |Diagram aplikačních funkcí | ||
| - | |||
| - | == Matice == | ||
| - | |||
| - | Matice zajímavé pro tuto vrstvu: | ||
| - | |||
| - | ^Matice | ||
| - | |Mapování Datových objektů na Objekty VS |Ukazuje jaké Datové objekty realizují jaké Objekty VS z byznys architektury | ||
| - | |Mapování Aplikačních služeb na Funkce/ | ||
| - | |Mapování aplikačních komponent na organizační strukturu | ||
| - | |||
| - | === Na co si dát pozor === | ||
| - | |||
| - | ^Držte správnou granularitu aplikačních komponent | ||
| - | |**Zamezte duplikaci informací mezi evidenčními systémy a modelem podnikové architektury** | ||
| - | |||
| - | === Reference === | ||
| - | |||
| - | Přesnou definici prvků a metamodel pro aplikační a datovou architekturu najdete v NARu: https:// | ||
| - | |||
| - | ==== Architektura IT (HW/SW) technologické infrastruktury ==== | ||
| - | |||
| - | //Motto: „na čem to běží, kde to běží a jak si to spolu povídá“.// | ||
| - | |||
| - | Tato oblast je jedna ze dvou, které se v této metodice věnují infrastruktuře. Cílem obou je popsat technické podhoubí, které umožňuje fungování podnikových aplikací a jejich komunikaci. | ||
| - | |||
| - | Vrstva technologické infrastruktury má za cíl ukázat, jaké technické platformy jsou v podniku k dispozici, | ||
| - | |||
| - | {{media/ | ||
| - | |||
| - | Doporučená redukce metamodelu technologické infrastruktury | ||
| - | |||
| - | === Doporučení pro modelování prvků TA === | ||
| - | |||
| - | == Jak modelovat technologické služby a funkce == | ||
| - | |||
| - | Technologická služba (Technology service v ArchiMate) popisuje požadavek na to, co by měla technologická vrstva umět a poskytovat směrem k vyšším vrstvám, zejména aplikační. Definuje se proto, aby byl zřejmý účel technologických prvků v podniku (realizují tech. službu). Tech. služby realizují podmínky pro fungování aplikací a procesů na aplikační úrovni. Zdrojem pro přehled Tech. služeb může být implementace strategické části metodiky ITIL v podniku. Očekává se, že na definici tech. služeb poskytovaných v podniku se podílí i podnikový architekt. Příklady tech. služeb jsou Internetová konektivita, | ||
| - | |||
| - | Technologické funkce (Technology function v ArchiMate) lze využít k popisu schopností nabízených na úrovni uzlů. Typicky se jedná o funkce jednotlivých datových center, jako např. Zajištění výpočetního výkonu, Virtualizace, | ||
| - | |||
| - | Tech. služby jsou realizovány Tech. funkcemi. | ||
| - | |||
| - | {{media/ | ||
| - | |||
| - | Příklad modelu technologické služby | ||
| - | |||
| - | == Jak modelovat uzly, zařízení a systémový SW == | ||
| - | |||
| - | Uzel (Node v ArchiMate) je základním prvkem modelu technologické infrastruktury. Reprezentuje typicky server či jiný fyzický prvek počítačového typu. Zařízení (Device v ArchiMate) je pak obvykle nějaká jeho fyzická součást a Systémový software (System software v ArchiMate) pak běží na daném zařízení, | ||
| - | |||
| - | Zařízení může figurovat jako samostatný prvek na úrovni uzlu, typicky pro specializovaná zařízení typu firewallu, či fileserveru. | ||
| - | |||
| - | Důležitým atributem v evidenci u Systémového software je jeho verze. Doporučujeme držet ji na úrovni podnikové architektury, | ||
| - | |||
| - | {{media/ | ||
| - | |||
| - | Příklad vztahu mezi uzlem, systémovým sofwarem a zařízením | ||
| - | |||
| - | == Jak modelovat komunikační infrastrukturu == | ||
| - | |||
| - | Komunikační infrastruktura se modeluje elementem Síť (Communication Network v ArchiMate). Síť propojuje uzly. Typickými příklady komunikačních sítí jsou WiFi na úřadu, Lokální síť (LAN), Internet (WAN). | ||
| - | |||
| - | Uzly se k síti připojují pomocí vazby agregace. | ||
| - | |||
| - | {{media/ | ||
| - | |||
| - | Příklad propojení uzlů pomocí sítě LAN | ||
| - | |||
| - | == Jak modelovat datové elementy na technologické úrovni == | ||
| - | |||
| - | Element Artefakt (Artefact v ArchiMate) reprezentuje datový prvek na úrovni tech. architektury. Element Artefakt použijeme tehdy, když chceme ukázat realizaci Datového objektu z aplikační vrstvy (viz kap. 4.6.2.1.4), např. za účelem zaznamenání jeho technického uložení či využití v uzlu.Rozhodně není vhodné snažit se pomocí Artefaktů modelovat DB tabulky, Artefakt reprezentuje spíše celou DB či schéma v ní. Pro potřeby detailních informací využijte technickou dokumentaci. Modelování Artefaktů je součástí pokročilého modelování datové architektury. | ||
| - | |||
| - | {{media/ | ||
| - | |||
| - | Realizace datového objektu několika artefakty v node (uzlu) | ||
| - | |||
| - | === Hlediska a pohledy === | ||
| - | |||
| - | Čtenáři informací z oblasti technologické architektury jsou zejména Manažeři provozu (operations), | ||
| - | |||
| - | * dostupné portfolio technických platforem pro realizaci změn v aplikačním portfoliu | ||
| - | * způsob realizace technologických služeb | ||
| - | * propojenost uzlů pro komunikaci | ||
| - | * dostupnost technologických funkcí v jednotlivých umístěních | ||
| - | |||
| - | Relevantní hlediska NAR: | ||
| - | |||
| - | * Hledisko technologického portfolia (mapa) | ||
| - | * Hledisko technologické infrastruktury - obecné | ||
| - | * Hledisko využití infrastruktury | ||
| - | * Zjednodušené hledisko nasazení informačních systémů | ||
| - | * //Hledisko využití komunikační infrastruktury (specifické pro ČR)// | ||
| - | * //Hledisko portfolia komunikační architektury (Mapa, specifické pro ČR)// | ||
| - | |||
| - | == Katalogy == | ||
| - | |||
| - | Doporučujeme formou katalogů evidovat všechny základní typy elementů: | ||
| - | |||
| - | * Katalog Technologických služeb (víceúrovňový) | ||
| - | * Katalog Uzlů (včetně Systémových SW a Zařízení) | ||
| - | * Katalog Sítí | ||
| - | * Katalog Technologických služeb | ||
| - | * Katalog Technologických funkcí | ||
| - | |||
| - | == Diagramy == | ||
| - | |||
| - | ^Diagram | ||
| - | |Mapa technologického portfolia | ||
| - | |Mapa využití tech. služeb pro realizaci aplikační vrstvy | ||
| - | |Realizace aplikací pomocí SW a HW infrastruktury | ||
| - | |||
| - | {{media/ | ||
| - | |||
| - | {{media/ | ||
| - | |||
| - | Mapa využití tech. služeb pro realizaci aplikační vrstvy | ||
| - | |||
| - | {{media/ | ||
| - | |||
| - | Realizace aplikací pomocí SW a HW infrastruktury | ||
| - | |||
| - | //Pozn: V této oblasti nejsou identifikované žádné zajímavé matice.// | ||
| - | |||
| - | === Na co si dát pozor === | ||
| - | |||
| - | ^Držte nejhrubší detail potřebný pro podnikového architekta^Více než kde jinde je zde důležité nepřesáhnout míru detailu modelu. Katalogy konkrétních fyzických serverů a zařízení je obtížné udržovat aktuální a pro podnikového architektura to není zajímavý detail. Soustřeďte se na modelování informací zajímavých strategicky a koncepčně.^ | ||
| - | |||
| - | === Reference === | ||
| - | |||
| - | Přesnou definici prvků a metamodel pro architekturu IT technologické infrastruktury najdete v NARu: https:// | ||
| - | |||
| - | ==== Architektura komunikační a fyzické infrastruktury ==== | ||
| - | |||
| - | Tato vrstva má za úkol popsat geografické umístění prvků infrastruktury a komunikační cesty mezi nimi. Využívá se tedy primárně pro model datových center a komunikačních okruhů. Důležitými elementy zde jsou Budova (Facility v ArchiMate) a Síť. | ||
| - | |||
| - | Pro potřeby modelování komunikačního kanálu mezi Budovami je možné efektivně použít elementu Komunikační cesta (Path v ArchiMate), | ||
| - | |||
| - | === Doporučení pro modelování prvků KFI === | ||
| - | |||
| - | == Jak modelovat umístění infrastruktury == | ||
| - | |||
| - | Z hlediska podnikové architektury jsou zajímavými umístěními (lokacemi) datová centra, případně serverovny. Modelují se jako Budovy, které agregují prvky, jež jsou v nich umístěné. Součástí modelu může být, jaké daná lokace nabízí tech. funkce. Lokace jsou propojené Sítěmi. | ||
| - | |||
| - | Důležitou vlastností Budovy je označení vystihující geografickou polohu. | ||
| - | |||
| - | {{media/ | ||
| - | |||
| - | Příklad modelu infrastruktury s dvěma datovými centry | ||
| - | |||
| - | === Hlediska a pohledy === | ||
| - | |||
| - | Čtenáři informací z oblasti komunikační a fyzické infrastruktury jsou zejména Manažeři provozu (operations), | ||
| - | |||
| - | * propojenost uzlů pro komunikaci | ||
| - | * dostupnost technologických funkcí v jednotlivých umístěních | ||
| - | |||
| - | Relevantní hlediska NAR: | ||
| - | |||
| - | * Nutno definovat v NAR | ||
| - | |||
| - | == Katalogy == | ||
| - | |||
| - | Zajímavé katalogy jsou: | ||
| - | |||
| - | * Katalog lokací (budovy, např. datová centra, serverovny, apod) | ||
| - | |||
| - | == Diagramy == | ||
| - | |||
| - | ^Diagram | ||
| - | |Přehled lokací | ||
| - | |Vybavení lokací | ||
| - | |||
| - | //Pozn: V této oblasti nejsou identifikované žádné zajímavé matice.// | ||
| - | |||
| - | === Na co si dát pozor === | ||
| - | |||
| - | Analogicky jako v kap. 4.6.3.4. | ||
| - | |||
| - | === Reference === | ||
| - | |||
| - | Přesnou definici prvků a metamodel pro architekturu komunikační a fyzické infrastruktury najdete v NARu: https:// | ||
| - | |||
| - | ==== Implementace a migrace ==== | ||
| - | |||
| - | V této oblasti se díváme na změny architektury podniku v čase, zejména jako výhled do budoucnosti ve formě roadmapy migrace. Účelem je ukázat čtenářům postup transformace z aktuálního stavu architektury na cílový. Při tvorbě je výchozím bodem současný stav architektury, | ||
| - | |||
| - | Migrací se myslí postup přechodu ze současné do cílové architektury přes potenciální dočasné (tranzientní) architektury. | ||
| - | |||
| - | === Postup při realizaci roadmapy === | ||
| - | |||
| - | Tým podnikové architektury vyjedná s ostatními zainteresovanými osobami podobu cílové architektury, | ||
| - | |||
| - | Mezi každými dvěma stavy architektury je pak stanovena sada Rozdílů, které je nutné realizovat pomocí projektů, či programů (Balíčků práce). Tento podklad je dále využit při plánování projektového portfolia podniku a při realizace konkrétních projektů. Během realizace projektu poskytuje podnikový architekt součinnost ve formě podkladů k daným Balíčkům práce a konzultací. | ||
| - | |||
| - | Po realizaci daného Balíčku práce (typicky release) musí podnikový architekt zaktualizovat aktuální stav architektury a roadmapu. | ||
| - | |||
| - | === Doporučení pro modelování prvků IM === | ||
| - | |||
| - | Změny v architektuře a její průběh v čase jsou reprezentovány několika elementy: | ||
| - | |||
| - | * **Stavy architektury** definují současné, cílové či přechodové podoby podnikové architektury. Nesou informaci o čase, v němž by měly být realizované. | ||
| - | * Stav architektury je kromě popisu doplněn odkazy na **Základní elementy struktury** z jednotlivých domén, které jsou jím ovlivněné. Vazba na Stav architektury určuje i období platnosti změny daného elementu. | ||
| - | * Mezi nimi jsou definované **Rozdíly**, | ||
| - | * které jsou pak zpracovány pomocí **Balíčků práce** (které mají zhruba velikost projektu). | ||
| - | * **Výstup projektu** pak určuje hlavní dodávané změny nutné pro realizaci daného Stavu architektury | ||
| - | |||
| - | Níže je uveden metamodel včetně kontextu do návazných oblastí architektury. | ||
| - | |||
| - | {{media/ | ||
| - | |||
| - | Identifikace elementů a vazeb pro tuto oblast v metamodelu | ||
| - | |||
| - | == Jak modelovat migraci == | ||
| - | |||
| - | Mezi dvěma Stavy architektury (Plateu v ArchiMate) jsou definované Rozdíly (Gap v ArchiMate) a jejich realizace probíhá pomocí Balíčků práce. | ||
| - | |||
| - | Ke Stavu architektury je vhodné pro ukotvení v čase přiřadit základní elementy z jednotlivých domén. Toto lze dobře řešit maticemi, kde je na jedné ose seznam Stavů architektury a na druhé sada elementů daného typu z vybrané domény. | ||
| - | |||
| - | Stav architektury v dané doméně (např. aplikační) je vizualizován přehledovými mapami architektury s vyznačením, | ||
| - | |||
| - | Typická podoba roadmapy migrace je na obrázku níže. | ||
| - | |||
| - | {{media/ | ||
| - | |||
| - | Příklad roadmapy se dvěma paralelními přechodovými architekturami | ||
| - | |||
| - | == Jak modelovat projektový aspekt == | ||
| - | |||
| - | Pro účely přípravy realizace identifikuje podnikový architekt Balíčky práce (Work package dle ArchiMate), které je potřeba realizovat, aby došlo k přechodu mezi dvěma Stavy architektury, | ||
| - | |||
| - | Architekt vytváří podklady pro věcné zadání projektu, samotný projekt je vytvářen a řízen projektovým managerem. | ||
| - | |||
| - | Výstupem je přehled projektů, které je nutné realizovat, aby došlo k nastolení cílového Stavu architektury. U každého projektu by měly být zřejmé jeho výstupy (Outcome dle ArchiMate), cíle a časování. Očekává se, že identifikované Balíčky práce budou navázané na skutečné rozběhlé projekty, řízené z podnikového týmu PMO (Project Management Office). | ||
| - | |||
| - | {{media/ | ||
| - | |||
| - | Diagram balíčků práce navázaných na konkrétní stavy architektury | ||
| - | |||
| - | === Hlediska a pohledy === | ||
| - | |||
| - | Očekávanými čtenáři této oblasti architektury jsou lidé zodpovědní za strategii a směřování podniku (včetně podnikových architektů), | ||
| - | |||
| - | Pro ně zajímavá hlediska z NAR jsou: | ||
| - | |||
| - | * Hledisko implementace a migrace | ||
| - | |||
| - | == Katalogy == | ||
| - | |||
| - | Elementy primárně zařazené do této oblasti mají své katalogy: | ||
| - | |||
| - | * Katalog Stavů architektury | ||
| - | * Katalog Rozdílů | ||
| - | * Katalog Balíčků práce | ||
| - | * Katalog Výstupů | ||
| - | |||
| - | == Diagramy == | ||
| - | |||
| - | Zajímavé diagramy pro tuto vrstvu jsou uvedeny v tabulce níže. | ||
| - | |||
| - | ^Diagram | ||
| - | |Pohled migrace | ||
| - | |Pohled implementace a migrace | ||
| - | |Projektový pohled | ||
| - | |||
| - | {{media/ | ||
| - | |||
| - | Ilustrační příklad: Pohled implementace a migrace | ||
| - | |||
| - | == Matice == | ||
| - | |||
| - | ^Matice | ||
| - | |Mapování Stavů architektury na měněné elementy | ||
| - | |||
| - | {{media/ | ||
| - | |||
| - | Příklad matice Mapování stavů architektury na měněné elementy | ||
| - | |||
| - | === Na co si dát pozor === | ||
| - | |||
| - | ^Nepodceňte potřebu plného sladění se stakeholdery | ||
| - | |**Nesuplujte práci projektového manažera** | ||
| - | |||
| - | === Reference === | ||
| - | |||
| - | Přesnou definici prvků a metamodel pro architekturu implementace a migrace najdete v NARu: https:// | ||
| - | |||
| - | ==== Architektura strategie a směřování ==== | ||
| - | |||
| - | V této oblasti modelujeme důvod, proč úřad (jako podnik) existuje a proč vypadá tak jak vypadá. NAR v této oblasti kombinuje motivační a strategickou vrstvu (dle ArchiMate). | ||
| - | |||
| - | Chceme vědět, v čím zájmu je, aby úřad existoval a jaké jsou motivátory k jeho existenci a hlavním aspektům jeho fungování. Z těchto prvků jsou pak odvozené cíle, které je naplňují. Na tomto základě pak definujeme principy, které ovlivňují architektonické požadavky, vedoucí na realizaci vnitřku organizace a omezení, která je nutné brát v potaz. | ||
| - | |||
| - | Dále by se v této oblasti měla nacházet odpověď na důvody, proč mají proběhnout / proběhly v organizaci změny. | ||
| - | |||
| - | Strukturu elementů a vazeb použitelných v této oblasti popisuje metamodel na obrázku níže. | ||
| - | |||
| - | {{media/ | ||
| - | |||
| - | Identifikace elementů a vazeb pro tuto oblast v metamodelu | ||
| - | |||
| - | === Doporučení pro modelování prvků MA === | ||
| - | |||
| - | == Jak modelovat Zainteresované strany == | ||
| - | |||
| - | Zainteresovaná strana odpovídá na otázku „V čím zájmu je, že jako úřad existuji a dělám to co dělám?“ Zainteresovanou stranou tedy bývá externí zřizovatel úřadu (vláda, ministerstvo? | ||
| - | |||
| - | == Jak modelovat Veřejné potřeby jako hnací prvky == | ||
| - | |||
| - | Hnací prvky (též motivátory) představují interní, či externí vlivy, které v důsledku formují vnitřní podobu úřadu („Proč úřad vypadá, jak vypadá? | ||
| - | |||
| - | * Veřejné potřeby jsou takovým případem hnacích prvků. Obvykle jsou dlouhodobě stabilní a určují základní aspekty fungování organizace. | ||
| - | * Analýzy či Vyhodnocení potřeby jsou výsledkem zhodnocení naplnění daného motivátoru. Identifikují potřebu změny, aby byl motivátor korektně naplněn. Definují se častěji, obvykle periodicky jako důsledek kontroly stavu organizace a jsou iniciátorem transformačních aktivit. | ||
| - | |||
| - | Hnací prvky (vč. Veřejných zájmů) modelujeme pomocí elementu Driver v ArchiMate, | ||
| - | |||
| - | == Jak modelovat Strategické cíle a Výstupy == | ||
| - | |||
| - | Strategické cíle naplňují Hnací prvky. Jsou často používány jako základní měřítko úspěšnosti fungování organizace. Do jaké míry/ | ||
| - | |||
| - | == Jak modelovat Architektonické principy | ||
| - | |||
| - | Architektonické principy definují sadu obecně platných pravidel, kterými se lze řídit při tvorbě podnikové architektury v dané oblasti. Jejich dodržováním se implicitně naplňují relevantní Strategické cíle. Při definici Strategických cílů je proto třeba brát v potaz jejich univerzálnost. | ||
| - | |||
| - | Architektonický princip by měl být definován např. následovně((https: | ||
| - | )): | ||
| - | |||
| - | ^Název | ||
| - | |Definice | ||
| - | |Důvod | ||
| - | |Důsledky | ||
| - | |||
| - | Pokud nejsme schopni danou část popisu principu naplnit, je pravděpodobné, | ||
| - | |||
| - | //Pozn.: V souladu s ArchiMate je možné označit sílu vazby pomocí ++/ | ||
| - | |||
| - | == Jak modelovat Klíčové požadavky a Omezující podmínky == | ||
| - | |||
| - | Při přípravě projektu, který bude realizovat zajištění Cíle či naplnění Výstupu je možné definovat Klíčové požadavky, jejichž splnění toto zajistí. Klíčové požadavky na úrovni podnikové architektury zdůrazňují důležité aspekty, které je potřeba vzít v potaz, např. naplnění určitých Architektonických principů. | ||
| - | |||
| - | Omezující podmínky pak systematickým způsobem vymezují „hřiště“, | ||
| - | |||
| - | {{media/ | ||
| - | |||
| - | Příklad hierarchie úrovní | ||
| - | |||
| - | === Hlediska a pohledy === | ||
| - | |||
| - | Očekávanými čtenáři informací v této oblasti jsou samotné Zainteresované strany – obvykle vrcholoví manažeři odpovědní za strategii v dané oblasti, dále samotní podnikoví architekti, architekti řešení a manažeři projektového portfolia. Podle toho volíme pohledy, které realizují pro ně zajímavá hlediska, jako jsou podle NAR: | ||
| - | |||
| - | * Motivační hledisko strategického směřování | ||
| - | |||
| - | Toto hledisko může být případně rozdělené podle očekávaných čtenářů na: | ||
| - | |||
| - | * Hledisko zainteresovaných stran | ||
| - | * Hledisko architektonických principů | ||
| - | |||
| - | == Katalogy == | ||
| - | |||
| - | Doporučujeme tvořit následující katalogy elementů: | ||
| - | |||
| - | * Katalog Zainteresovaných stran | ||
| - | * Katalog Veřejných potřeb/ | ||
| - | * Katalog Strategických cílů | ||
| - | * Katalog Vyhodnocení potřeb/ | ||
| - | * Katalog Výstupů | ||
| - | * Katalog Architektonických principů | ||
| - | * Katalog Klíčových architektonických požadavků a Omezujících podmínek | ||
| - | |||
| - | == Diagramy == | ||
| - | |||
| - | Zajímavé diagramy pro tuto doménu jsou uvedeny v tabulce níže. Pro lepší přehlednost je na obrázku barevně znázorněno pokrytí elementů metamodelu v diagramech. | ||
| - | |||
| - | {{media/ | ||
| - | |||
| - | Umístění elementů na diagramy v této oblasti | ||
| - | |||
| - | ^Diagram | ||
| - | |Přehled Zainteresovaných osob a Hnacích prvků | ||
| - | |Přehled Architektonických principů (Mapa) | ||
| - | |Realizace strategických elementů pomocí Klíčových požadavků a Omezujících podmínek | ||
| - | |||
| - | == Matice == | ||
| - | |||
| - | V této oblasti nejsou definované žádné specifické matice. Pro lepší přehlednost je možné připravit matice ukazující důležité vazby, např. pokrytí Hnacích prvků pomocí Strategických cílů, či genezi Hnacích prvků od Zainteresovaných stran či z Vyhodnocení potřeb. | ||
| - | |||
| - | === Na co si dát pozor === | ||
| - | |||
| - | ^Zajistěte stabilní strategii^Architektura strategie a směřování definuje základy, z nichž vychází celá architektura a fungování podniku. Měla by proto být co nejrobustnější a soustředit se na důležité prvky. Ty je však často obtížené identifikovat a nastavit měřitelně, | ||
| - | |||
| - | === Reference === | ||
| - | |||
| - | Přesnou definici prvků a metamodel pro architektura strategie a směřování najdete v NARu: [[https:// | ||
| - | |||
| - | Následující oblasti architektury jsou průřezové. Pro potřeby DIA je očekáván hlavně slovní popis situace. Navíc se jedná o oblasti, kde není metodika zcela detailní. Proto u nich není popsán mechanismus modelování. Informace pro systematičtější přístup, který se pravděpodobně bude dlouhodobě rozvíjet a upřesňovat je popsán v příslušných částech NAR. | ||
| - | |||
| - | ==== Architektura bezpečnosti ==== | ||
| - | |||
| - | Architektura bezpečnosti je důležitá průřezová disciplína, | ||
| - | )) od společnosti BizzDesign. Framework využívá vlastního rozšíření elementů jazyka ArchiMate v motivačním aspektu. | ||
| - | |||
| - | Základem frameworku je iterativní proces sestávající z 9 kroků, ilustrovaných na obrázku níže, které zajišťují systematické pokrytí bezpečnostních aspektů architektury. | ||
| - | |||
| - | {{media/ | ||
| - | |||
| - | Základní proces ESRM | ||
| - | |||
| - | Červené kroky představují fázi zhodnocení rizik, zelené pak fázi realizace opatření a mechanismů pro provoz, která pokrývá i realizaci prostředků a nástrojů pro fázi zhodnocení rizik. | ||
| - | |||
| - | === Reference === | ||
| - | |||
| - | https:// | ||
| - | |||
| - | ==== Architektura výkonnosti ==== | ||
| - | |||
| - | Momentálně není poptávané modelování výkonnosti pro potřeby DIA. Úřady by ale měly zavádět a udržovat mechanismy umožňující měřitelnost výsledků provedených změn a jejich dlouhodobého provozování. | ||
| - | |||
| - | Jazyk ArchiMate nyní neobsahuje metriky ani jiné ukazatele výkonnosti, | ||
| - | |||
| - | === Reference === | ||
| - | |||
| - | Informace k architektuře výkonnosti najdete v NARu zde: https:// | ||
| - | |||
| - | ==== Architektura shody s pravidly ==== | ||
| - | |||
| - | Tato oblast zajišťuje korektní navázání elementů z ostatních architektonických domén (zejména Motivační) na konkrétní předpisy, standardy a kritéria udržitelnosti. Jedná se tedy hlavně o popis toho, Jak jsou modelované tyto elementy a jak se na ně odkazovat ze zbylých částí modelu. | ||
| - | |||
| - | Předpokládaný způsob modelování je takový, že DIA/OHA bude vlastnit elementy reprezentující používané předpisy apod. a architekti úřadů na ně budou odkazovat pomocí vazeb z relevantních elementů – např. Hnacích prvků, Strategických cílů, Omezujících podmínek, apod., aby byl zřejmý jejich původ. | ||
| - | |||
| - | === Reference === | ||
| - | |||
| - | Informace k architektuře shody s pravidly najdete v NARu: https:// | ||
| - | |||
| - | ====== Nástroje ====== | ||
| - | |||
| - | ===== Modelovací nástroje ===== | ||
| - | |||
| - | Pro tvorbu modelů nejsou předepsané žádné konkrétní nástroje. Očekává se, že podnik využije svých znalostí a zkušeností k volbě nástroje dle uvážení. | ||
| - | |||
| - | Podrobněji jsou požadavky na nástroj popsané v NAR: [[https:// | ||
| - | |||
| - | ===== Výměna informací ===== | ||
| - | |||
| - | Pro usnadnění výměn informací ve strukturované podobě stanovuje OHA formát pro výměnu modelů(([[https:// | ||
| - | )). Jedná se o formát **The Open Group ArchiMate File Exchange Format**. | ||
| - | |||
| - | Je nutné, aby použitý nástroj podporoval export a import do/z tohoto formátu a interní procesy modelování umožňovaly doplnění potřebných metainformací k prvkům modelu, i samotnému exportovanému souboru. | ||
| - | |||
| - | ====== Definice pojmů v této metodice ====== | ||
| - | |||
| - | Níže je uvedena definice důležitých pojmů, s nimiž tento dokument pracuje. Cílem je jednoznačné chápání těchto pojmů v kontextu této metodické dokumentace. | ||
| - | |||
| - | Tabulka 1: Definice pojmů v této metodice | ||
| - | |||
| - | ^Zkratka | ||
| - | |ArchiMate | ||
| - | |BP | ||
| - | |ČR | ||
| - | |DIA |Digitální a informační agentura | ||
| - | |EA | ||
| - | |ESRM | ||
| - | |ICT |Informační a komunikační technologie | ||
| - | |IT | ||
| - | |NAR |Národní architektonický rámec | ||
| - | |OHA |odbor Hlavního architekta eGovernmentu | ||
| - | |OVS |Orgán veřejné správy | ||
| - | |PMO |Project Management Office (projektová kancelář) | ||
| - | |RPP |Registr práv a povinností. Základní registr agend, orgánů veřejné moci, soukromoprávních uživatelů údajů a některých práv a povinností. Slouží jako zdroj údajů pro informační systémy základních registrů při řízení přístupu uživatelů k údajům v jednotlivých registrech a agendových informačních systémech. | ||
| - | |KSVS | ||
| - | |TOGAF | ||
| - | |UML |Unified Modeling Language | ||
| - | |VS | ||
| - | |||
| - | Slovník pojmů | ||
| - | |||
| - | Tabulka 2: Slovník pojmů v této metodice | ||
| - | |||
| - | ^Pojem | ||
| - | |application | ||
| - | |best practice | ||
| - | |business | ||
| - | |capability | ||
| - | |enterprise | ||
| - | |layer | ||
| - | |motivation | ||
| - | |note | ||
| - | |performance | ||
| - | |refaktorování | ||
| - | |security | ||
| - | |stream | ||
| - | |tailoring | ||
| - | |top-down | ||
| - | |value | ||
| - | |prvek modelu | ||
| - | |element | ||
| - | |||