Kontrola a schválení dokumentu

Metodika Modelování

Název Datum zhotovení Zhotovitel Zpracoval za zhotovitele Verze Veřejná zakázka Smlouva Objednatel Počet stran

Metodika modelování MSK 14. 3. 2016 KPMG Česká republika, s.r.o. Tomáš Martinka 2.1 181/2015 Návrh architektury ICT kraje 111/2016/INF Moravskoslezský kraj 74

Kontrola a schválení dokumentu Provedené revize Verze 1.0 2.0 2.1

Autor Tomáš Martinka Tomáš Martinka Tomáš Martinka

Datum 29. 2. 2016 14. 3. 2016 14. 3. 2016

Revize První verze Metodiky modelování Vypořádání připomínek MSK Finální verze

Tento dokument byl zkontrolován 1. 2.

Kontrolu provedl/a Jan Voříšek, Tomáš Řehořek Jan Voříšek, Tomáš Řehořek

Datum kontroly 29. 2. 2016 14. 3. 2016

Tento dokument byl schválen 1. 2. 3.

Jméno Alois Slovák

Podpis

I

Datum schválení

Obsah 1

2

Úvod....................................................................................................................... 1 1.1

Účel dokumentu ................................................................................................ 1

1.2

Základní definice použitých pojmů ...................................................................... 1

1.3

Východiska pro návrh metodiky .......................................................................... 2

1.4

Návaznost na metodiku řízení architektury........................................................... 3

1.5

Návaznost na rámec TOGAF ............................................................................... 5

Modelovací jazyk ArchiMate 2.1 ................................................................................. 6 2.1

Obecné zásady modelovacího jazyka ArchiMate ................................................... 6

2.1.1 2.2

4

Definování elementů používaných v metamodelu architektury MSK ........................ 8

2.2.1

Elementy organizační (byznys) vrstvy ........................................................... 9

2.2.2

Elementy aplikační vrstvy .......................................................................... 11

2.2.3

Elementy technologické a infrastrukturní vrstvy ........................................... 13

2.2.4

Elementy motivačního rozšíření .................................................................. 14

2.2.5

Elementy implementačního a migračního rozšíření ....................................... 14

2.3

3

Rozšíření jazyka ArchiMate .......................................................................... 8

Definování vazeb používaných v metamodelu architektury MSK ........................... 15

2.3.1

Vazby motivačního rozšíření ....................................................................... 17

2.3.2

Vazby implementačního a migračního rozšíření ............................................ 17

Definování závazného Metamodelu .......................................................................... 18 3.1

Vysvětlení pojmu Metamodel ............................................................................ 18

3.2

Vymezení celkového metamodelu MSK .............................................................. 19

3.2.1

Zjednodušený metamodel.......................................................................... 19

3.2.2

Dílčí doménové metamodely ...................................................................... 21

3.2.3

Metamodely z rozšíření jazyka ArchiMate .................................................... 27

Vymezení převzatých hledisek ................................................................................. 28 4.1

Definice hlediska ............................................................................................. 28

4.2

Převzatá hlediska ............................................................................................ 29

4.2.1

Úvodní hledisko ........................................................................................ 31

4.2.2

Hledisko organizační ................................................................................. 32

4.2.3

Hledisko portfolia byznys funkcí ................................................................. 32

4.2.4

Hledisko kooperace byznys procesů ............................................................ 33

4.2.5

Hledisko aplikačního portfolia ..................................................................... 34

4.2.6

Hledisko aplikační ..................................................................................... 35 II

5

4.2.7

Hledisko spolupráce aplikací ...................................................................... 36

4.2.8

Hledisko využití aplikací ............................................................................. 36

4.2.9

Hledisko technologického portfolia ............................................................. 37

4.2.10

Hledisko technologické .............................................................................. 38

4.2.11

Hledisko využití technologie/infrastruktury .................................................. 39

4.2.12

Hledisko vrstev ......................................................................................... 40

4.2.13

Hledisko zainteresovaných stran................................................................. 41

4.2.14

Hledisko principů ...................................................................................... 41

4.2.15

Implementační a migrační hledisko............................................................. 42

Vysvětlení možného užití elementů na příkladech...................................................... 43 5.1

Příklady – Základní elementy ............................................................................ 43

5.1.1

Byznys vrstva ........................................................................................... 43

5.1.2

Aplikační vrstva ........................................................................................ 50

5.1.3

Technologická vrstva................................................................................. 53

5.1.4

Elementy motivačního rozšíření .................................................................. 56

5.1.5

Elementy migračního a implementačního rozšíření ....................................... 59

5.2

Příklady – Vazby .............................................................................................. 59

5.2.1

Kompozice ............................................................................................... 59

5.2.2

Agregace ................................................................................................. 60

5.2.3

Přiřazení .................................................................................................. 60

5.2.4

Realizace ................................................................................................. 61

5.2.5

Použité ze strany ...................................................................................... 61

5.2.6

Přístup ..................................................................................................... 61

5.2.7

Asociace .................................................................................................. 62

5.2.8

Spouštění ................................................................................................. 62

5.2.9

Tok ......................................................................................................... 62

5.2.10

Seskupení ................................................................................................ 63

5.2.11

Spojka ..................................................................................................... 63

5.2.12

Specializace.............................................................................................. 63

5.3

Příklady hledisek ............................................................................................. 64

5.3.1

Hledisko organizační ................................................................................. 64

5.3.2

Hledisko aplikací ....................................................................................... 65

5.3.3

Hledisko spolupráce aplikací ...................................................................... 65

5.3.4

Hledisko využití aplikací ............................................................................. 65 III

6

5.3.5

Hledisko technologické .............................................................................. 66

5.3.6

Hledisko využití infrastruktury .................................................................... 66

5.3.7

Hledisko vrstev ......................................................................................... 67

5.3.8

Implementační a migrační hledisko............................................................. 67

Seznam obrázků .................................................................................................... 68

IV

1 Úvod 1.1 Účel dokumentu Účelem tohoto dokumentu je stanovení základního rámce modelování v prostředí Moravskoslezského kraje (dále jen „MSK“). Dokument závazně definuje jednotlivé objekty, stanovuje základní metamodel a definuje převzatá hlediska.

1.2 Základní definice použitých pojmů V tabulce níže je uveden seznam všech důležitých pojmů používaných v této Metodice modelování. Úplný slovník pojmů je součástí rámce TOGAF.

1

Pojem ADM (The Architecture Development Method) Architektura

Doména architektury

Hledisko

Metamodel Metodika Model

Modelování Vrstva architektury Zainteresovaný subjekt (Stakeholder) Životní cyklus

Definice pojmu Je označení pro procesy popisující tvorbu architektury organizace.

1. Formální popis systému nebo jeho detailní plán na úrovni komponent vedoucí k jeho implementaci. 2. Struktura komponent a jejich vazeb včetně principů a návodů, které řídí návrh a rozvoj v čase. Jedná se o architektonické oblasti, které jsou předmětem zájmu. NA VS ČR člení domény na vertikální (např. architektura rizik a bezpečnosti, architektura výkonnosti, aj.) a horizontální (byznys, aplikační, technologická a infrastrukturní). Horizontální domény označujeme jako „Vrstvy architektury“ Definuje perspektivu, ze které je možné vidět pohled. Jedná se o specifikaci konvencí pro vytvoření a použití pohledu. Pohled je konkrétní diagram, Hledisko říká, jak má diagram vypadat a co má prezentovat uživateli. Model definující jakým způsobem bude architektura popsána. Definovaná a opakovatelná sada kroku pro vyřešení daného úkolu. Zaměřuje se na proces samotný, ale může obsahovat i definici požadovaného obsahu Model představuje účelově zjednodušenou reprezentaci předmětu zájmu. Model je nástrojem pro porozumění předmětu zájmu. V podnikové architektuře je předmětem zájmu podnik nebo jeho část. Účelem modelu je potom prezentovat ty aspekty podniku, které jsou podstatné z pohledu zainteresovaných subjektů. Modelování je proces, při kterém se vytváří model předmětu, vždy s ohledem na zamýšlené použití modelu. V rámci této metodiky rozeznáváme 4 základní vrstvy architektury a to organizační (byznys), aplikační, technologickou a infrastrukturní. Jednotlivec, tým nebo organizace, která má zájem na přínosu architektury. Časové období, které začíná okamžikem vzniku systému a končí okamžikem, od kdy již systém není k dispozici pro žádné využití.

1.3 Východiska pro návrh metodiky Navržená metodika vychází ze dvou základních pilířů používaných v oblasti návrhu moderní ICT Architektury: 

TOGAF – TOGAF je mezinárodně uznávaný rámec pro řízení tvorby Enterprise architektury ve společnostech využívajících prostředků informačních technologií. Původní koncept vznikl v USA, ale již více než deset let se používá po celém světě včetně České republiky.1

1

Oficiální dokumentace standardu TOGAF se nachází na adrese http://pubs.opengroup.org/architecture/togaf9doc/arch/index.html.

2



ArchiMate® - je nezávislý grafický modelovací jazyk. O jeho správu se stará konsorcium Open Group, které ArchiMate® vyhlásilo jako standard pro popis Enterprise architektury.2

1.4 Návaznost na metodiku řízení architektury Metodika řízení architektury představuje závazný a opakovatelný návod popisující relevantní procesy k danému životnímu cyklu architektury. Východiskem pro její návrh je například rámec TOGAF, respektive jeho část popisující procesy cyklu ADM. U těchto procesů se předpokládá, že bude upravována na míru dané organizaci. Říká nám, co tvoříme a kdy to tvoříme. Jinými slovy klade požadavek na vytvoření jednotlivých úrovní architektury (např. organizační (byznys) architektury, aplikační architektury a datové architektury) tj. výstupů relevantních pro každou její fázi. Výstup každé fáze musí být zaznamenaný. Aby došlo k snadnému porozumění, je potřeba definovat si společný komunikační prostředek neboli modelovací jazyk. Metodika modelování závazně definuje metodu znázornění architektury, protože říká, jak zaznamenat informaci. Vhodným kandidátem je modelovací jazyk ArchiMate. Ten je vymyšlen takovým způsobem, aby klíčové fáze TOGAF ADM cyklu tj.: fázi B (procení architekturu), fázi C (architekturu informačních systémů – datová a aplikační architektura) a fázi D (technologickou architekturu) dokázal znázornit. Některé oblasti TOGAF ADM cyklu nejsou v jazyce ArchiMate obsaženy. Je to pochopitelné, protože TOGAF je rámec a má mnohem širší záběr než ArchiMate, který je jazykem pro modelování architektury. Návaznost je schematicky znázorněna na obrázku níže (obrázek č. 1). Dále existuje Implementační a migrační oblast rozšíření ArchiMate, která koresponduje s TOGAF ADM fázemi. Jmenovitě se jedná o fázi E (příležitosti a řešení), fázi F (plánování migrace) a fázi G (zavedení řízení).

2

Obecné standardy pro modelování v jazyce ArchiMate jsou dostupné na adrese http://pubs.opengroup.org/architecture/archimate2-doc/.

3

Obrázek 1 Schématické znázornění vztahu TOGAF ADM cyklu na modelovací jazyk ArchiMate

4

1.5 Návaznost na rámec TOGAF V průběhu procesu tvorby architektury (TOGAF ADM) vznikají dodávané výstupy (orig. „deliverable“). Tyto výstupy jsou charakteristické tím, že jsou (smluvně) určené a následně formálně revidované, odsouhlasené a podepsané zodpovědným schvalovatelem. Výstupy představují výstupní produkty daného architektonického projektu a očekává se, že po dokončení projektu budou archivovány a/nebo převedeny do architektonického úložiště (orig. „repository“) jako referenční modely nebo jako záznamy daného stavu architektury v určitém časovém období. Artefakty a stavební bloky Každý z dodaných výstupů obsahuje alespoň jeden artefakt, reálně však několik. Artefaktem obecně značíme produkt architektonické práce zaměřený na jeden aspekt architektury. Rámec TOGAF rozeznává tři hlavní třídy artefaktů, kterými jsou:   

Katalogy – Představují seznamy stavebních bloků. Matice – Zobrazují závislosti mezi alespoň dvěma stavebními bloky architektury. Diagramy – Zobrazují stavební bloky a jejich vztahy a vzájemná spojení a to grafickým způsobem, který usnadňuje efektivní komunikaci vůči zainteresovaným stranám.

Výše uvedené třídy artefaktů popisují tzv. stavební bloky. Stavební bloky představují (potenciálně znovu-použitelné) byznysové komponenty, IT komponenty a architekturní schopnosti. Mohou být kombinovány s dalšími stavebními bloky za účelem dodání požadovaného architektonického řešení. Stavební bloky můžeme definovat na různých úrovních detailu. Tato Metodika modelování popisuje, jakým způsobem budou vytvářeny diagramy (viz Obrázek 2). Dodaný výstup architektury

Architektonické úložiště

Artefakty a stavební bloky

Znovu použitelné stavební bloky

Artefakty

Artefakty jsou

Katalogy

Katalogy

Matice

Matice

Diagramy

Diagramy

Popisují

Popisují

Stavební bloky

Stavební bloky

Ostatní dodané výstupy

Dodané výstupy architektury

Obrázek 2 Vysvětlení pojmů Dodaný výstup architektury, Artefakty a Stavební bloky.

5

2 Modelovací jazyk ArchiMate 2.1 2.1 Obecné zásady modelovacího jazyka ArchiMate Jazyk je složen ze základních stavebních kamenů, kterým se říká elementy. Elementy členíme do tří základních kategorií:   

aktivní, behaviorální a pasivní.

V tomto dělení můžeme shledat podobnost s přirozeným jazykem, kde aktivní struktury odpovídají podmětu, behaviorální slovesu a pasivní předmětu. Aktivní elementy jsou definovány jako elementy provádějící nějakou činnost (příklad: byznys aktéři, aplikační komponenty a zařízení). Behaviorální elementy jsou definovány jako jednotka činnosti prováděná jedním či více aktivními elementy (příklad: proces). Pasivní elementy jsou definované jako objekty, se kterými je prováděna nějaká činnost.

Obrázek 3 Podobnost s přirozeným jazykem

Struktury můžeme logicky rozčlenit do vrstev:   

procesní, aplikační, technologická,

Rozšíření jazyka ArchiMate pak přidalo další dvě speciální vrstvy:  

implementační a migrační, a motivační.

Tyto vrstvy jsou navázány na odpovídající fáze TOGAF cyklu ADM (viz kapitola č. 1.4). Na rozdíl od rámce TOGAF chybí datová vrstva, která je v ArchiMate rozložena do všech ostatních vrstev, což je pro použití v rámci modelování logičtější. Standard dále definuje, jaké vazby je možné mezi jednotlivými strukturami použít. Použití vazeb je definováno relativně striktně. Některé vazby jsou převzaty z jazyků UML a BPMN. K obecným zásadám modelovacího jazyka ArchiMate patří: 

Rozeznáváme tři základní vrstvy elementů, které jsou od sebe vždy odlišeny barevně. Pro všechny elementy spadající do jedné ze tří základních vrstev bude použita barevná konvence dle níže uvedené tabulky.

6

Název vrstvy Organizační (Byznys) vrstva

Používaná barva Žlutá

Aplikační vrstva

Tyrkysová

Technologická vrstva

Zelená

Ukázka

Tabulka 1 Definování barevné konvence



Rozlišováním jednotlivých vrstev se též rozumí i jejich vhodné uspořádání (respektive seskupení) a to ve stejném pořadí, jak je uvedeno v tabulce č. 1 (od organizační až po technologickou vrstvu). Jednotlivé elementy pohledů pak mohou být vertikálně (shora dolů) snadno propojeny logickými vazbami. K seskupení je vhodné použít pomocný element zvaný skupina. Příklad je znázorněn na obrázku níže.

Obrázek 4 Znázornění vhodného seskupení elementů jednotlivých vrstev.

7

2.1.1 Rozšíření jazyka ArchiMate Jazyk ArchiMate dlouhou dobu disponoval pouze elementy pokrývajícími klíčové fáze cyklu ADM. Na obrázku č. 1 značeno jako „jádro ArchiMate“. Protože i ostatní fáze cyklu ADM představují nezanedbatelné činnosti vývoje architektury, byl jazyk ArchiMate rozšířen dvěma významnými rozšířeními:  

Motivační rozšíření Implementační rozšíření

Motivační rozšíření Motivační rozšíření přidává motivační koncepty, které stojí za záměry a působením každé organizace. Slouží k vyjádření jakým způsobem je architektura organizace spjata s „kontextem“, s motivací ke změně architektury. Příkladem lze zmínit cíle, principy a požadavky na architekturu. Jak je patrno z obrázku č. 1 Motivační rozšíření má své uplatnění v počátečních fázích cyklu ADM. V rámci těchto fází se řeší „high-level“ cíle organizace, architektonické principy a výchozí požadavky ze strany byznysu. Převzaté elementy z Motivačního rozšíření jsou představeny v kapitole č. 2.2.4. Implementační a migrační rozšíření Jak naznačuje název, implementační a migrační rozšíření je vztaženo k posledním, neméně významným fázím ADM cyklu (viz obrázek č. 1), které jsou spjaty s implementací, migrací a governance architektury. Rozšíření přidává skupinu elementů umožňující zaznačit způsob implementace změn, případně projektů. Obsahuje tedy koncepty pro:   

podporu modelování implementace programů a projektů, podporu programového, portfolio a projektového managementu, podporu plánování migrací.

Převzaté elementy z Motivačního rozšíření jsou představeny v kapitole č. 2.2.5.

2.2 Definování elementů používaných v metamodelu architektury MSK V rámci definovaného metamodelu architektury MSK budou ze specifikace ArchiMate 2.1 převzaty níže uvedené elementy. Jedná se o všechny základní elementy z jádra ArchiMate a o všechny elementy motivačního a implementačního rozšíření. Pro každý element je stanoven jeho název (včetně anglického ekvivalentu), popis a symbol použitý ke korektnímu znázornění.

8

2.2.1 Elementy organizační (byznys) vrstvy V tabulkách uvedených níže jsou popsány převzaté elementy ze specifikace ArchiMate 2.1 patřící do organizační (byznys) vrstvy. Elementy jsou seskupeny dle kategorií (aktivní, behaviorální a pasivní). Byly převzaty veškeré elementy z organizační (byznys) vrstvy. Pojem Elementy Účastník, aktér/ aktivní Business Actor struktury

Spolupráce/ Business Collaboration

Popis Symbol Účastník je definován jako organizační jednotka schopna vykonávat aktivitu přiřazenou k jedné nebo více byznys rolím. Zodpovědnost za vykonávání specifického chování, ke které může být přiřazen účastník procesu. Spojení dvou a více rolí pracující společně k vykonání určitého kolektivního chování.

Rozhraní/ Business Interface

Přístupový bod, kde je procesní služba dostupná okolnímu prostředí.

Lokalita, místo/ Location

Místo v prostoru, kde se nacházejí aktéři nebo kde je vykonáváno chování

Role / Business Role

9

Pojem Elementy Proces/ chování Business Process Funkce/ Business Function Interakce/ Business Interaction

Popis Symbol Element chování, který sdružuje skupiny chování na základě pořadí činností. Je určen k produkování sady produktů nebo byznys služeb. Element chování, který seskupuje chování podle vybraná sady kritérií (typicky požadovaných dovedností, znalostí, zdrojů. Element chování, který popisuje chování spolupráce.

Událost/ Business Event

Něco co se stává (interně nebo externě) a ovlivňuje chování.

(Byznys) služba/ Business Service

Byznys služba je definována jako služba, která naplňuje potřeby zákazníka (interního nebo externího vůči poskytující organizaci).

10

Pojem Elementy Objekt/ pasivní Business struktury Object

Popis Symbol Pasivní element, který má relevanci z předmětného pohledu.

Reprezentace/ Smyslově Representation informací objektem

vnímatelná forma spojených s byznys

Význam/ Meaning

Znalost nebo odbornost přítomná v byznys objektu nebo v jeho reprezentaci

Kontrakt/ Contract

Formální nebo neformální specifikace dohody, která specifikuje práva a povinnosti spojené s produktem. Hodnota představuje přínos, užitek nebo důležitost produktu či služby

Hodnota/ Value

Produkt/ Product

Produkt je soubor služeb definovaných kontraktem (zákonem), které jsou společně poskytovány klientovi (pro jeho životní situaci).

2.2.2 Elementy aplikační vrstvy V tabulkách uvedených níže jsou popsány převzaté elementy ze specifikace ArchiMate 2.1 patřící do aplikační vrstvy. Elementy jsou seskupeny dle kategorií (aktivní, behaviorální a pasivní). Byly převzaty veškeré elementy z aplikační vrstvy. Pojem Elementy Komponenta aktivní aplikace/ struktury Application Component Spolupráce/ Application Collaboration Rozhraní aplikace/ Application Interface

Popis Symbol Modulární, nasaditelná a nahraditelná část softwarového systému, zapouzdřující své chování a data, které poskytuje skrz sadu rozhraní. Souhrn dvou nebo více komponent aplikací, které pracují společně za účelem vykonání kolektivního chování Přístupový bod, ve kterém je služba aplikace dostupná pro využití uživatelem nebo jinou komponentou aplikace

11

Pojem Popis Symbol Elementy Funkce Aplikační funkce je definována jako chování aplikace/ interní chování jedné aplikační Application komponenty. Function Interakce Element chování, který popisuje aplikace/ chování aplikací při jejich kooperaci. Application Interaction Služba Služba, která poskytuje aplikace/ automatizované chování Application Service

Pojem Elementy Datový pasivní objekt/ struktury Data Object

Popis Symbol Pasivní element, který je zpracováván za použití výpočetní techniky.

12

2.2.3 Elementy technologické a infrastrukturní vrstvy V tabulkách uvedených níže jsou popsány převzaté elementy ze specifikace ArchiMate 2.1 patřící do technologické vrstvy. Elementy jsou seskupeny dle kategorií (aktivní, behaviorální a pasivní). Byly převzaty veškeré elementy z technologické vrstvy. Pojem Elementy Uzel/ aktivní Node struktury

Síť/ Network

Popis Symbol Výpočetní zdroj, na kterém mohou být skladovány, dislokovány nebo zpracovávány artefakty pro použití. Poskytuje především služby výpočetního výkonu a datových kapacit. Komunikační medium mezi dvěma nebo více zařízeními.

Cesta/ Communication Path

Spojení mezi dvěma nebo více uzly, skrz které si mohou tyto uzly vyměňovat data.

Zařízení/ Device

Hardwarový zdroj, na kterém mohou být skladovány nebo dislokovány artefakty pro použití.

Systémový software/ Systém Software

Softwarové prostředí pro speciální typ komponentů a objektů, které jsou na něm rozmístěny ve formě artefaktů. Přístupový bod, kde služby infrastruktury nabízené uzlem mohou být využity jiným uzlem nebo komponentou aplikace.

Rozhraní infrastruktury/ Infrastructure Interface

Pojem Elementy Infrastrukturní chování funkce/ Infrastructure function Služby infrastruktury/ Infrastructure Service

Popis Symbol Infrastrukturní funkce je definována jako element chování, který může být vykonávaný uzlem. Externě viditelná jednotka funkcionality poskytovaná jedním nebo více uzly, která je přístupná přes dobře definované rozhraní a má význam pro okolí.

13

Pojem Elementy Artefakt/ pasivní Artifact struktury

Popis Symbol Artefaktem se rozumí fyzická reprezentace dat, která je používána či vytvářena systémem.

2.2.4 Elementy motivačního rozšíření V tabulce uvedené níže jsou popsány převzaté elementy ze specifikace ArchiMate 2.1 nově zavedené motivačním rozšířením. Do této metodiky byly převzaty veškeré elementy z motivačního rozšíření. Pojem Popis Symbol Zainteresovaný Zainteresovaný jedinec, tým nebo organizace, subjekt/ která má zájem na přínosu architektury. Stakeholder Motivátor/ Driver

Motivátor je definován jako okolnost, která vytváří, motivuje a podporuje změnu v organizaci.

Zhodnocení/ Assesment

Výsledek analýzy motivátoru.

Cíl/ Goal

Koncový stav, kterého chce zainteresovaný subjekt (stakeholder) dosáhnout.

Požadavek/ Requirement

Stanovisko, formálně vyjádřená potřeba, která musí být v systému (resp. architekturou) realizována. Jedná se o architektonické nikoli byznysové požadavky.

Omezení/ Constraint

Omezení na cestě k realizaci systému.

Princip/ Principle

Normovaná vlastnost všech systémů v daném kontextu, nebo způsob jejich realizace. Principy vycházejí ze strategických cílů a svými důsledky formují a formulují architektonické požadavky.

2.2.5 Elementy implementačního a migračního rozšíření V tabulce uvedené níže jsou popsány převzaté elementy ze specifikace ArchiMate 2.1 nově zavedené implementačním a migračním rozšířením. Do této metodiky byly převzaty veškeré elementy z implementačního a motivačního rozšíření. 14

Pojem Pracovní blok/ Work Package

Popis Symbol Série akcí navržená tak, aby dosáhla vytyčeného cíle ve specifikovaném čase.

Dodaný výstup/ Deliverable

Přesně definovaný výsledek pracovního bloku.

Stav architektury/ Plateau

Relativně stabilní stav architektury, která existuje (existovala) během omezeného časového období.

Rozdíl/ Gap

Rozdíl je napojený na dva stavy architektury (např. výchozí a cílovou nebo dvě přechodové) a tudíž představuje znázornění rozdílů mezi těmito dvěma stavy architektury.

2.3 Definování vazeb používaných v metamodelu architektury MSK V rámci definovaného metamodelu architektury MSK budou ze specifikace ArchiMate 2.1 převzaty níže uvedené vazby. Vazby jsou převzaty v plném a nezměněném rozsahu ze standardní specifikace ArchiMate 2.1. Rozeznáváme základní 3 typy vazeb a to: Strukturní vazby, Dynamické vazby a Ostatní vazby.

15

Pojem Strukturní Asociace/ vazby Association

Popis Symbol Asociace vztahů modelů, které nejsou popsatelné jiným, konkrétnější vztahem. Přístup/ Přístupová vazba modeluje přístup Access prvků chování k procesním a datovým objektům. Použité ze Použití služeb procesy, funkcemi, nebo strany/ interakcí a přístupem k rozhraní Used by rolemi, komponentami nebo spoluprací. Realizace/ Vztah realizace spojuje logickou entitu Realization s více konkrétní entitou, která ji realizuje. Přiřazení/ Vztah přiřazení spojuje prvky chování Assignment s aktivními elementy (např. role, komponenty), které je provádějí nebo role s účastníky, kteří je plní. Agregace/ Vztah agregace značí, že objekt Aggregation seskupuje určitý počet jiných objektů. To tedy znamená, že objekt může být seskupen současně i do více celků a tudíž o své existenci rozhoduje sám (nezaniká se zánikem seskupení).

Pozn.: Alternativně lze vyjádřit vkládáním elementů do sebe. Kompozice/ Composition

Vztah kompozice značí, že objekt je složen z jednoho nebo více jiných objektů. To tedy znamená, že objekt je součástí pouze jediného celku a tudíž zaniká spolu se zánikem celku.

Pozn.: Alternativně lze vyjádřit vkládáním elementů do sebe. Pojem Dynamické Tok/ vazby Flow Spouštění/ Triggering

Popis Symbol Vztah tok popisuje výměnu nebo transfer např. informace nebo hodnotu mezi procesy, funkcemi, interakcemi a událostmi. Vztah spouštění popisuje časové nebo příčinné vztahy mezi procesy, funkcemi, interakcemi a událostmi.

16

Ostatní vazby

Pojem Seskupení/ Group

Popis Symbol Vztah seskupení značí, že stejné nebo rozdílné objekty jsou seskupeny podle nějaké společné charakteristiky.

Spojka/ Junction Specializace/ Specialization

Spojka se používá ke spojení vztahů stejného typu. Vztah specializace značí, že objekt je specializací jiného objektu.

2.3.1 Vazby motivačního rozšíření Vazby motivačního rozšíření vycházejí ze standardních vazeb popsaných v kapitole č. 2.3. Protože se některé svým významem mohou mírně lišit, uvádíme v rámci této kapitoly jejich plný výčet. Pojem Asociace/ Association

Popis Symbol Asociace modeluje vztah nějakého záměru s jeho zdrojem či příčinou.

Agregace/ Aggregation

Agregace modeluje, že se jeden záměr skládá z několika menších záměrů.

Realizace/ Realization

Vliv/ Influence

Alternativně lze vyjádřit vkládáním elementů do sebe. Vazba vyjadřuje, že je záměr realizován nějakým prostředkem. 1. Cíl (záměr) je realizován principem, omezením či požadavkem (prostředek). 2. Princip (záměr) je realizován omezením či požadavkem (prostředek). 3. Požadavek (záměr) je realizován systémem (prostředkem).3 Vazba modeluje, že nějaký motivační element má pozitivní, nebo negativní vliv na realizaci dalšího motivačního elementu. Jedná se o převzatou vazbu znázorňující „tok vlivu“. K šipce lze připojit atribut značící směr a sílu vlivu např.: {++,+,0,-,--} nebo [0..10]. Pozn.: Výběr stylu záznamu je ponechán na uživatelích.

2.3.2 Vazby implementačního a migračního rozšíření V rámci Implementačního a migračního rozšíření nevznikla potřeba upravovat či vytvářet nové vazby. Používají se vazby uvedené v kapitole č. 2.3. 17

3 Definování závazného Metamodelu Kapitola definuje několik základních převzatých metamodelů z jazyka ArchiMate 2.1 pro účely modelování architektury kraje.

3.1 Vysvětlení pojmu Metamodel Dle definice uvedené v rámci TOGAF se metamodelem rozumí: „Model definující jakým způsobem bude architektura popsána.“ Jak již bylo naznačeno v předchozím textu klíčovým předpokladem pro znázornění určité reality (tj. vytvoření modelu) je domluva na společném komunikačním prostředku – modelovacím jazyce. Vhodným kandidátem je modelovací jazyk ArchiMate. Jazyk ArchiMate se skládá z elementů a vazeb, ty které byly přezvány touto metodikou, jsou popsány v kapitolách č. 1.5 a č. 2.3. Jejich vzájemný vztah je popsán metamodelem. Jinými slovy můžeme říci, že metamodel je předpis a logika používání daného jazyka pro modelování architektury v praxi. Pro účely tvorby architektury MSK budou vytvářeny modely v jazyce ArchiMate podle předem schváleného metamodelu. Přičemž, metamodel nemusí být jen jeden, viz dále. Užití Metamodelu je plně v souladu se specifikacemi jazyka ArchiMate a architektonického rámce TOGAF. Metamodel architektury jednoznačně definuje jaké elementy z jazyka ArchiMate a jaké vazby mezi nimi, jsou použity. V rámci této Metodiky modelování rozeznáváme několik metamodelů lišící se především jejich rozsahem a jejich zamýšleným použitím. 

 

 

Celkový metamodel jazyka ArchiMate 2.1 – Představuje výčet všech elementů, jejich vazeb a definuje, jakým způsobem budou použity. Tento metamodel je příliš komplexní, a proto byl zredukován do celkového metamodelu této metodiky. Celkový metamodel této metodiky – Představuje výčet všech elementů a jejich vazeb, které byly převzaty z celkové specifikace jazyka ArchiMate ve verzi 2.1. Doménové metamodely – Doménové metamodely popisují určitou zájmovou oblast. Rámec TOGAF rozeznává 4 základní domény architektury: byznys architektura, architektura dat, architektura aplikací a technologická architektura. Proto byl vytvořen metamodel pro každou ze zmíněných domén architektury. V kontextu NA VS ČR se jedná o označení „vrstva“, protože pojem „doména“ je chápán obecněji (kromě horizontálních domén souhrnně označovaných jako vrstvy, zahrnuje NA VS ČR i vertikální domény, které mají svůj původ v dalších rámcích). Metamodely popisující rozšíření – Rozšíření jazyka přidalo ještě dva metamodely popisující jednotlivá rozšíření. Hlediska – Nezanedbatelnou součástí jazyka ArchiMate jsou hlediska. Ta definují perspektivu, ze které je možné vidět pohled, podle toho, jaký zájem na modelu má zainteresovaný, pro něhož je pohled vytvořen. Jedná se o specifikaci konvencí pro vytvoření a použití pohledu. Pohled je konkrétní diagram, graficky představující část modelu. Hledisko říká, jak má diagram vypadat a co má prezentovat uživateli (jedná se tedy o jistou formu metamodelu). Hlediska jsou blíže popsána v kapitole č. 4.

18

Shrnutí:  

Metamodel je abstraktním modelem, důležitým pro správné zachycení a zvýraznění objektů a vazeb v modelu úřadu (co a jak modelovat), Metamodel podporuje určitou metodu nebo konkrétní postup tvorby modelů (předepisuje modelovací jazyk, použité elementy a možné vazby).

3.2 Vymezení celkového metamodelu MSK Pro účely sestavení metamodelu architektury MSK byly převzata pouze níže uvedená část z celkové specifikace ArchiMate 2.1.4   

Výčet a představení převzatých elementů je závazně stanoven v kapitole č 2.2. Výčet a představení převzatých vazeb je závazně stanoven v kapitole č 2.3. Výčet a představení převzatých hledisek je závazně stanoven v kapitole č. 4.

3.2.1 Zjednodušený metamodel Celkový metamodel definující architekturu MSK obsahuje značné množství vazeb. Pro přehlednost a lepší pochopení je na obrázku č. 5 schematicky znázorněn zjednodušený metamodel. Z úplného metamodelu byly vybrány pouze nejzásadnější vazby. Přestože modelovací jazyk ArchiMate rozeznává tři vrstvy elementů tj. Organizační, Aplikační a Technologická, v uvedeném metamodelu jsou používány čtyři. Metamodel vychází z poznatků českého eGovernmentu, který definoval čtyřvrstvou architekturu:    

Organizační (byznys), Aplikační, Technologická, Infrastrukturní.

K znázornění Infrastrukturní vrstvy se použijí elementy Technologické vrstvy, hovoříme o tzv. specializaci. Pro lepší odlišení Technologické a Infrastrukturní vrstvy je dále doporučeno používání jiných odstínů zelené barvy, tak jak je naznačeno na obrázku č. 5. Toto doporučení není v rozporu s navrhovaným principem barevné konvence jazyka ArchiMate (viz kapitola č. 2.1).

4

Teprve praktická zkušenost ukáže, zda není výhodné některé objekty metamodelu pro zjednodušení zakázat a jiné specializací původních doplnit.

19

Obrázek 5 Zjednodušený metamodel kraje

20

3.2.2 Dílčí doménové metamodely Podle TOGAFu rozeznáváme 4 dílčí doménové metamodely, které slouží ke znázornění jednotlivých oblastí architektury dle následujícího členění: 1) 2) 3) 4)

Organizační (Byznys) architektura (BA). Architektura dat (AD). Architektura aplikací (AA). Technologická architektura (TA).

Pozn.: Byznys architektura je v prostředí MSK označována jako Organizační architektura. Tento pojem bude upřednostňován z důvodu zažité terminologie a snazšího pochopení ze strany pracovníků MSK. Jazyk ArchiMate disponuje pouze 3 základními vrstvami, kterými jsou:   

Organizační (byznys) vrstva5, Aplikační vrstva a Technologická vrstva.

Nemá tedy vlastní vrstvu pro architekturu dat. Její objekty jsou rozloženy napříč všemi základními vrstvami. Toto uspořádání je logičtější. Pro představu vztah mezi členěním architektury a základními vrstvami jazyka ArchiMate je znázorněn následující tabulkou.

Byznys vrstva Vrstvy dle Aplikační vrstva ArchiMate Technologická vrstva

Aktivní BA AA TA

Kategorizace elementů Chování Pasivní BA BA, AD AA AD TA AD

Specializací poslední, tj. technologické vrstvy, vzniká vrstva infrastrukturní. Je tak naplněn princip čtyřvrstvé architektury, který je MSK převzat z NA VS ČR. V prostředí MSK tedy hovoříme o:    

5

Organizační (Byznys) vrstvě, Aplikační vrstvě, Technologické vrstvě a Infrastrukturní vrstvě,

Někdy se setkáváme i s označením „Procesní vrstva“.

21

3.2.2.1 Metamodel organizační (byznys) architektury V rámci této kapitoly je definován metamodel organizační architektury a to jak v plné, tak i redukované verzi. Plná verze metamodelu organizační architektury

Obrázek 6 Plná verze metamodelu organizační architektury

Redukovaný metamodel organizační architektury

Obrázek 7 Redukovaná verze metamodelu organizační architektury

22

3.2.2.2 Metamodel architektury dat Datová architektura dle TOGAF v notaci ArchiMate nemá vlastní vrstvu, její objekty jsou rozloženy ve všech třech vrstvách. Představují pasivní prvky, tedy o čem jsou systémy, s čím zachází. Vždy se jedná o tři úrovně abstrakce. Zatímco datové modelování hovoří o konceptuálních, logických a fyzických datových objektech, TOGAF hovoří o datových entitách, logických a fyzických informačních komponentách, používá ArchiMate vyjádření na obrázku č. 8.

Obrázek 8 Znázornění metamodel datové architektury v jazyce ArchiMate

Objekt korporace představuje všechny věci, které v prostředí korporace (resp. MSK) prostě jsou. A některé z nich jsou pro nás zajímavé do té míry, že si o nich vedeme datové záznamy. Datový objekt je logickým obrazem skutečného objektu, promítnutého do vrstvy informačních systémů. Datový artefakt, tedy soubor, tabulka, záznam na disku je fyzickou reprezentací dat o objektu. Artefakt je také používán jako fyzická reprezentace SW, ať již aplikační komponenty nebo systémového SW.

23

3.2.2.3 Metamodel architektury aplikací V rámci této kapitoly je definován metamodel architektury aplikací a to jak v plné, tak i redukované verzi. Plný metamodel architektury aplikací

Obrázek 9 Metamodel architektury aplikací v plném rozsahu

Zjednodušený metamodel architektury aplikací

Obrázek 10 Zjednodušený metamodel aplikací

24

Příklad možného rozšíření Dále je demonstrován příklad možného rozšíření metamodelu architektury a to s využitím specializace elementů, v tomto případě aplikační komponenty a aplikačního rozhraní.

Obrázek 11 Příklad možného rozšíření metamodelu architektury aplikací využitím specializace objektů

25

3.2.2.4 Metamodel technologické architektury V rámci této kapitoly je definován zjednodušený metamodel technologické architektury.

Obrázek 12 Metamodel technologické architektury

Metamodel komunikační infrastruktury je totožný jako metamodel jakékoli ostatní ICT technologické infrastruktury, v architektonických výstupech bude převážně představovat samostatný pohled. Pokud bude potřeba zdůraznit na úrovni metamodelu odlišnost komunikační infrastruktury, budou všechny použité koncepty metamodelu tzv. specializovány, viz obr níže.

Obrázek 13 Znázornění možné specializace elementů technologické vrstvy

26

3.2.3 Metamodely z rozšíření jazyka ArchiMate V následující kapitole jsou popsány převzaté metamodely vycházející z Implementačního a migračního a Motivačního rozšíření jazyka ArchiMate 2.1. 3.2.3.1 Metamodel implementačního a migračního rozšíření Na obrázku níže je znázorněn metamodel implementačního a migračního rozšíření (viz obrázek č. 14). Konceptuálně je Program/projekt/balíček práce obdobný jako byznys proces v tom, že se skládá ze souvisejících úkolů mající stejný cíl. Nicméně program/projekt/balíček je „jednorázový“ (resp. unikátní) proces. A přesto jej můžeme popsat velmi obdobným způsobem, jak je tomu i u procesů.

Obrázek 14 Metamodel implementačního a migračního rozšíření

3.2.3.2 Motivační metamodel Metamodel neobsahuje všechny možné vazby, protože každý element v motivačním rozlišení může být agregací/specializací elementu stejného typu (např. cíl se může agregovat na dílčí cíle).

Obrázek 15 Motivační metamodel

27

4 Vymezení převzatých hledisek V rámci této kapitoly jsou závazně definována hlediska, která budou z doporučení úplné specifikace ArchiMate 2.1 a z metodiky NA VS ČR převzata.

4.1 Definice hlediska Hlediska vycházejí z myšlenky, že existuje několik skupin zainteresovaných lidí, kteří potřebují ke své práci pouze určitý typ informací a různou míru detailu. Kdyby jich bylo prezentováno více, model by se pro ně stával nepřehledným až nečitelným, případně nedisponují potřebnými znalostmi pro pochopení přílišného detailu. Dle definice uvedené v rámci TOGAF se hlediskem rozumí:

„Hledisko definuje perspektivu, ze které je možné vidět pohled. Jedná se o specifikaci konvencí pro vytvoření a použití pohledu. Pohled je konkrétní diagram, Hledisko říká, jak má diagram vypadat a co má prezentovat uživateli.“ Tuto definici hezky doplňuje obrázek znázorněný níže (Obrázek 16).

Obrázek 16 Klasifikace hledisek dle jazyka ArchiMate

Každé hledisko je tedy určeno jiné skupině zainteresovaných osob (též „stakeholderů“) a může sloužit k odlišným účelům. Z definice vyplývá, že hledisko je vlastně určitým dílčím metamodelem (má definovanou množinu relevantních elementů a jejich vzájemných vazeb). V dalších kapitolách proto budou vymezena použitá hlediska a stanoveny role zodpovědné za daná hlediska.

28

4.2 Převzatá hlediska Jazyk ArchiMate 2.1 definuje jakožto příklady možných hledisek celkem 18 základních hledisek a 9 hledisek patřících pod motivační a implementační rozšíření. Pro potřeby MSK bylo převzato 12 nejpoužívanějších konkrétních hledisek, která byla vybrána s ohledem na jejich praktické využití. Vedle toho se ve specifikaci ArchiMate 2.1 uvádí obecné hledisko představující grafické vyjádření matic a klasifikací architektury, zvané hledisko přehledové (krajinné) mapy6. V Národním architektonickém rámci (NAR) architektury VS ČR je toto obecné doporučení rozpracováno pro každou z vrstev byznys, aplikační a technologické architektury. Tyto tzv. Mapy portfolia jsou nositeli grafického vyjádření klasifikace a topologie (rozmístění) prvků architektury v tzv. Referenčních modelech. Pro NA VS ČR se jako základní hlediska vedle portfoliových map považují vždy dvojice hledisek, hledisko vnitřní struktury a hledisko vnějších služeb. Zatímco první hledisko se soustředí na modelování vnitřního fungování úřadu, jeho aplikací a technologií, druhé hledisko se zaměřuje na užití těchto funkcí pomocí služeb pro konkrétní příjemce. Z praktických důvodů přidává NAR v byznys vrstvě ještě hledisko organizační, ve vrstvě architektur IS hledisko struktury informací a hledisko spolupráce aplikací (komunikace, integrace). V případě potřeby umožňuje NAR využít doporučená ArchiMate hlediska v motivační a implementační oblasti. Z důvodu podpory strategie vize tzv. čtyřvrstvé architektury přidává NAR ještě hlediska komunikační infrastruktury, tj. pohledy zaměřené na ty prvky infrastruktury, které stojí vně technologických (datových) center a umožňují jejich vzájemné propojení a připojení na sdílené služby eGovernmentu KIVS/CMS. Z hlediska metamodelu a definic jsou pro tyto pohledy přiměřeně využity tytéž prostředky infrastrukturní (zelené) vrstvy jazyka ArchiMate. Proto že se následně v modelech individuálních architektur použijí dvakrát, pro IT technologie a pro komunikační infrastrukturu, není třeba i jejich definice zdvojovat.

6

Z angl. Landscape Map Viewpoint

29

Převzatá základní hlediska

ID

Název

1

Úvodní hledisko

2

Hledisko organizační Hledisko kooperace byznys procesů Hledisko aplikační

3 4 5 6 7 8 9

Hledisko spolupráce aplikací Hledisko využití aplikací Hledisko technologické Hledisko využití technologie/infras truktury Hledisko vrstev

Anglický ekvivalent Introductory viewpoint

Stručný popis

Organization viewpoint Business process co-operation viewpoint. Application Behaviour Viewpoint Application cooperation viewpoint Application Usage Viewpoint Infrastructure Viewpoint Infrastructure Usage Viewpoint Layered viewpoint

30

Obsahuje všechny prvky jazyka v podobě zjednodušené grafické notace. Používá se především pro hrubý návrh, kdy ještě nejsou k dispozici informace potřebné pro detailní popis podnikové architektury. Zabývá se organizačním uspořádáním podniku nebo jeho části Zachycuje vztahy mezi procesy a jejich okolím Zachycuje vnitřní aktivity aplikací a služby, které poskytují svému okolí Popisuje vztahy a informační toky mezi aplikacemi Popisuje, jakým způsobem aplikace podporují podnikové procesy a ostatní aplikace. Zobrazuje softwarové a hardwarové prostředky organizace Zachycuje, jak aplikace využívají SW a HW technologie/infrastrukturu. Využívá všechny vrstvy a elementy pro komplexní pohled na podnikovou architekturu

Hlediska převzatá z rozšíření Hlediska doplněná z NAR VS ČR

ID

Název

Anglický ekvivalent Stakeholder Viewpoint

Stručný popis

10

Hledisko zainteresovaných subjektů

11

Hledisko principů

Principles Viewpoint

12

Hledisko implementační a migrační

Implementation and Migration Viewpoint

13

Mapa portfolia byznys funkcí

Landscape Map

14

Mapa aplikačního portfolia

Landscape Map

15

Mapa technologického portfolia / infrastrukturního portfolia

Landscape Map

Umožňuje analytikovy zachytit zainteresované subjekty (tzv. stakeholdery), interní a externí motivátory ke změně a jejich zhodnocení. Umožňuje zachytit pohromadě všechny principy navrhované architektury pospolu s cíli, kterými jsou tyto principy ovlivněny (pozitivně, či negativně). Účelem tohoto hlediska je dát do souvislosti programy a projekty k částem architektury, které implementují. Účelem tohoto hlediska je představit dekompozici a klasifikaci všech byznys funkcí (procesů nebo služeb) krajské korporace, jeho typových segmentových organizací a KÚ. Účelem tohoto hlediska je představit dekompozici a klasifikaci všech aplikační komponent (funkcí nebo služeb) krajské korporace, jeho typových segmentových organizací a KÚ. Účelem tohoto hlediska je představit dekompozici a klasifikaci všech technologických komponent (funkcí nebo služeb) krajské korporace, jeho typových segmentových organizací a KÚ. Hledisko může být v případě potřeby specializováno za účelem vytvoření infrastrukturního portfolia.

4.2.1 Úvodní hledisko Obsahuje všechny prvky jazyka v podobě zjednodušené grafické notace. Používá se především pro hrubý návrh, kdy ještě nejsou k dispozici informace potřebné pro detailní popis podnikové architektury. Lze jej tedy použít k velmi detailnímu až velmi obecnému hrubému návrhu, který je určen pro všechny zainteresované strany (viz obrázek vlevo).

31

Metamodel tohoto hlediska může vypadat například následovně:

Obrázek 17 Příklad možného znázornění úvodního hlediska

4.2.2 Hledisko organizační Organizační hledisko slouží ke znázornění (interní) organizační struktury organizace případně některé z jeho nižších organizačních jednotek. Rovněž jej můžeme použít ke znázornění sítě organizací (např. zřizovatel a organizační složky, příspěvkové organizace atp.). Zejména u tohoto hlediska se doporučuje jednotlivé elementy vkládat do sebe. Čtenář tak obdrží přehlednou a velmi intuitivní organizační strukturu. Mírou detailu se jedná o vazební hledisko určené pro všechny zájmové skupiny (viz obr. vlevo). Doporučený metamodel organizačního hlediska:

Obrázek 18 Doporučený metamodel organizačního hlediska

4.2.3 Hledisko portfolia byznys funkcí Základem obsahu tohoto pohledu je třístupňová klasifikace všech prvků byznys architektury. S trochou nepřesnosti je možné říci, že jak byznys role, jejich funkce, procesy a jejich služby a s nimi spojené objekty VS lze jednoznačně klasifikovat, tj. každou zařadit právě do jedné z byznys kategorií. 32

Pro vyjádření klasifikace a její topologie je v modelech doporučeno používat objekt „Skupina“. Za nevhodné se považuje používat pro úrovně klasifikace objekty vyhrazené skutečně jsoucím prvkům architektury (byznys funkce, procesy nebo služby). Vlastní model individuální architektury úřadu se tím ale stává nekonzistentním, neboť jsou v něm v jednom seznamu uvedeny prvky modelu, které skutečně jsou a jiné, které je jenom virtuálně zastupují v klasifikaci. Nad takovým modelem se pak nedá rozumně automatizovaně o architektuře reportovat. Uvnitř tzv. byznys kategorie již je možné objekty dále hierarchizovat (například funkce, procesy a služby), pokud se dá říci, že každý takový objekt v realitě existuje, byť je komponován z řady další. Například musí mít zodpovědnou osobu a další atributy. Dílčí metamodel je znázorněn na obrázku níže:

Obrázek 19 Doporučený metamodel hlediska portfolia byznys funkcí

4.2.4 Hledisko kooperace byznys procesů Hledisko kooperace byznys procesů slouží ke znázornění vztahu jednoho či více byznys procesů vůči ostatním procesům případně jejich prostředím. Jednak může být použito k vytvoření vysokoúrovňovému znázornění byznys procesů spolu s nezbytným kontextem za účelem tvorby těchto procesů, rovněž může sloužit i jako nezbytná prezentační pomůcka pro provozní manažery, kterým poskýtá nezbytný přehled závislostí jim řízených procesů (viz obr. vlevo).

33

Dílčí metamodel je znázorněn na obrázku níže:

Obrázek 20 Doporučený metamodel hlediska kooperace byznys procesů

4.2.5 Hledisko aplikačního portfolia Základem obsahu tohoto hlediska je třístupňová klasifikace základních prvků aplikační architektury. Jde o stejné členění jako v případě mapy portfolia funkcí veřejné správy, tzn., že jak aplikační komponenty, jejich funkce, jejich služby a s nimi spojené datové objekty lze jednoznačně klasifikovat, tj. každý zařadit právě do jedné z aplikačních kategorií. Ve schématu je naznačeno doporučení používat pro vyjádření klasifikace a její topologie v modelech objekt „Skupina“. Tato metodika považuje za nevhodné, používat pro úrovně klasifikace objekty vyhrazené skutečně jsoucím prvkům architektury (byznys funkce, procesy nebo služby). Vlastní model architektury se tím ale stává nekonzistentním, neboť jsou v něm v jednom seznamu uvedeny komponenty, které skutečně jsou a jiné, které je jenom virtuálně zastupují v klasifikaci. Nad takovým modelem se pak nedá rozumně automatizovaně o architektuře reportovat. Uvnitř tzv. aplikační kategorie již je možné objekty dále hierarchizovat (například funkce a služby), pokud se dá říci, že každý takový objekt v realitě existuje. Dílčí metamodel je znázorněn na obrázku níže:

34

Obrázek 21 Doporučený metamodel hlediska aplikačního portfolia

4.2.6 Hledisko aplikační Hledisko aplikační slouží ke znázornění vnitřního chování popisované aplikace, která může poskytovat jednu či více služeb. Primární využití spočívá při návrhu hlavních funkcí aplikací nebo při identifikování překrývajících se funkcionalit poskytovaných různými aplikacemi. Hledisko je detailní a určeno pro odborné pracovníky (viz obrázek vlevo). Dílčí metamodel je znázorněn na obrázku níže:

Obrázek 22 Doporučený metamodel aplikačního hlediska

35

4.2.7 Hledisko spolupráce aplikací Hledisko popisuje vazby mezi jednotlivými aplikačními komponentami a to za účelem zachycení důležitých toků a znázornění služeb, které jsou jimi poskytovány. Toto hledisko primárně slouží k názornému až detailnímu zobrazení vazeb na aplikační úrovni. Dílčí metamodel je znázorněn na obrázku níže:

Obrázek 23 Doporučený metamodel hlediska spolupráce aplikací

4.2.8 Hledisko využití aplikací Toto hledisko popisuje, jakým způsobem jsou aplikace používány k podpoře jednoho či více byznys procesů, případně jak jsou používány jinými aplikacemi. Hledisko se dá rovněž využít při návrhu aplikací a to díky identifikaci aplikačních služeb, které jsou požadovány jednotlivými procesy případně ostatními aplikacemi. Hledisko lze rovněž využít k návrhu byznys procesů postavených na již existujících aplikačních službách. Toto hledisko představuje logickou návaznost mezi byznys a aplikační vrstvou. Dílčí metamodel je znázorněn na obrázku níže:

36

Obrázek 24 Doporučený metamodel hlediska využití aplikací

4.2.9 Hledisko technologického portfolia Základem obsahu tohoto hlediska je třístupňová klasifikace základních prvků technologické architektury. Jde o stejné členění jako v případě mapy portfolia funkcí veřejné správy nebo aplikací, tzn., že jak technologické komponenty (zejména typy zařízení, operačních systémů a databází), jejich funkce a jejich služby lze jednoznačně klasifikovat, tj. každý zařadit právě do jedné z technologických kategorií. Ve schématu je naznačeno doporučení používat pro vyjádření klasifikace a její topologie v modelech objekt „Skupina“. Tato metodika považuje za nevhodné, používat pro úrovně klasifikace objekty vyhrazené skutečně jsoucím prvkům architektury (např. technologické uzly, funkce nebo služby). Vlastní model architektury se tím ale stává nekonzistentním, neboť jsou v něm v jednom seznamu uvedeny komponenty, které skutečně jsou a jiné, které je jenom virtuálně zastupují v klasifikaci. Nad takovým modelem se pak nedá rozumně automatizovaně o architektuře reportovat. Uvnitř tzv. technologické kategorie již je možné objekty dále hierarchizovat (například funkce a služby), pokud se dá říci, že každý takový objekt v realitě existuje. Dílčí metamodel je znázorněn na obrázku níže:

37

Obrázek 25 Doporučený metamodel hlediska Technologického portfolia

Toto hledisko může být v případě infrastrukturního portfolia.

potřeby

specializováno

za

účelem

vytvoření

4.2.10 Hledisko technologické Technologické hledisko slouží ke znázornění softwarových a hardwarových infrastrukturních elementů, kterými například jsou zařízení, sítě či systémový SW (např. operační systémy, databáze a middleware). Znázorňuje poměrně detailním způsobem technologickou vrstvu.


Obrázek 26 Doporučený metamodel technologického hlediska

38

4.2.11 Hledisko využití technologie/infrastruktury Hledisko poskytuje informaci o SW a HW zajištění jednotlivých aplikací. Jednotlivá zařízení technologie/infrastruktury poskytují služby, které jsou posléze těmito aplikacemi využívány. Toto hledisko je významné například při popsání výkonnosti a škálovatelnosti, protože znázorňuje vztahy mezi zařízeními a aplikacemi.


Obrázek 27 Doporučený metamodel hlediska využití infrastruktury

39

4.2.12 Hledisko vrstev Jak název napovídá, toto hledisko slouží ke znázornění několika vrstev architektury v rámci jednoho diagramu. Rozeznáváme 2 kategorie vrstev a to dedikované a servisní vrstvy. Do první kategorie vrstev řadíme účastníky, byznys procesy, aplikace a prvky infrastruktury. Do druhé skupiny vrstev se pak řadí služby. Kategorie vrstev se střídají. Přičemž je důležitý jejich vztah. Vrstva dedikovaných objektů realizuje servisní vrstvu (vztah „realizace“). Tato servisní vrstva je posléze využívána jinou dedikovanou vrstvou (vztah „used by“). Tento pohled nám umožní odlišit interní strukturu organizace, která je vyjádřena dedikovanou vrstvou od externě rozeznatelného chování vyjádřeného v servisní vrstvě.

Obrázek 28 Příklad možného použití hlediska vrstev

40

Počet vrstev není pevně stanoven. Metamodel tohoto pohledu vychází z celkového metamodelu jazyka ArchiMate 2.1. Na obrázku č. 30 je tedy uveden pouze příklad možného použití, nikoli úplný metamodel této vrstvy. (Klíčové je střídání dedikovaných a servisních vrstev a užívání příslušných vazeb). V rámci NA VS ČR se tohoto hledisko používá primárně pro vyjádření naplnění tzv. vize čtyřvrstvé architektury eGovernmentu konkrétní architekturou úřadu, jeho segmentu nebo schopnosti. 4.2.13 Hledisko zainteresovaných stran Hledisko slouží ke znázornění zainteresovaných subjektů, interních a externích motivátorů změn a zhodnocení (ve smyslu silných a slabých stránek, příležitostí a hrozeb) těchto motivátorů. Rovněž může být použito k popisu vysokoúrovňových cílů.

Doporučený metamodel hlediska zainteresovaných stran:

Obrázek 29 Doporučený metamodel hlediska zainteresovaných stran

4.2.14 Hledisko principů Hledisko principů umožňuje analytikovi/designérovi zachytit klíčové principy které jsou relevantní danému problému a to včetně cílů které motivují tyto principy. Kromě toho lze znázornit i vztah mezi principy a jejími cíli. Například principy se mohou vzájemně ovlivňovat (ať už negativně či pozitivně).

Doporučený metamodel hlediska principů je znázorněn na obrázku níže:

41

Obrázek 30 Doporučený metamodel hlediska principů

4.2.15 Implementační a migrační hledisko Toto hledisko se používá ke vztažení všech programů a projektů k částem architektury, kterou implementují. Pohled umožňuje modelování rozsahu programů, projektů a projektových aktivit a to v souvislosti s rovinou architektury nebo jednotlivých elementů, které jsou ovlivněny. Způsob, jakým se jednotlivé elementy ovlivňují, může být znázorněn vhodnou anotací jejich vazeb. Metamodel implementačního a migračního hlediska:

Obrázek 31 Doporučený metamodel implementačního a migračního hlediska

42

5 Vysvětlení možného užití elementů na příkladech Tato kapitola je pouze informativní. Nestavuje pravidla týkající se použití elementů a jejich vazeb. Cílem je vysvětlit v předchozích kapitolách popsané elementy, vazby, metamodely a hlediska na konkrétních příkladech.

5.1 Příklady – Základní elementy 5.1.1 Byznys vrstva 5.1.1.1 Účastník a Role Účastník (někdy značený jako „Aktér“) představuje organizační jednotku schopnou vykonávat nějakou aktivitu. Může se jednat o jednotlivce, skupinu osob nebo také oddělení či organizační jednotku libovolné instituce. Role je definována jako zodpovědnost za vykonávání specifického chování/aktivity, ke které může být přiřazen účastník. Role může být přiřazena k jednomu či více procesům/funkcím. Může rovněž využívat byznys (uvedeno na příkladu výše) nebo aplikační rozhraní. Byznys rozhraní může být zároveň součástí role. Příklad č. 1 Na příkladu uvedeném níže je znázorněno byznys rozhraní, které je přiděleno byznys rolím. Toto rozhraní slouží jako komunikační prostředek. Byznys role vykonávají konkrétní účastníci.

Obrázek 32 Vysvětlení elementů „účastník“ a „role“

43

Příklad č. 2

Obrázek 33 Vysvětlení elementu „účastník“ a „role“

Element „Aktér“ je na obrázku výše použit ke znázornění Organizace jako celku. Součástí této organizace je „Oddělení příjem korespondence“, též značeno elementem aktér. Toto oddělení vykonává různé role, v našem konkrétním případě byznys roli „Pracovníka podatelny“, proto je použit element Role. Proces „Zpracování podání“ je vykonáván touto rolí. Proces zároveň nabízí služby, které mohou využívat různí aktéři např. Občan. 5.1.1.2 Spolupráce Spolupráce je definována jako spojení dvou a více rolí pracující společně k vykonání určité kolektivní aktivity/chování. Je využívána pro popsání interní činnosti, která je výsledkem spolupráce. Spolupráce může využívat byznys, nebo aplikační rozhraní. Spolupráce může zároveň mít byznys rozhraní (s využitím kompozice). Interakce Je definována jako element chování, který popisuje chování spolupráce. Role v kolaboraci sdílí zodpovědnost za vykonání interakce. Může být vyvolána, nebo vyvolávat jakýkoliv jiný behaviorální element. Příklad č. 1 K sepsání smlouvy z oblasti IT je potřeba spolupráce dvou klíčových rolí a to právního odboru a IT odboru (Odbor právní zajišťuje formální správnost a odbor IT věcnou správnost).

44

Obrázek 34 Vysvětlení elementu "Spolupráce"

5.1.1.3 Rozhraní Rozhraní je definováno jako přístupový bod, kde je procesní služba dostupná okolnímu prostředí. Rozhraní vystavuje funkcionalitu byznys služby ostatním rolím (poskytované rozhraní), nebo očekává funkcionalitu od ostatních byznys služeb (požadované rozhraní). Je často označované za komunikační kanál. Jedna služba může mít více rozhraní. Služba je definována jako služba, která naplňuje potřeby zákazníka (interního nebo externího vůči poskytující organizaci). Vystavuje funkcionalitu role, nebo spolupráce pro její okolí. Je realizována jedním, nebo více procesy, funkcemi, nebo interakcemi, které jsou vykonávány rolemi, nebo spolupracemi. Příklad č. 1

Obrázek 35 Vysvětlení elementů "Rozhraní" a „Služba“

5.1.1.4 Lokalita Lokalita je definována jako místo (koncepčně nebo v prostoru). Element se používá k modelování umístění strukturních elementů (např. aktérů, aplikačních komponent a zařízení). Se strukturálními elementy jsou propojeny vztahem přiřazení.

45

Příklad č. 1 Příklad níže udává, že v lokalitě značené jako „Budova Krajského úřadu“ sídlí Krajský úřad, který má 2 oddělení. Všimněte si stejného znázornění vpravo. V některých situacích je přehlednější a pochopitelnější jednotlivé elementy vkládat do sebe.

Obrázek 36 Vysvětlení elementu "Lokalita"

5.1.1.5 Proces a Událost Proces je definován jako element chování, který sdružuje skupiny chování na základě pořadí činností. Je určen k produkování sady produktů nebo byznys služeb. Popisuje interní činnost vykonávanou rolí, jejíž úkol je produkovat produkty a služby. Konzumenta služby nezajímá postup, ale jen výsledek – proto označení „interní“. Proces typicky seskupuje zase procesy (podprocesy) nebo funkce (dílčí funkce, činnosti). Událost je definována jako něco co se stává (interně nebo externě) a ovlivňuje chování/činnost. Může být vyvolána, nebo vyvolávat (byznys) proces, (byznys) funkci, nebo (byznys) interakci. Událost může přistupovat k byznys objektům a může být složena z jiných událostí. Příklad č. 1 Proces „Zpracování žádosti o výpis z matriky“ je iniciován událostí „Podání žádosti o výpis z matriky“. Všimněte si schématického zaznačení klíčových kroků (na které bude možno později navázat aplikační služby, které tyto procesy zajišťují/podporují). Z obrázku je dále patrna informace, že daný proces je vykonáván určitou byznys rolí.

Obrázek 37 Vysvětlení elementů "Proces" a „Událost“

46

5.1.1.6 Funkce Funkce je definována jako element chování, který seskupuje chování podle vybraná sady kritérií (typicky požadovaných dovedností, znalostí, zdrojů. Popisuje interní činnost/chování vykonávané rolí. Může být vyvolána, nebo může vyvolat jakýkoliv jiný behaviorální element. Funkce na vyšší úrovni obecnosti (například tzv. agendová funkce) seskupuje typicky procesy nebo zase funkce (nižší úrovně, konkrétní). Příklad č. 1

Obrázek 38 Příklad možného použití elementu "Funkce"

5.1.1.7 Byznys objekt Byznys objekt je definován jako element, který je relevantní z předmětného (byznys) pohledu. Reprezentuje důležité informační, nebo konceptuální elementy, které spadají do vrstvy. Využívá se pro modelování typu objektu, jehož instance mohou v organizaci existovat. Příklad č. 1 Na následujícím příkladu je klíčovým objektem faktura. Ta je pro nás natolik významná, že jsme si ji na byznys úrovni pojmenovali. Dále říkáme, že nás zajímají její jednotlivé položky (všimněte si vztahu agregace, který nám říká, že daný objekt „Faktura“ seskupuje určitý počet objektů pojmenovaných jako „Položka faktury“. Faktura je realizována na nižší tj. aplikační úrovni objektem, který je pojmenován „Elektronická faktura“.

Obrázek 39 Příklad možného použití elementu "Objekt"

5.1.1.8 Reprezentace

47

Reprezentace je definována jako smyslově vnímatelná forma informací spojených s byznys objektem. Jsou nosiči informace, která je svázána s byznys objektem. Příkladem mohou být zprávy, nebo dokumenty. Příklad č. 1 Za použití objektu reprezentace je na obrázku níže znázorněno, že existují dvě formy dokumentů, které nás zajímají a to elektronické a listinné.

Obrázek 40 Příklad možného použití elementu "Reprezentace"

5.1.1.9 Význam Význam je definován jako znalost nebo odbornost přítomná v byznys objektu nebo v jeho reprezentaci. Reprezentuje účel byznys objektu, nebo reprezentace. Příklad č. 1

Obrázek 41 Vysvětlení elementu význam

5.1.1.10

Hodnota Hodnota je definována jako relativní přínos, hodnota, užitek nebo důležitost produktu či služby. Hodnota může být asociována přímo s (byznys) službami a nepřímo přes produkty s rolemi a aktéry, které je využívají. 48

Příklad č. 1

Obrázek 42 Vysvětlení elementu „Hodnota"

5.1.1.11

Produkt a Kontrakt Produkt je soubor služeb definovaných kontraktem (zákonem nebo více zákony), které jsou společně poskytovány klientovi (pro jeho životní situaci). Může agregovat byznys / aplikační službu i smlouvu. Může být asociován s hodnotou. Kontrakt je definován jako formální nebo neformální specifikace dohody, která specifikuje práva a povinnosti spojené s produktem. Může být využit k modelování smlouvy jak ve formálním, tak i neformálním smyslu. Je specializací (byznys) objektu.

Příklad č. 1 Ve většině organizací představuje Helpdesk typický produkt. Je totiž definován smluvně (např. interní SLA).

Obrázek 43 Vysvětlení elementů „Kontrakt“ a „Produkt“

49

Příklad č. 2

Obrázek 44 Příklad č. 2 možného použití elementů kontrakt a produkt

Element produkt zde nazvaný jako „Poskytování informací dle zákona“ logicky seskupuje všechny byznys služby, které je potřeba vykonat za účelem splnění příslušné zákonné povinnosti (viz element kontrakt – „Zákon č. 106/1999 Sb….“). 5.1.2 Aplikační vrstva 5.1.2.1 Aplikace/Komponenta Aplikace/Komponenta je definována jako modulární, nasaditelná a nahraditelná část softwarového systému, zapouzdřující své chování a data, které poskytuje skrz sadu rozhraní. Spolupracující aplikační komponenty se propojují přes element aplikační integrace. Příklad č. 1 Na obrázku níže je namalováno, že existují 2 aplikace, které realizují určité aplikační služby. Tyto služby spolu komunikují přes definované rozhraní.

Obrázek 45 Příklad možného použití elementu aplikace

50

5.1.2.2 Aplikační integrace a aplikační interakce Aplikační integrace je definována jako souhrnů dvou nebo více komponent aplikací, které pracují společně za účelem vykonání kolektivního chování. Používá se pro modelování logické, či dočasná integrace aplikačních komponent, která v „podniku“ neexistuje jako samostatná komponenta. Aplikační interakce je definována jako behaviorální element, který vyjadřuje aktivitu kooperujících aktivit. Popisuje kolektivní chování/činnost, která je vykonávána zúčastněnými komponentami. Může také vyjadřovat činnost potřebnou k realizaci aplikační služby. Příklad č. 1 Na příkladu uvedeném níže je namalováno, že dvě aplikace spolu spolupracují, aby provedly určité chování, které jsme schopni jednoznačně pojmenovat.

Obrázek 46 Příklad možného použití elementu aplikační integrace

5.1.2.3 Rozhraní aplikace Aplikační rozhraní je definováno jako přístupový bod, ve kterém je služba aplikace dostupná pro využití uživatelem nebo jinou komponentou aplikace. Specifikuje, jak může být přistupováno k funkcionalitě komponenty (poskytované rozhraní), nebo jakou funkcionalitu komponenta vyžaduje (požadované rozhraní). Příklad č. 1 Na příkladu uvedeném níže je znázorněno, že systém ISDS poskytuje rozhraní, přes které se spisová služba kraje může napojit. V tomto konkrétním případě ještě došlo k zdůraznění požadavku na požadované rozhraní (viz „Požadované rozhraní na ISDS) ze strany spisové služby.

51

Obrázek 47 Příklad možného využití elementu aplikační rozhraní

5.1.2.4 Aplikační funkce a aplikační služby Aplikační funkce je definována jako interní chování jedné aplikační komponenty. Slouží k popisu interního chování aplikační komponenty. Aplikační funkce může realizovat jednu, nebo více aplikačních služeb. Aplikační funkce na vyšší úrovni obecnosti seskupuje funkce z úrovní nižších – konkrétnějších (viz příklad). Služba aplikace je definována jako služba, která poskytuje automatizované chování. Pomocí aplikačních rozhraní vystavuje služba funkcionalitu komponent jejímu okolí (typicky byznys rolím vykonávajícím byznys funkce nebo jiným aplikačním komponentám v téže vrstvě architektury). Příklad č. 1 Na schématu je znázorněno, že aplikace „Systém spisové služby“ disponuje funkcí „Vyřízení žádosti“, která se dále člení na dílčí funkce. Rovněž je velmi jednoduše zaznamenána posloupnost těchto funkcí. Tato aplikace poskytuje službu pojmenovanou „Služba spisové služby“, která může být užívána některými z byznys procesů.

Obrázek 48 Příklad možného využití elementu funkce.

52

5.1.2.5 Datový objekt Datový objekt je definován jako pasivní element vhodný k automatickému zpracování. Měl by popisovat informaci důležitou pro organizaci, ne jen pro aplikační vrstvu. Příklad č. 1

Obrázek 49 Příklad možného využití elementu datový objekt.

Příklad č. 2 Viz kapitola č. 5.1.1.7. 5.1.3 Technologická vrstva 5.1.3.1 Uzel, zařízení a systémový SW Uzel je definován jako výpočetní zdroj, na kterém mohou být skladovány nebo dislokovány artefakty pro použití. Často je kombinací hardwarové komponenty a systémového softwaru, čímž poskytuje kompletní výpočetní prostředí. Uzly mohou být propojeny pomocí elementu cesta, mohou se skládat z pod-uzlů. Zařízení je definováno jako hardwarový zdroj, na kterém mohou být skladovány nebo dislokovány artefakty pro použití. Je specializací uzlu, které vyjadřuje fyzický (výpočetní) zdroj. Zařízení mohou být propojena elementem síť. K zařízení mohou být přiřazeny elementy artefakt (vyjadřující např. nasazení) a systémový software. Systémový SW je definován jako softwarové prostředí pro speciální typ komponentů a objektů, které jsou na něm rozmístěny ve formě artefaktů. Je specializací uzlu a vyjadřuje softwarové prostředí pro běh artefaktů.

53

Příklad č. 1

Obrázek 50 Příklad možného využití elementů uzel, zařízení a systémový SW

5.1.3.2 Rozhraní infrastruktury Rozhraní infrastruktury je definováno jako přístupový bod, kde služby infrastruktury nabízené uzlem mohou být využity jiným uzlem nebo komponentou aplikace. Specifikuje, jak mohou ostatní uzly přistupovat k infrastrukturním službám (poskytované rozhraní), nebo jaká funkcionalita je prostředím vyžadována (požadované rozhraní). Příklad č. 1 Obrázek udává, že systémový SW (například operační systém) disponuje rozhraním.

Obrázek 51 Příklad možného využití elementu "Rozhraní infrastruktury"

5.1.3.3 Komunikační cesta Komunikační cesta je definována jako spojení mezi dvěma nebo více uzly, skrz které si mohou tyto uzly vyměňovat data. Je realizována jednou, nebo více sítěmi, které reprezentují fyzické komunikační média. Příklad č. 1

Obrázek 52 Příklad možného použití elementu "Komunikační cesta"

5.1.3.4 Síť

54

Síť je definována jako komunikační medium mezi dvěma nebo více zařízeními. Reprezentuje fyzickou komunikační infrastrukturu. Realizuje jednu, nebo více komunikačních cest. Příklad č. 1

Obrázek 53 Příklad možného použití elementu "Síť"

5.1.3.5 Infrastrukturní funkce a Služba infrastruktury Infrastrukturní funkce je definována jako element chování, který sjednocuje infrastrukturní aktivitu a může být vykonávaný uzlem. Popisuje interní chování/aktivitu uzlu. Je vystavena pomocí jedné, nebo více infrastrukturních služeb. Služba infrastruktury je definována jako externě viditelná jednotka funkcionality poskytovaná jedním nebo více uzly, která je přístupná přes dobře definované rozhraní a má význam pro okolí. Vystavuje funkcionalitu uzlu jeho okolí, která je přístupná přes rozhraní infrastruktury. Může vyžadovat, používat a produkovat artefakty.

Příklad č. 1 Na příkladu je namalováno, že databázový server disponuje dvěma klíčovými funkcemi a to „Poskytování přístupu k datům“ a „Správa dat“. Tyto funkce jsou přístupné vyšším vrstvám (případně jiným technologickým komponentám) pomocí dvou stejnojmenných funkcí.

Obrázek 54 Příklad možného použití elementu "funkce a služba infrastruktury"

55

5.1.4 Elementy motivačního rozšíření 5.1.4.1 Zainteresovaný subjekt (Stakeholder) Zainteresovaný subjekt, tým nebo organizace, která má zájem na přínosu architektury.

Příklad č. 1

Obrázek 55 Příklady stakeholderů

5.1.4.2 Motivátor Motivátor představuje okolnost, která vede organizaci ke změně. Např. změna v legislativě, která vyžaduje změnu ve způsobu fungovaní organizace.

Obrázek 56 Vysvětlení elementu "Motivátor"

5.1.4.3 Zhodnocení Zhodnocení je výsledek analýzy motivátoru.

56

Obrázek 57 Vysvětlení elementu "zhodnocení"

5.1.4.4 Cíl Cíl je koncový stav, kterého chce stakeholder dosáhnout.

Obrázek 58 Vysvětlení elementu cíl

5.1.4.5 Požadavek Požadavek je stanovisko, formálně vyjádřená potřeba, která musí být v systému realizována.

57

Obrázek 59 Vysvětlení elementu "požadavek"

5.1.4.6 Omezení

Omezení na cestě k realizaci požadovaného systému.

Obrázek 60Vysvětlení elementu omezení

5.1.4.7 Princip Princip představuje normovanou vlastnost všech systémů v daném kontextu, nebo způsob jejich realizace.

58

Obrázek 61 Vysvětlení elementu "Princip"

5.1.5 Elementy migračního a implementačního rozšíření

Obrázek 62 Vysvětlení elementů "Pracovní blok" a "Dodaný výstup"

5.2 Příklady – Vazby 5.2.1 Kompozice Vztah kompozice značí, že objekt je složen z jednoho nebo více jiných objektů. Příklad č. 1 Všimněte si dvojího možného vyjádření, které říká totéž. Na obrázku je znázorněno, že „Komponenta spisové služby“ se skládá ze dvou dílčích komponent a to „Podatelna a výprava“ a „Komplementace řízení workflow“.

59

Obrázek 63 Příklad možného použití vazby kompozice.

5.2.2 Agregace Vztah agregace značí, že objekt seskupuje určitý počet jiných objektů. Příklad č. 1 Cíl „Snížení nákladů na provoz IT se rozpadá“ na dva dílčí cíle.

Obrázek 64 Příklad možného použití vazby "agregace"

5.2.3 Přiřazení Vztah přiřazení spojuje prvky chování s aktivními elementy (např. role, komponenty), které je provádějí nebo role s účastníky, kteří je plní. Příklad č. 1

Obrázek 65 Příklad možného použití vazby přiřazení

60

5.2.4 Realizace Vztah realizace spojuje logickou entitu s více konkrétní entitou, která ji realizuje. Příklad č. 1

Obrázek 66 Příklad možného použití vazby „realizace“

Příklad č. 2

Obrázek 67 Příklad možného použití vazby "realizace"

5.2.5 Použité ze strany Použití služeb procesy, funkcemi, nebo interakcí a přístupem k rozhraní rolemi, komponentami nebo spoluprací. Příklad č. 1 Obrázek říká, že aplikační služba „Služba spisové služby“ je používána určitou byznys rolí.

Obrázek 68 Příklad možného použití vazby "použité ze strany"

5.2.6 Přístup Přístup přístupová vazba modeluje přístup prvků chování k procesním a datovým objektům. Příklad č. 1 61

Na obrázku níže dva procesy přistupují k datovému objektu.

Obrázek 69 Příklad možného využití vazby "Přístup"

5.2.7 Asociace Asociace vztahů modelů, které nejsou popsatelné jiným, konkrétnější vztahem.

Obrázek 70 Příklad možného využití vazby "Asociace"

5.2.8 Spouštění Vztah spouštění popisuje časové nebo příčinné vztahy mezi procesy, funkcemi, interakcemi a událostmi. Příklad č.1 Z obrázku je jasně rozpoznatelná sekvence jednotlivých kroků (respektive procesů a událostí).

Obrázek 71 Příklad možného využití vazby "spouštění"

5.2.9 Tok Vztah tok popisuje výměnu nebo transfer např. informace nebo hodnotu mezi procesy, funkcemi, interakcemi a událostmi. Příklad č. 1

Obrázek 72 Příklad možného využití vazby "tok"

62

5.2.10 Seskupení Vztah seskupení značí, že stejné nebo rozdílné objekty jsou seskupeny podle nějaké společné charakteristiky.

Obrázek 73 Příklad možného využití seskupení

Tento příklad je současně příkladem (ne úplně přesným) potřeby použití pohledu aplikačního portfolia. 5.2.11 Spojka Spojka se používá ke spojení vztahů stejného typu. Příklad č.1 V tomto případě je spojka použita k větvení procesního flow.

Obrázek 74 Příklad možného využití vazby „spojka“

5.2.12 Specializace Vztah specializace značí, že objekt je specializací jiného objektu. Příklad č.1 Vztah specializace je odvozen z jazyka ULM. Říká, že daný objekt vychází z obecnějšího objektu.

63

Obrázek 75 Příklad možného využití vazby „specializace“

5.3 Příklady hledisek 5.3.1 Hledisko organizační Na příkladu uvedeném níže je provedeno znázornění organizační struktury organizace/dané části organizace, které je předmětem našeho zájmu.

64

5.3.2 Hledisko aplikací

5.3.3 Hledisko spolupráce aplikací

5.3.4 Hledisko využití aplikací

65

5.3.5 Hledisko technologické

5.3.6 Hledisko využití infrastruktury

66

5.3.7 Hledisko vrstev

5.3.8 Implementační a migrační hledisko

67

6 Seznam obrázků Obrázek 1 Schématické znázornění vztahu TOGAF ADM cyklu na modelovací jazyk ArchiMate .............................................................................................................................. 4 Obrázek 2 Vysvětlení pojmů Dodaný výstup architektury, Artefakty a Stavební bloky. .......... 5 Obrázek 3 Podobnost s přirozeným jazykem ......................................................................... 6 Obrázek 4 Znázornění vhodného seskupení elementů jednotlivých vrstev. ........................... 7 Obrázek 5 Zjednodušený metamodel kraje ..........................................................................20 Obrázek 6 Plná verze metamodelu organizační architektury ................................................22 Obrázek 7 Redukovaná verze metamodelu organizační architektury ...................................22 Obrázek 8 Znázornění metamodel datové architektury v jazyce ArchiMate ..........................23 Obrázek 9 Metamodel architektury aplikací v plném rozsahu ...............................................24 Obrázek 10 Zjednodušený metamodel aplikací ....................................................................24 Obrázek 11 Příklad možného rozšíření metamodelu architektury aplikací využitím specializace objektů .............................................................................................................25 Obrázek 12 Metamodel technologické architektury ..............................................................26 Obrázek 13 Znázornění možné specializace elementů technologické vrstvy ........................26 Obrázek 14 Metamodel implementačního a migračního rozšíření ........................................27 Obrázek 15 Motivační metamodel ........................................................................................27 Obrázek 16 Klasifikace hledisek dle jazyka ArchiMate .........................................................28 Obrázek 17 Příklad možného znázornění úvodního hlediska ...............................................32 Obrázek 18 Doporučený metamodel organizačního hlediska ...............................................32 Obrázek 19 Doporučený metamodel hlediska portfolia byznys funkcí ..................................33 Obrázek 20 Doporučený metamodel hlediska kooperace byznys procesů ...........................34 Obrázek 21 Doporučený metamodel hlediska aplikačního portfolia ......................................35 Obrázek 22 Doporučený metamodel aplikačního hlediska ...................................................35 Obrázek 23 Doporučený metamodel hlediska spolupráce aplikací .......................................36 Obrázek 24 Doporučený metamodel hlediska využití aplikací ..............................................37 Obrázek 25 Doporučený metamodel hlediska Technologického portfolia .............................38 Obrázek 26 Doporučený metamodel technologického hlediska ............................................38 Obrázek 27 Doporučený metamodel hlediska využití infrastruktury ......................................39 Obrázek 30 Příklad možného použití hlediska vrstev............................................................40 Obrázek 29 Doporučený metamodel hlediska zainteresovaných stran .................................41 Obrázek 30 Doporučený metamodel hlediska principů .........................................................42 Obrázek 31 Doporučený metamodel implementačního a migračního hlediska .....................42 Obrázek 32 Vysvětlení elementů „účastník“ a „role“ .............................................................43 Obrázek 33 Vysvětlení elementu „účastník“ a „role“ .............................................................44 Obrázek 34 Vysvětlení elementu "Spolupráce".....................................................................45 Obrázek 35 Vysvětlení elementů "Rozhraní" a „Služba“ .......................................................45 Obrázek 36 Vysvětlení elementu "Lokalita" ..........................................................................46 Obrázek 37 Vysvětlení elementů "Proces" a „Událost“ .........................................................46 Obrázek 38 Příklad možného použití elementu "Funkce" .....................................................47 Obrázek 39 Příklad možného použití elementu "Objekt" .......................................................47 Obrázek 40 Příklad možného použití elementu "Reprezentace" ...........................................48 Obrázek 41 Vysvětlení elementu význam .............................................................................48 68

Obrázek 42 Vysvětlení elementu „Hodnota" .........................................................................49 Obrázek 43 Vysvětlení elementů „Kontrakt“ a „Produkt“ .......................................................49 Obrázek 44 Příklad č. 2 možného použití elementů kontrakt a produkt ................................50 Obrázek 45 Příklad možného použití elementu aplikace ......................................................50 Obrázek 46 Příklad možného použití elementu aplikační integrace ......................................51 Obrázek 47 Příklad možného využití elementu aplikační rozhraní ........................................52 Obrázek 48 Příklad možného využití elementu funkce. ........................................................52 Obrázek 49 Příklad možného využití elementu datový objekt. ..............................................53 Obrázek 50 Příklad možného využití elementů uzel, zařízení a systémový SW....................54 Obrázek 51 Příklad možného využití elementu "Rozhraní infrastruktury" ..............................54 Obrázek 52 Příklad možného použití elementu "Komunikační cesta" ...................................54 Obrázek 53 Příklad možného použití elementu "Síť" ............................................................55 Obrázek 54 Příklad možného použití elementu "funkce a služba infrastruktury" ...................55 Obrázek 55 Příklady stakeholderů ........................................................................................56 Obrázek 56 Vysvětlení elementu "Motivátor" ........................................................................56 Obrázek 57 Vysvětlení elementu "zhodnocení" ....................................................................57 Obrázek 60 Vysvětlení elementu cíl .....................................................................................57 Obrázek 59 Vysvětlení elementu "požadavek" .....................................................................58 Obrázek 60Vysvětlení elementu omezení ............................................................................58 Obrázek 61 Vysvětlení elementu "Princip" ............................................................................59 Obrázek 62 Vysvětlení elementů "Pracovní blok" a "Dodaný výstup" ...................................59 Obrázek 63 Příklad možného použití vazby kompozice. .......................................................60 Obrázek 64 Příklad možného použití vazby "agregace" .......................................................60 Obrázek 65 Příklad možného použití vazby přiřazení ...........................................................60 Obrázek 66 Příklad možného použití vazby „realizace“ ........................................................61 Obrázek 67 Příklad možného použití vazby "realizace" ........................................................61 Obrázek 68 Příklad možného použití vazby "použité ze strany" ...........................................61 Obrázek 69 Příklad možného využití vazby "Přístup" ...........................................................62 Obrázek 70 Příklad možného využití vazby "Asociace" ........................................................62 Obrázek 71 Příklad možného využití vazby "spouštění" .......................................................62 Obrázek 72 Příklad možného využití vazby "tok" ..................................................................62 Obrázek 73 Příklad možného využití seskupení ...................................................................63 Obrázek 74 Příklad možného využití vazby „spojka“.............................................................63 Obrázek 75 Příklad možného využití vazby „specializace“ ...................................................64

69

Kontrola a schválení dokumentu

Recommend Documents