Rozdíly

Zde můžete vidět rozdíly mezi vybranou verzí a aktuální verzí dané stránky.

Odkaz na výstup diff

Obě strany předchozí revize Předchozí verze
Následující verze		 Předchozí verze
nar_dokument:ramec_obsahu_a_vystupu_architektur [2021/01/13 10:42] – ↷ Stránka přesunuta z 'nar-dokument:ramec_obsahu_a_vystupu_architektur' do 'nar_dokument:ramec_obsahu_a_vystupu_architektur' Tomáš Šedivecnar_dokument:ramec_obsahu_a_vystupu_architektur [2023/08/16 15:03] (aktuální) – [Metamodel architektury IS - aplikační architektury (AA)] Tomáš Šedivec
Řádek 11: Řádek 11:
   * **Celkový metamodel jazyka rámce TOGAF 9.2 a jazyka ArchiMate 3.1** – Představuje výčet všech prvků, 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 jazyka rámce TOGAF 9.2 a jazyka ArchiMate 3.1** – Představuje výčet všech prvků, 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 prvků a jejich vazeb, které byly do NAR převzaty z celkové specifikace jazyka ArchiMate ve verzi 3.1.   * **Celkový metamodel této metodiky** – Představuje výčet všech prvků a jejich vazeb, které byly do NAR převzaty z celkové specifikace jazyka ArchiMate ve verzi 3.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 a postupně pro tzv. vertikální domény, které mají svůj původ v motivačním rozšíření ArchiMate a dalších rámcích, nejprve pro Strategické směrování, viz přehled domén v [[nar-dokument:struktura_modelovanych_architektur|Struktura modelovaných architektur]].+  * **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 a postupně pro tzv. vertikální domény, které mají svůj původ v motivačním rozšíření ArchiMate a dalších rámcích, nejprve pro Strategické směrování, viz přehled domén v [[nar_dokument:struktura_modelovanych_architektur|Struktura modelovaných architektur]].
   * **Minimální metamodel** – i výběr prvků ze standardů do celkového metamodelu je příliš rozsáhlý a pro úvodní angažmá obtížně použitelný. Proto je v této části doporučena i jeho minimalistická, redukovaná podoba, vhodná pro prvních několik typických architektonických angažmá úřadu.   * **Minimální metamodel** – i výběr prvků ze standardů do celkového metamodelu je příliš rozsáhlý a pro úvodní angažmá obtížně použitelný. Proto je v této části doporučena i jeho minimalistická, redukovaná podoba, vhodná pro prvních několik typických architektonických angažmá úřadu.
  
Řádek 84: Řádek 84:
 **Barevnost prvků domén motivační architektury** **Barevnost prvků domén motivační architektury**
  
-Poslední verze standardu ArchiMate 3.1 zavedla nové barvy pro nové domény (strategickou a fyzickou) a přesunula řadu prvků z byznys domény do strategické. Tím došlo k rozporu v barevnosti prvků vůči původnímu barevnému ladění domén NAR, viz [[nar-dokument:struktura_modelovanych_architektur|Struktura modelovaných architektur]].+Poslední verze standardu ArchiMate 3.1 zavedla nové barvy pro nové domény (strategickou a fyzickou) a přesunula řadu prvků z byznys domény do strategické. Tím došlo k rozporu v barevnosti prvků vůči původnímu barevnému ladění domén NAR, viz [[nar_dokument:struktura_modelovanych_architektur|Struktura modelovaných architektur]].
  
 Tento rozpor se ještě bude muset řešit. Problém je v tom, že na jedné straně NAR počítá s doménami a prvky, které ještě ve standardu ArchiMate nejsou a až se v něm (pravděpodobně) objeví, mohou mít jinou barvu, než nyní plánuje NAR. Současně je problémem efektivní užívání modelovacích nástrojů, kde nejjednodušší je ponechávat prvkům jejich originální ArchiMate barvu. Tento rozpor se ještě bude muset řešit. Problém je v tom, že na jedné straně NAR počítá s doménami a prvky, které ještě ve standardu ArchiMate nejsou a až se v něm (pravděpodobně) objeví, mohou mít jinou barvu, než nyní plánuje NAR. Současně je problémem efektivní užívání modelovacích nástrojů, kde nejjednodušší je ponechávat prvkům jejich originální ArchiMate barvu.
Řádek 264: Řádek 264:
 )). )).
  
-Příkladem rozšíření specializací je sada specializovaných konceptů, odvozených jedním z úřadů z konceptu aplikační komponenty, viz [[nar-dokument:ramec_obsahu_a_vystupu_architektur|Rámec obsahu a výstupu architektur]].+Příkladem rozšíření specializací je sada specializovaných konceptů, odvozených jedním z úřadů z konceptu aplikační komponenty, viz [[nar_dokument:ramec_obsahu_a_vystupu_architektur|Rámec obsahu a výstupu architektur]].
  
 ==== Povinný rozsah modelů ==== ==== Povinný rozsah modelů ====
Řádek 358: Řádek 358:
 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 následující vyjádření, viz následující obrázek. 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 následující vyjádření, viz následující obrázek.
  
-{{:nar-dokument:image36.png?200 | Metamodel datové architektury NAR}}+{{ :nar-dokument:image36.png | Metamodel datové architektury NAR}}
  
 **Objekt / subjekt veřejné správy** (orig. Business Object) představuje všechny věci, které v prostředí veřejné správy 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. Objekt v modelu představuje konceptuální úroveň datového modelování. **Objekt / subjekt veřejné správy** (orig. Business Object) představuje všechny věci, které v prostředí veřejné správy 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. Objekt v modelu představuje konceptuální úroveň datového modelování.
Řádek 458: Řádek 458:
 Hierarchie aplikačních komponent se může modelovat pouze tam, kde každá jako komponenta označená věc, splňuje skutečně všechny vlastnosti komponenty. Hierarchie aplikačních komponent se může modelovat pouze tam, kde každá jako komponenta označená věc, splňuje skutečně všechny vlastnosti komponenty.
  
-Podle NAR není přípustné společně s reálnými komponentami modelovat i objekty SW licence.+Podle NAR není přípustné společně s reálnými prvky typu Komponenta modelovat i virtuální prvky jako např. SW licence. SW licence je byznysový objekt, pokud je součástí např. nějakého produktu.
  
 Tato otázka se definitivně vyřeší až s tím, jak se v souvislosti s další fází rozvoje ISoISVS v RPP rozhodne o evidování a unikátním označování existence dílčích součástí (aplikačních komponent a funkcí) ISVS. Tato otázka se definitivně vyřeší až s tím, jak se v souvislosti s další fází rozvoje ISoISVS v RPP rozhodne o evidování a unikátním označování existence dílčích součástí (aplikačních komponent a funkcí) ISVS.
Řádek 578: Řádek 578:
 Koncept „Zdroj“ znamená v architektuře strategie a směřování „zdroj pro zajištění změny schopnosti“, nikoli zdroj pro rutinní výkon schopnosti. Koncept „Zdroj“ znamená v architektuře strategie a směřování „zdroj pro zajištění změny schopnosti“, nikoli zdroj pro rutinní výkon schopnosti.
  
-„Schopnost“, jak je uvedeno v [[nar-dokument:modelujici_urady_a_jejich_architektury|Modelující úřady a jejich architektur]], není typickým doménovým typem prvku, tvořícího architekturu, nýbrž schopnost je nejmenší částí organizace, pro niž se architektura hledá a navrhuje. Mapa schopností slouží pro získání celkové přehledu o organizaci. Plánování schopností((Z angl. Capability Based Planning.))je manažerská technika pro plánování zlepšování a plnění strategických cílů bez detailní znalosti o architektuře jednotlivých schopností.+„Schopnost“, jak je uvedeno v [[nar_dokument:modelujici_urady_a_jejich_architektury|Modelující úřady a jejich architektur]], není typickým doménovým typem prvku, tvořícího architekturu, nýbrž schopnost je nejmenší částí organizace, pro niž se architektura hledá a navrhuje. Mapa schopností slouží pro získání celkové přehledu o organizaci. Plánování schopností((Z angl. Capability Based Planning.))je manažerská technika pro plánování zlepšování a plnění strategických cílů bez detailní znalosti o architektuře jednotlivých schopností.
  
 Typ prvku „Hodnota“ má pro NAR dva nejdůležitější významy, oba významy zatím nejsou důvodem pro specializaci stereotypů, pravděpodobně budou v prvních obdobích užívání NAR využívány zřídka: Typ prvku „Hodnota“ má pro NAR dva nejdůležitější významy, oba významy zatím nejsou důvodem pro specializaci stereotypů, pravděpodobně budou v prvních obdobích užívání NAR využívány zřídka:
Řádek 795: Řádek 795:
 Základním použitím „Seskupení“ je vyjádřit úrovně zobecnění nějakých prvků, jejich typů, klasifikačních tříd, u nichž již nejsou naplněny přepoklady definice typu prvku. Základním použitím „Seskupení“ je vyjádřit úrovně zobecnění nějakých prvků, jejich typů, klasifikačních tříd, u nichž již nejsou naplněny přepoklady definice typu prvku.
  
-Například kategorie Front-Office, Middle-Office a Back-office jsou nesmírně důležité pro procesní i aplikační dekompozici (Mapu) úřadu, ale nejsou ani procesem ani aplikační komponentou, proto jsou Seskupením - více např. v [[nar-dokument:referencni_modely_a_klasifikacni_ramce|Referenční modely a klasifikační rámce]].+Například kategorie Front-Office, Middle-Office a Back-office jsou nesmírně důležité pro procesní i aplikační dekompozici (Mapu) úřadu, ale nejsou ani procesem ani aplikační komponentou, proto jsou Seskupením - více např. v [[nar_dokument:referencni_modely_a_klasifikacni_ramce|Referenční modely a klasifikační rámce]].
  
 „Umístění/ lokace“ představuje primárně umístění prvku v prostoru, tj. s odkazem na geografickou navigaci (adresní bod) nebo případně na navigaci uvnitř budouvy. Umístění je přirozeně (a neomezeně) hierarchické, od úrovně planety k nejmenšímu detailu (světadíl, stát, kraj/region, obec, ulice, dům atp.) dle potřeby. „Umístění/ lokace“ představuje primárně umístění prvku v prostoru, tj. s odkazem na geografickou navigaci (adresní bod) nebo případně na navigaci uvnitř budouvy. Umístění je přirozeně (a neomezeně) hierarchické, od úrovně planety k nejmenšímu detailu (světadíl, stát, kraj/region, obec, ulice, dům atp.) dle potřeby.
Řádek 826: Řádek 826:
 ==== Typy vazeb mezi objekty metamodelu ==== ==== Typy vazeb mezi objekty metamodelu ====
  
-Typy vazeb NA VS ČR se plně shodují s aktuálním standardem jazyka ArchiMate, viz [[nar-dokument:ramec_obsahu_a_vystupu_architektur|Rámec obsahu a výstupu architektur]].+Typy vazeb NA VS ČR se plně shodují s aktuálním standardem jazyka ArchiMate, viz [[nar_dokument:ramec_obsahu_a_vystupu_architektur|Rámec obsahu a výstupu architektur]].
  
 === Doporučené příklady vazeb === === Doporučené příklady vazeb ===
Řádek 983: Řádek 983:
 ==== Přehled typových dodávaných výstupů ==== ==== Přehled typových dodávaných výstupů ====
  
-Během cyklu tvorby architektury ADM, v jeho jednotlivých iteracích podle typu angažmá, viz například [[nar-dokument:proces_tvorby_architektur|Proces tvorby architektur]], vzniká a dále se využívá celá řada formalizovaných výstupů (deliverables). Ze standardu TOGAF byly pro NAR vybrány následující z nich.+Během cyklu tvorby architektury ADM, v jeho jednotlivých iteracích podle typu angažmá, viz například [[nar_dokument:proces_tvorby_architektur|Proces tvorby architektur]], vzniká a dále se využívá celá řada formalizovaných výstupů (deliverables). Ze standardu TOGAF byly pro NAR vybrány následující z nich.
  
 === Přehled výstupů architektury a jejich lokalizace === === Přehled výstupů architektury a jejich lokalizace ===
Řádek 1096: Řádek 1096:
 Každý ze standardů a vzorů kategorizuje výstupy a artefakty, naplňující hlediska, z různých pohledů, dimenzí. Zatímco ArchiMate a GEA-NZ třídí primárně podle architektonických domén, u TOGAFu je to podle fází cyklu ADM a u Zachman je to podle průsečíků mezi světonázorovými otázkami (Kdo, Co, Proč, Kde apod.) a úrovněmi abstrakce. Každý ze standardů a vzorů kategorizuje výstupy a artefakty, naplňující hlediska, z různých pohledů, dimenzí. Zatímco ArchiMate a GEA-NZ třídí primárně podle architektonických domén, u TOGAFu je to podle fází cyklu ADM a u Zachman je to podle průsečíků mezi světonázorovými otázkami (Kdo, Co, Proč, Kde apod.) a úrovněmi abstrakce.
  
-NAR přebírá obě klíčová třídění hledisek, podle domén i podle fází, a přidává ještě třetí pragmatický přístup. V rámci něj uvádí NAR povinná, resp. doporučená hlediska a definice pohledů pro jednotlivé explicitně upravené druhy architektonických angažmá, viz [[nar-dokument:proces_tvorby_architektur|Proces tvorby architektury]]. Ostatní, v následujících částech uvedená hlediska jsou pouze inspirací, ulehčující počátky modelování v úřadech.+NAR přebírá obě klíčová třídění hledisek, podle domén i podle fází, a přidává ještě třetí pragmatický přístup. V rámci něj uvádí NAR povinná, resp. doporučená hlediska a definice pohledů pro jednotlivé explicitně upravené druhy architektonických angažmá, viz [[nar_dokument:proces_tvorby_architektur|Proces tvorby architektury]]. Ostatní, v následujících částech uvedená hlediska jsou pouze inspirací, ulehčující počátky modelování v úřadech.
  
 Některá hlediska a definice pohledů z jednotlivých zdrojů se vzájemně překrývají. V takovém případě NAR tyto definice propojuje a vybírá do vlastní specifikace hlediska to podstatné z obou, ze všech zdrojů. Ve Znalostní bázi NA VS ČR je plánováno zveřejnit tabulku namapování doporučovaných hledisek NAR podle zdrojů (hlavně ArchiMate, TOGAF a Zachman, ale i dalších), ze kterých pocházejí. Některá hlediska a definice pohledů z jednotlivých zdrojů se vzájemně překrývají. V takovém případě NAR tyto definice propojuje a vybírá do vlastní specifikace hlediska to podstatné z obou, ze všech zdrojů. Ve Znalostní bázi NA VS ČR je plánováno zveřejnit tabulku namapování doporučovaných hledisek NAR podle zdrojů (hlavně ArchiMate, TOGAF a Zachman, ale i dalších), ze kterých pocházejí.
Řádek 1157: Řádek 1157:
  
 Obecně platí, že v těchto raných fázích implementace NA ve VS ČR je pro architektonická hlediska architektury úřadů povoleno využívat jakékoli typu katalogu, matice nebo diagramu s tím, že doporučovány jsou typy artefaktů podle ArchiMate a TOGAF ACF((Z angl. Architecture Content Framework Obecně platí, že v těchto raných fázích implementace NA ve VS ČR je pro architektonická hlediska architektury úřadů povoleno využívat jakékoli typu katalogu, matice nebo diagramu s tím, že doporučovány jsou typy artefaktů podle ArchiMate a TOGAF ACF((Z angl. Architecture Content Framework
-)), pokud v pokynu pro vybrané architektonické angažmá, viz [[nar-dokument:proces_tvorby_architektur|Proces tvorby architektury]] Praktické příklady architektonických angažmá, není explicitně uvedeno jinak.+)), pokud v pokynu pro vybrané architektonické angažmá, viz [[nar_dokument:proces_tvorby_architektur|Proces tvorby architektury]] Praktické příklady architektonických angažmá, není explicitně uvedeno jinak.
  
 Pro všechny katalogy a matice, níže aktuálně zahrnuté do Národního architektonického rámce, budou postupně definovány evidované atributy objektů a ve Znalostní bázi NA VS ČR publikovány pracovní vzory, jak v tabulkovém editoru pro prvotní inventarizaci, tak ve výměnném formátu ArchiMate. Pro všechny katalogy a matice, níže aktuálně zahrnuté do Národního architektonického rámce, budou postupně definovány evidované atributy objektů a ve Znalostní bázi NA VS ČR publikovány pracovní vzory, jak v tabulkovém editoru pro prvotní inventarizaci, tak ve výměnném formátu ArchiMate.
Řádek 1397: Řádek 1397:
 Hledisko struktury informací je srovnatelné s tradičními informačními modely vytvořenými v rámci vývoje jakéhokoliv informačního systému. Zobrazuje strukturu informací využívaných v podniku nebo ve specifických byznys procesech či aplikacích ve formě datových typů nebo objektově orientovaných tříd. Hledisko může sloužit také k zobrazení způsobu, jak jsou byznys informace reprezentovány na aplikační úrovni ve formě datových struktur, a jak jsou namapovány na základní infrastrukturu například prostřednictvím databázového schématu. Hledisko struktury informací je srovnatelné s tradičními informačními modely vytvořenými v rámci vývoje jakéhokoliv informačního systému. Zobrazuje strukturu informací využívaných v podniku nebo ve specifických byznys procesech či aplikacích ve formě datových typů nebo objektově orientovaných tříd. Hledisko může sloužit také k zobrazení způsobu, jak jsou byznys informace reprezentovány na aplikační úrovni ve formě datových struktur, a jak jsou namapovány na základní infrastrukturu například prostřednictvím databázového schématu.
  
-Na zobrazení struktury informací v ArchiMate obvykle navazují detailní diagramy v dalších notacích - ERD, UML, viz také [[nar-dokument:ramec_obsahu_a_vystupu_architektur|Rámec obsahu a výstupu architektur]].+Na zobrazení struktury informací v ArchiMate obvykle navazují detailní diagramy v dalších notacích - ERD, UML, viz také [[nar_dokument:ramec_obsahu_a_vystupu_architektur|Rámec obsahu a výstupu architektur]].
  
 === Hledisko struktury aplikací === === Hledisko struktury aplikací ===