- Česky (cs)
- English (en)
Rámec obsahu a výstupů architektur
Tato kapitola stanovuje přesně, jaké objekty architektury úřadu jsou předmětem zájmu při sestavování modelu a jeho architektonických výstupů jako způsobu popisu obrazu architektury úřadu.
Kapitola se zejména zaměřuje na prvky metamodelu a na formální (předměty dodávky) a neformální (artefakty) architektonické výstupy.
Předměty modelování – architektonický metamodel
Metamodel je předpis a logika používání jazyka pro modelování architektury v praxi. Při tvorbě Národní architektury VS ČR budou vytvářeny modely v jazyce ArchiMate podle předem schváleného metamodelu. Užití metamodelu je plně v souladu se specifikacemi jazyka ArchiMate a architektonického rámce TOGAF. Metamodel architektury jednoznačně definuje, jaké elementy ze specifikací rámce TOGAF a jazyka ArchiMate a jaké vazby mezi nimi, jsou použity.
- 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.
- 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 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.
Důvody a pravidla pro používání metamodelů při tvorbě konkrétních modelů jsou následující:
- Metamodel je abstraktním modelem modelování, 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).
Základy jazyka ArchiMate
Modelovací jazyk ArchiMate je složen ze základních stavebních kamenů, kterým se říká elementy (prvky, koncepty). Byl navržen s oporou o několik základních principů, jsou to:
- tři základní architektonické vrstvy (byznys, aplikační a technologická) a tři rozšiřující (strategická, fyzická a implementační)
- čtyři aspekty (motivace, aktivní, chování a pasivní)
- interní a externí aktivní prvky a prvky chování modelu
- individuální a kolektivní aktivní prvky a prvky chování modelu
- specifické prvky Seskupení a Umístění (lokalita)
Aspekty jazyka ArchiMate
Jazyk je složen z prvků, které se člení do čtyř kategorií:
- aktivní,
- behaviorální,
- pasivní a
- motivační
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: business 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.
K tomu se přidávají motivační prvky jazyka, které říkají proč je struktura hlavních (core) prvků jaké je a zejména proč by se měla měnit do své cílové podoby.
Pravidla použití jazyka ArchiMate pro modelování NA VS ČR
Vrstvy a struktura diagramů v modelech
V diagramech je třeba rozlišit jednotlivé vrstvy (příp. strukturu) modelů pomocí vizuálního uspořádání. Základní elementy vrstev modelu (byznys, aplikační a datová, technologická, infrastrukturní) budou vždy odlišeny barevně. Jednotlivé elementy pohledů jsou i mezi vrstvami vertikálně (shora dolů a naopak) propojeny logickými vazbami.
Metodika předpokládá, že výraznou informací, obsaženou v pohledech na model je i umístění prvků modelu v jeho ploše, v tzv. mapách, také se hovoří o topologii prvků. Pro jednotnou logiku umisťování prvků v diagramech poslouží postupně sestavené referenční modely k jednotlivým vrstvám architektury a k jednotlivým pohledům na ně.
Barvy prvků
Specifikace standardu ArchiMate 3.1 barevnost prvků nepředepisuje, ale umožňuje ji s výhodou jednotně využít. Rozhodnutí o barevnosti ponechává na architektovi a jeho nástroji.
NAR jde v tomto dále a pro snazší jednotné čtení a interpretaci diagramů modelů předepisuje základní barevnost jednotlivých prvků v tabulkách níže. Barevnost podle RPG není povinná, ale doporučující.
Pokud architekt vyjadřuje v některých diagramech barvou nějakou klíčovou vlastnost prvku, například, že vzniká, mění se nebo zaniká, může použít i jiné barvy, ale vždy musí doplnit legendu barev.
Barevnost prvků podle aspektu
Pokud je potřeba v metamodelu zdůraznit příslušnost prvku k některému aspektu jazyka, učiní se tak pomocí odstínů šedé následovně:
- bílá – abstraktní prvky (kategorie), které nemají instance
- světle šedá – pasivní struktury
- středně šedá – chování
- tmavě šedá – aktivní struktury
Barevnost prvků základních vrstev (domén).
Definovaná struktura metamodelu ArchiMate je členěna na tři vrstvy, které jsou pro účely respektování čtyřvrstvé vize architektury eGovernmentu ČR rozšířeny na čtyři vrstvy. Každá vrstva má barevnou interpretaci dle doporučení originální ArchiMate specifikace, podle které lze určit, o jakou vrstvu se jedná. Tento barevný standard je nutno respektovat a dodržovat.
- Byznys vrstva a všechny elementy v této vrstvě jazykem ArchiMate definované budou žluté,
- Aplikační a datová vrstva a všechny elementy v této vrstvě jazykem ArchiMate definované budou tyrkysové,
- Technologická vrstva a všechny elementy v této vrstvě jazykem ArchiMate definované budou zelené (případně světlejší zelené),
- Infrastrukturní vrstva a všechny elementy v této vrstvě jazykem ArchiMate definované budou zeleně (případně tmavší zelené).
Komponenty obou technologických vrstev vize čtyřvrstvé architektury VS (IT technologické a infrastrukturní) mohou být v téže zelené, neboť ve skutečnosti tyto vrstvy jsou pouze speciálním rozdělením jednotné technologické architektury standardu ArchiMate pro české potřeby řízení zodpovědnosti za rozdílné technologické služby.
V souladu se specifikací ArchiMate nedoporučuje NAR používat barevné vzájemné rozdělení tzv. aspektů v jednotlivých vrstvách (aktivní prvky, chování a pasivní prvky) – barevné odlišení není nutné, a když, tak jedině stupni šedé.
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 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.
Tabulka definice barev dle standardu ArchiMate 3.11)
Doména | Název barvy | Definice barvy (RGB) | ||
---|---|---|---|---|
Červená (R) | Zelená (G) | Modrá (B) | ||
Motivační | Fialová | 204 | 204 | 255 |
Strategická | Okrová | 245 | 222 | 170 |
Byznys | Žlutá | 255 | 255 | 175 |
Aplikační | Tyrkysová | 175 | 255 | 255 |
Technologická | Zelená | 175 | 255 | 175 |
Fyzická | Zelená | 175 | 255 | 175 |
Implementační a migrační | Světle červená | 255 | 224 | 224 |
Kompozitní | Světle zelená | 224 | 255 | 224 |
Bez barvy (bílá) | - (255) | - (255) | - (255) | |
Oranžová | 255 | 185 | 115 |
Tvary prvků
Elementy ve všech vrstvách budou zobrazeny tak, jak je jazyk ArchiMate definuje. Pro standardizované a povinné diagramy je nepřípustné upravovat jejich tvary dané standardem The Open Group.
Vedle toho (a navíc) je ale možné vytvářet na základě korektně zachyceného modelu úřadu libovolné a rozmanité tzv. laické diagramy, představující model netrénovaným čtenářům prostřednictvím intuitivních (často naivních a naturálních) ikon a animací.
Vyšší verze specifikace ArchiMate
Tato verze metodiky modelování a metamodelu v NAR vychází z aktuální verze specifikace ArchiMate, označované jako 3.1. Jelikož již jsou na rok 2019 ohlášena další rozšíření a nové verze, bude potřeba metamodel NAR průběžně aktualizovat. Očekává se ale, že nové verze specifikace budou velkou měrou tzv. zpětně kompatibilní a nebude tak mít zásadní dopad na v této metodice již vyjádřená pravidla a příklady.
Přehled lokalizace prvků a vazeb standardu ArchiMate
Přehled prvků standardu ArchiMate 3.1 a jejich lokalizace
Doména | Původní název | Generický překlad | Úprava pro NAR |
---|---|---|---|
Motivační | Stakeholder | Zainteresovaný | |
Driver | Motivátor, vliv, driver | Veřejná potřeba, hnací prvek | |
Assesment | Zhodnocení vlivu | Vyhodnocení potřeby | |
Goal | Cíl | Strategický cíl, politika | |
Outcome | Výstup | ||
Principle | Princip | Architektonický princip | |
Requirement | Požadavek | Klíčový architektonický požadavek | |
Constraint | Omezení | Omezující podmínka řešení | |
Meaning | Význam | ||
Value | Hodnota | Hodnota služby VS | |
Strategická | Course of action | Směr změny | Směr změny, postup, iniciativa |
Capability | Schopnost | Schopnost úřadu | |
Resource | Zdroj | ||
Value stream | Hodnotový řetězec | Scénář dodávky služby | |
Byznys | Business interface | (Byznys) rozhraní | Obslužný kanál VS |
Business actor | Účastník/aktér | Účastník interakce s VS | |
Business role | Role | Role ve veřejné správě | |
Business collaboration | (Byznys) spolupráce | Spolupráce ve VS | |
Business function | (Byznys) funkce | ||
Business process | Proces | ||
Business event | Událost | Životní událost | |
Business interaction | Interakce | Interakce ve VS | |
Business service | (Byznys) služba | Služba veřejné správy | |
Business object | (Byznys) objekt | Objekt VS | |
Contract | Kontrakt | ||
Representation | Reprezentace | ||
Product | Produkt | Produkt VS pro ŽS | |
Aplikační | Application component | (Aplikační) komponenta | Aplikace |
Application interface | (Aplikační) rozhraní | ||
Application collaboration | (Aplikační) spolupráce | ||
Application service | (Aplikační) služba | ||
Application function | (Aplikační) funkce | ||
Application interaction | (Aplikační) interakce | ||
Application process | (Aplikační) proces | ||
Application event | (Aplikační) událost | ||
Data object | (Datový) objekt | Logická data | |
Technologická | Node | Uzel | |
Communication network | (Komunikační) síť | Datová síť? | |
Device | Zařízení | ||
System software | Systémový software | ||
Technology collaboration | (Technologická) spolupráce | ||
Technology interface | (Technologické) rozhraní | ||
Path | Cesta | ||
Technology service | (Technologická) služba | ||
Technology function | (Technologická) funkce | ||
Technology process | (Technologický) proces | ||
Technology interaction | (Technologická) interakce | ||
Technology event | (Technologická) událost | ||
Artifact | Artefakt | Fyzická data | |
Fyzická | Equipment | Vybavení/Nástroj | |
Facility | Budova | ||
Distribution network | Distribuční cesta | ||
Material | Materiál | ||
Implementační a migrační | Work package | Balíček práce | |
Deliverable | Předmět dodávky /plnění | ||
Implementation event | Implementační událost | ||
Plateau | Stav architektury | ||
Gap | Rozdíl | ||
Kompozitní | Grouping | Seskupení | |
Location | Lokace |
Barevnost prvků v tabulce2) je 100% převzata z originální specifikace ArchiMate 3.1.
Přehled vazeb ArchiMate
Přehled a vysvětlení jednotlivých vazeb obsahuje následující tabulka3):
Při použití v modelech a jejich diagramech dostávají (mohou dostávat) jednotlivé instance těchto typů vazeb své výstižné názvy, obdobně jako je tomu u instancí konceptů (typů prvků metamodelu).
Celkový metamodel NA VS ČR
Jelikož metamodely a definice pohledů jsou základem pro tvorbu modelů a jejich interoperabilitu, jsou všechny zde uvedené definice dostupné na OHA a jeho webových stránkách také jako soubory ve formátech open source nástroje Archi a ve výměnném formátu The Open Group ArchiMate File Exchange Format.
Aktualizované metamodely budou vydány až jako výsledek ověření níže uvedených návrhů v praxi úřadů.
Maximální metamodel NA VS ČR
Maximální metamodel architektury úřadů jako součástí Národní architektury je pro první období jejího zavádění stanoven jako plný a nezměněný rozsah standardní specifikace ArchiMate 3.1, případně vyšší.
Protože metamodel ArchiMate a TOGAF ještě není vzájemně 100% shodný4), přebírá NAR některé objekty metamodelu i z TOGAF, a to objekty Organizační jednotka, Logická a fyzická aplikační komponenta, Logická a fyzická technologická komponenta.
Vedle toho zavádí NAR nové koncepty pro objekty typické pro českou veřejnou správu, a to Právní předpis, Agendu a Informační systém (logický, ISVS).
Nad rámec standardní specifikace ArchiMate 3.1 jsou tedy pro metamodel NA VS ČR zavedeny následující specializované koncepty (objekty metamodelu), tzv. «stereotypy», postihující:
- potřeby veřejné správy je to „právní předpis“ jako «Předpis», «Agenda» a «IS»,
- obecně chybějící koncepty „organizační jednotka“ jako «Organizace» (dle TOGAF) a «Útvar », pro standardizaci «Standard»,
- potřeby odděleně postihnout a vyhodnotit prvky komunikační infrastruktury jsou to volitelně «Komunikační služby», «Komunikační funkce» apod. (z čtyřvrstvé vize),
- potřeby odlišit «Logické aplikační komponenty» a «Fyzické aplikační komponenty» (z TOGAF).
Není povinné specializovat prvky z doplněné vrstvy Komunikační a fyzické infrastruktury, ale je to přípustné.
Teprve praktická zkušenost ukáže, zda není výhodné některé objekty metamodelu pro zjednodušení úplně zakázat a jiné další jako specializace původních ještě doplnit.
Základní metamodel
Doporučený poprvé redukovaný (základní) metamodel je představen souhrnně na schématu uvedeném níže (vybrané prvky) a současně po částech vždy u jednotlivých doménových metamodelů (kompletně).
V jednotlivých typizovaných (a legislativním nebo metodickým předpisem upravených) architektonických angažmá, jako je právě seznámení OHA s plánovaným IT projektem (tzv. žádost) bude samostatným metodickým postupem doporučen pro zjednodušení ještě dále redukovaný metamodel.
Doporučené redukované (zjednodušené) metamodely jednotlivých vrstev architektury jsou uvedeny v následujících částech.
Zjednodušený metamodel základních doporučených prvků
Celkový, již redukovaný základní (natož maximální) metamodel definující architekturu NA, obsahuje ještě stále značné množství vazeb a rozšiřujících oblastí. Pro přehlednost a lepší pochopení je na Obrázku níže schematicky znázorněn dále zjednodušený metamodel základních doporučených prvků. Z úplného metamodelu byly vybrány pouze nejzásadnější objekty a vazby z nerozšířeného standardu ArchiMate.
Principy a příklady lokálních rozšíření metamodelu
Každá z budoucích tzv. povinných organizací (OVS) bude pravděpodobně moci architekturu úřadu modelovat nad rámec povinného rozsahu, definovaného touto metodikou a udržovaného v centrálním architektonickém úložišti. Do něj však budou po kontrole přebírány pouze modely přesně stanoveného rozsahu.
Pro svoje interní účely smí OVS rozšiřovat metamodel architektury, jak v notaci ArchiMate specializací objektů, kdy vznikají nové tzv. stereotypy, tak provázáním objektů do detailních modelů v jiných notacích, např. UML, BPMN, DMN nebo Citizen Journey Map5).
Příkladem rozšíření specializací je sada specializovaných konceptů, odvozených jedním z úřadů z konceptu aplikační komponenty, viz Rámec obsahu a výstupu architektur.
Povinný rozsah modelů
Povinný rozsah modelů na úrovni Národní architektury VS ČR není stanoven souhrnně touto metodikou, ale je dán typy architektonických angažmá. Jim budou odpovídat dílčí metodické pokyny a rozšiřující metodiky typu „Jak na to?“. Například tabulky a vysvětlení ve formuláři a metodickém pokynu žádosti o stanovisko OHA k ICT projektům jednoznačně stanovují, které objekty modelů musí být zahrnuty.
Dílčí doménové metamodely
Metamodel byznys architektury (BA)
V rámci této části je definován metamodel organizační architektury a to jak v plné, tak i redukované verzi a v minimální verzi.
Součástí metamodelu BA, jak je zobrazen, jsou i koncepty metamodelu patřící podle NAR nebo ArchiMate do jiných domén, protože jsou důležitou součástí celkového pohledu na výkon služeb veřejné správy (tj. Byznys). Myslí se tím koncepty:
- ze strategické domény: Schopnost úřadu, Scénář dodávky veřejné služby a Umístění
- z motivační domény: Hodnota produktu/služby VS a Význam objektu VS
- z domény shody s předpisy: Předpis.
Vedle lokalizovaných označení pro VS ČR, například „Účastník interakce s VS“, je možné pro zjednodušení v profesní komunitě vždy používat i originální označení, zde „aktér“. Některé zmíněné pro byznys důležité koncepty byly ve verzi 3.1 ArchiMate přesunuty do jiných domén, proto mají jiné barvy, ale zde jsou i nadále uvedeny.
Definice prvků metamodelu byznys architektury
Tabulka6) s definicemi prvků metamodelu byznys architektury
Název typu prvku | Definice významu typu prvku | Definice NAR |
---|---|---|
Byznys rozhraní | A point of access where a business service is made available to the environment. | Místo přístupu ke službám veřejné správy, také kontaktní místo nebo obslužný kanál (přepážky, CzechPOINT, Portál občana apod.) |
Účastník/aktér | A business actor is a business entity that is capable of performing behavior (ArchiMate). A person, organization, or system that has one or more roles that initiates or interacts with activities; for example, a sales representative who travels to visit customers. Actors may be internal or external to an organization (TOGAF). | Osoba, organizace nebo systém, který vystupuje v jedné nebo více rolích jako účastník aktivit (byznys funkcí, procesů nebo služeb). Účastníky, aktéry, jsou všechny strany výkonu služby ve veřejné správě. |
Role | The responsibility for performing specific behavior, to which an actor can be assigned, or the part an actor plays in a particular action or event. (ArchiMate). The usual or expected function of an actor, or the part somebody or something plays in a particular action or event. An actor may have a number of roles (TOGAF). | Role představuje přístup, resp. chování, konkrétní osoby nebo skupiny osob ve vztahu k výkonu služeb ve veřejné správě. Každá reálná osoba (aktér) vystupuje do, je aktivní v, jedné nebo více rolích, bere na sebe pro daný případ roli. Obvyklá, nebo očekávaná funkce aktéra, nebo jeho části nebo cokoli hrající (účastníci se aktivně) v konkrétní akci nebo události. |
Spolupráce (byznys) | An aggregate of two or more business internal active structure elements that work together to perform collective behavior. | Skupina nejméně dvou aktérů či rolí, kteří musí pracovat společně, aby mohli vykonat určité kolektivní chování. Může nastat například při spolupráci více OVS na jedné službě. |
Byznys funkce | A collection of business behavior based on a chosen set of criteria (typically required business resources and/or competences), closely aligned to an organization, but not necessarily explicitly governed by the organization.. | Funkce dodává business schopnosti. Funkce je úzce propojena s organizací (jejím členěním), ale není nezbytně touto částí organizace řízena / spravována. Základní jednotka chování, konání úřadu, to, co musí úřad interně umět vykonávat, aby mohl vykonávat činnosti v agendě a poskytovat interní (v úřadu) i externí služby klientům. |
Byznys proces | A sequence of business behaviors that achieves a specific outcome such as a defined set of products or business services (ArchiMate). A process represents flow of control between or within functions and/or services (depends on the granularity of definition). Processes represent a sequence of activities that together achieve a specified outcome, can be decomposed into sub-processes, and can show operation of a function or service (at next level of detail). Processes may also be used to link or compose organizations, functions, services, and processes (TOGAF). | Proces představuje specifický způsob řízení funkcí v jejich přesně daném pořadí. Proces je tedy tvořen funkcemi a současně funkce (na jiné míře detailu je tvořena procesy. Typickým výstupem procesu, tzv. procesním rozhraním je služba. |
Událost /životní událost | A business behavior element that denotes an organizational state change. It may originate from and be resolved inside or outside the organization. | Změna stavu, která je z procesního pohledu podstatná, může se vyskytnout vně nebo uvnitř organizace a vně nebo uvnitř organizace může být zpracována. |
Interakce | A unit of collective business behavior performed by (a collaboration of) two or more business roles. | Jednotka kolektivního chování vykonávaná ve spolupráci dvou a více rolí. |
Byznys služba veřejné správy | An explicitly defined exposed business behavior (ArchiMate). A service delivers or supports business capabilities through an explicitly defined interface and is explicitly governed by an organization (ie. has a SLA contract) - TOGAF. | Služba je specifickým způsobem řízení výkonu funkcí a procesů. Podporuje podnikové dovednosti (business capabilities) prostřednictvím jednoznačně definovaného rozhraní a je jednoznačně formálně řízena organizací (například má SLA smlouvu). |
Byznys objekt / objekt práva | A concept used within a particular business domain. | Byznys objekt je cokoli, co objektivně (hmotně i nehmotně) existuje v byznys doméně, je předmětem modelování a nehodí se pro to žádný specifický koncept BA. Objekt je typicky pasivní, tj. je předmětem chování aktivních prvků (akterů a rolí), ve veřejné správě má mnoho společného s pojmem „objekt práva“, ale má širší význam. |
Kontrakt | A formal or informal specification of an agreement between a provider and a consumer that specifies the rights and obligations associated with a product (ArchiMate). An agreement between a service consumer and a service provider that establishes functional and non-functional parameters for interaction (TOGAF). | Kontraktem (smlouvou) nazýváme jakoukoli formální nebo neformální dohodu mezi poskytovatelem a příjemcem služby, resp. celého produktu. Produkty veřejné správy jsou upraveny zejména zákony, proto byl zaveden specializovaný typ prvků právní předpis, «Předpis», odvozený od kontraktu. Pro řízení interních i externích služeb budou sloužit dohody o úrovni služeb (SLA7)). |
Reprezentace | A perceptible form of the information carried by a business object. | Forma existence a možnosti vnímání byznys objektu a jeho informací, například eletronická, hlasová, listinná, materiální, apod. |
Produkt VS pro ŽS | A coherent collection of services and/or passive structure elements, accompanied by a contract/set of agreements, which is offered as a whole to (internal or external) customers (ArchiMate). Output generated by the business. The business product of the execution of a process. | Produktem je kompozice výstupů byznysu, typicky služeb a zboží, doplněná o další součásti - pravidla, smlouvy a podmínky, data, nosiče a další. Trendem VS bude transformovat povinnosti úředníků do podoby služeb nebo dokonce produktů veřejné správy, kompletně řešících životní situaci klienta. |
«Agenda» | Nemá, viz byznys funkce | Ucelená oblast působnosti orgánu veřejné moci nebo ucelená oblast působení soukromoprávního uživatele údajů. Je unikátně evidována v RPP. Odpovídá široce pojaté byznys funkci, ale pro svébytné postavení ve VS ČR bude modelována jako specializovaný stereotyp. |
«Agendová činnost » | Nemá, viz byznys funkce | Dílčí část agendy, opět odpovídá byznys funkci, alternativně i pro ni je navržen specializovaný stereotyp. Je evidována v RPP. |
«Organizace» | Nemá, viz aktér (ArchiMate). A self-contained unit of resources with goals, objectives, and measures. Organization units may include external parties and business partner organizations (TOGAF). | TOGAF na rozdíl od ArchiMate obsahuje samostatný typ prvku i pro aktéra v podobě osoby. Zavedením specializovaného stereotypu pro právnické osoby se uvolní prostor používání typu aktér výhradně pro fyzické neboli přirozené osoby. |
«Útvar» | Nemá, viz aktér. | Samostatně neexistující dílčí organizační jednotka úřadu (sekce, odbor, oddělení, skupina, tým, atp.) Pro rozlišení od osob nadaných právní subjektivitou (fyzické/přirozené a právnické) může být vhodné využívat tento specializovaný stereotyp pro kolektivní aktéry bez vlastní subjektivity, součásti organizace. |
Interpretace metamodelu byznys architektury
Systém úřadu má architekturu, ta se skládá z prvků a jejich vazeb. Celý úřad jako systém (enterprise) se dělí do menších částí až na nejmenší a dále nedělitelné schopnosti úřadu vykonávat aktivity8). Každá dílčí schopnost úřadu má svoji architekturu na všech vrstvách. Rozdělení úřadu do schopností a jejich vyhodnocení je součástí fáze architektonické vize, ale má klíčový význam pro porozumění byznys architektuře úřadu.
Aktivní prvky BA úřadu
Základním aktivním prvkem úřadu jsou interní aktéři (úřednici) a někteří externí aktéři (subjekty práva), kteří vstupují do vzájemných kontaktů (interakcí) v různých rolích, které na sebe dynamicky a dočasně berou.
Aktéři v rolích využívají obslužných kanálů pro poskytování a přijímání služeb veřejné správy. Pokud je pro realizaci služby potřebná spolupráce více poskytujících aktérů, s výhodou se modeluje jejich vzájemná spolupráce jako zvláštní typ aktivního prvku - spolupráce. Další specializovaný typ aktéra je organizační jednotka.
Aktéři se poznají podle toho, že mají vždy nějakou unikátní identitu, na rozdíl od rolí.
Prvky chování BA úřadu
Aktivní prvky struktury úřadu jsou nadány (dovedou, mají) interním chováním, mají svoji byznys funkci. Byznys funkce možné řídit v jejich přesném pořadí jako byznys proces, končící procesním rozhraním pro klienta – byznys službou, respektive produktem.
Zvláštním, kolektivním typem interního chování je tzv. interakce spolupracujících aktérů.
Zvláštním typem chování aktivních prvků, který nemá trvání, je událost. V systému úřadu se mohou dít interní a externí události. Některé externí události se dějí subjektům práva v rolích klientů a nazýváme je životními událostmi.
Specializovaným typem chování úřadu je jeho každá tzv. agenda, vyjádřená jako agregace všech funkcí, potřebných pro výkon agendy, evidovaných jako tzv. činnosti v agendě.
Navenek patrným prvkem chování a součástí produktů úřadu je jeho veřejná služba, která má hodnotu pro klienta.
Pasivní prvky BA úřadu
Vstupem a výstupem chování úřadu jsou fyzické a elektronické reprezentace věcí, o nichž se úřaduje, tzv. objektů práva. Ty mají pro účastníky chování svůj význam.
Zvláštním typem byznys objektu je kontrakt, reprezentující ujednání dvou nebo mnoha aktérů nebo podmínky, za nichž je vykonáváno chování a dodáván produkt. Specializovaným typem kontraktu je právní předpis různé právní síly (zákon, vyhláška, usnesení, metodika apod.), pro zestručnění zde nazývaný pojmem «Předpis». Svým charakterem koncept Předpis v NAR patří do jedné z motivačních domén, a to do domény Shoda s předpisy, standardizace a dlouhodobá udržitelnost, kterou ale jazyk ArchiMate nezná. Proto je použit specializovaný objekt z byznys vrstvy.
Všechny ostatní „věci“, které jsou součástí vnitřního nebo vnějšího prostředí úřadu a nemají svůj samostatný koncept v některé z domén, se modelují také jako byznys objekt ve vrstvě BA.
Kompozitní prvky BA úřadu
Kompozitním prvkem této vrstvy, který v sobě může zahrnovat řadu ostatních je tzv. produkt. Tento prvek přesně odpovídá marketingové definici produktu – až když je zboží nebo služba doprovázeno obchodními podmínkami (kontraktem, SLA), dokumentací, daty, servisem a dalšími součástmi, stává se produktem, který dokáže řešit potřeby klienta, v našem případě jeho situaci ve vztahu k veřejné správě, plynoucí z jeho nastalé životní události.
Metamodel architektury IS - informační (datové) architektury (DA)
Datová architektura dle TOGAF v nemá jazyce ArchiMate vlastní vrstvu, její objekty jsou rozloženy ve všech třech základních vrstvách. Představují pasivní prvky, tedy o čem jsou systémy, s čím zachází. V podstatě 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 následující vyjádření, viz následující obrázek.
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í.
Datový objekt je logickým obrazem skutečného objektu, promítnutého do vrstvy informačních systémů. Vypovídá o struktuře údajů vedených v IS a představuje logickou úroveň datového modelování.
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.
Datová architektura má pouze pasivní prvky, nemá žádné aktivní ani vlastní kompozitní prvky a ani prvky chování. Může s výhodou využívat kompozitní koncept Seskupení.
Metamodel architektury IS - aplikační architektury (AA)
V rámci této části je definován metamodel architektury aplikací a to jak v plné, tak i redukované verzi.
Struktura prvků metamodelu (konceptů) plně odpovídá základním aspektům jazyka ArchiMate, obdobně jako v ostatních základních vrstvách.
Předpokládáme, že v praxi bude užitečné redukovat jak počet typů prvků modelů, tak počet typů povolených vazeb. Aktuálně doporučenou redukci metamodelu AA, současně považovanou za minimální možnou, ukazuje následující schéma:
Definice prvků metamodelu aplikační architektury
Tabulka9) s definicemi prvků metamodelu aplikační architektury
Název typu prvku | Definice typu prvku | Definice NAR |
---|---|---|
Aplikační komponenta | 1) An encapsulation of application functionality aligned to implementation structure, which is modular and replaceable. It encapsulates its behavior and data, exposes services, and makes them available through interfaces (ArchiMate). 2) An application is a deployed and operational IT system that supports business functions and services. Applications use data and are supported by multiple technology components but are distinct from the technology components that support the application (TOGAF 9.1). | 1) Aplikační komponenta je zapouzdření funkcionality v souladu se strukturou implementace, která je modulární a vyměnitelná. Zapouzdřuje své chování a data, nabízí své služby a dává je k dispozici prostřednictvím rozhraní. 2) Aplikační komponenta je nainstalovaný a zprovozněný IT systém, který podporuje business funkce a služby. Aplikace používají data a jsou tvořeny technologickými komponentami. |
Aplikační rozhraní | A point of access where application services are made available to a user, another application component, or a node. | Aplikační rozhraní je místo, kde jsou aplikační služby dostupné pro uživatele, jiné aplikace nebo technologické uzly. |
Aplikační spolupráce | An aggregate of two or more application components that work together to perform collective application behavior. | Seskupení dvou a více aplikačních komponent, které pracují společněpro poskytnutí kolektivního aplikačního chování. Aplikační spoluprací jsou takové skupiny integrovaných komponent, které nemohou poskytnout službu pro byznys funkci, pokud některá z komponent bude mimo provoz nebo nefunkční či nedostupná. |
Aplikační služba | An explicitly defined exposed application behavior (ArchiMate). The automated elements of a business service. An information system service may deliver or support part or all of one or more business Services (TOGAF). | Aplikační službou je takové chování aplikace (funkce nebo interakce), které je dáno k dispozici uživatelům a je explicitně jako služba řízeno. Aplikační služby jsou součástí digitálních služeb veřejné správy, realizují je. |
Aplikační funkce | Automated behavior that can be performed by an application component. | Schopnost aplikace poskytnout podporu konkrétní byznys funkci nebo procesu. Aplikační funkce je vždy obsažena v nějaké aplikační komponentě a může být byznys funkci či procesu poskytována jako aplikační služba. |
Aplikační interakce | An application interaction represents a unit of collective application behavior performed by (a collaboration of) two or more application components. | Aplikační interakcí je takové chování, které může být vykonáno výhradně ve spolupráci dvou a více aplikačních komponent. |
Aplikační proces | A sequence of application behaviors that achieves a specific outcome. | Aplikační proces představuje aplikační chování (funkce nebo interakce), které jsou řízeny specificky ve svém pevném pořadí (automatizovaně). |
Aplikační událost | An application behavior element that denotes a state change. | Prvek chování aplikace, který označuje změnu stavu. |
Datový objekt | Data structured for automated processing. | |
«Informační systém» |
Interpretace metamodelu aplikační architektury
Aktivní prvky AA úřadu
Základním aktivním prvkem aplikační architektury informačních systémů je aplikační komponenta. Nejméně jedna skutečně instalovatelná aplikační komponenta je součástí Informačního systému.
Aplikační komponenta obsahuje aplikační funkce (funkční specifikace, FS, n-FS) a aplikační rozhraní (GUI a API). Pokud aplikační komponenta disponuje funkcemi a dodá službu výhradně ve spojení s jinou komponentou, pak tyto komponenty tvoří tzv. aplikační spolupráci.
Aplikační rozhraní je přiřazeno aplikační službě, resp. služba je dostupná na rozhraní. Aplikační rozhraní slouží a) jiné aplikační komponentě (službě, funkci) respektive b) slouží aktérovi v jeho roli, čí realizuje byznys rozhraní.
Prvky chování AA úřadu
Základem chování aplikačních komponent, jejich rozhraní a spoluprací jsou (interní) aplikační funkce. Aplikační komponenta má libovolnou granularitu (hierarchii) funkcí.
Kolektivní interní funkce aplikační spolupráce se nazývají aplikační interakce. Charakter aplikační interakce má služba, která v sobě pod jedním společným řízením zahrnuje funkce z více aplikačních komponent - nemůže být poskytnuta, pokud některá z komponent bude mimo provoz nebo nefunkční či nedostupná.
Aplikační funkce, interakce a dílčí procesy lze realizovat a řídit jako automatizované aplikační procesy a workflow. Pro jejich modelování se mohou uplatnit typy prvků aplikační událost a aplikační proces.
Externím projevem chování a výsledkem aplikačních funkcí, interakcí nebo procesů jsou aplikační služby pro jiné aplikace, ale zejména pro prvky chování byznys vrstvy.
Pasivní prvky AA úřadu
Pasivním prvkem aplikační architektury a současně logickým prvkem datové architektury informačních systémů je datový objekt, který v modelu reprezentuje realizaci informačního (datového) obrazu byznys objektu nebo libovolného jiného prvku architektury.
Kompozitní prvky BA úřadu
Aplikační architektura nemá specifický kompozitní prvek, ale pro kategorizaci a seskupení výskytů ostatních prvků používá prvek Seskupení.
Specializace konceptů aplikační architektury
Metodika NAR dále předpokládá, že některé úřady budou chtít / potřebovat význam některých konceptů, prvků metamodelu, upřesnit, tzv. specializovat, a tím si rozsah metamodelu naopak pro svoji potřebu rozšířit.
Takovým příkladem je praxe jednoho z ministerstev, které specializovalo prvek aplikační komponenty do čtyřech kategorií, z nichž dvě představují virtuální agregační úrovně nad originálním významem aplikační komponenty (Informační systém a komponenta IS) a jedna naopak menší logickou jednotku aplikační komponenty (tzv. aplikační modul). Z této zkušenosti zatím je navrženo zahrnout do standardu NAR stereotyp Informační systém (logický), ostatní typy prvků zatím do standardu převzaty nejsou.
Jiným příkladem z téhož zdroje je rozdělení aplikačního rozhraní do více specializovaných rozhraní.
Při budoucím sehrávání modelů úřadů do centrálního repozitory s využitím výměnného formátu The Open Group ArchiMate File Exchange Format, který přirozeně tyto specializace nezná, budou tyto nahrazeny zpět prvkem aplikační komponenta. Je otevřenou metodickou otázkou, která se prakticky vyřeší až při implementaci centrálního repozitory, zda to bude v závazné metodice přípustné nebo bude nutno model pro export filtrovat tak, aby byly přeneseny pouze prvky jednotného významu a granularity, v tomto případě tedy tzv. „Aplikace“, ve významu existující aplikační komponenta.
Z tohoto důvodu doporučujeme při specializaci prvků a rozšiřování metamodelu úřadu značnou zdrženlivost.
Přitom je potřeb zdůraznit rozdíl mezi použitím kompozitní a agregační vazby mezi specializovanými komponentami. Pokud by specializované komponenty byly obrazem fyzických instancí (stavebních bloků řešení - SBB), pak se mezi nimi uplatní vazba kompozitní, protože například jeden fyzický modul může být součástí pouze jedné aplikace a komponenty, pouze jednoho IS.
V případě, kdy budou zastupovat logické prvky architektury (architektonické stavební bloky – ABB), pak se mezi nimi může uplatnit kompozitní i agregační vazba, protože jeden vzorový prvek může být ve výsledku použit ve více výskytech, ve více nadřazených prvcích.
Dále je povšimnutí hodné, že podle standardu ArchiMate je «Informační systém» de facto/prakticky spíše Aplikační spoluprací (colaboration), protože pokud nebudou aplikace systému spolupracovat, pravděpodobně nenaplní svůj / jeho účel.
Také je potřeba zdůraznit, že TOGAF ani ArchiMate neznají pojem Aplikace (Application) jako podstatné jméno ve smyslu aktivního prvku (podmětu), nýbrž pouze jako přídavné jméno, například aplikační služba (Application Service) nebo jako podstatné jméno slovesné (aplikování – něčeho někde).
Pokud je tato „Aplikace“ samostatně instalovatelná a spravovatelná10), pak se podle ArchiMate jedná o aplikační komponentu. Pokud není samostatná, pak se jedná o aplikační funkci, libovolné úrovně podrobnosti.
Pokud by chtěl nějaký úřad vyjádřit «Aplikační modul», který však není schopen samostatné provozní existence, pak by měl jako východisko pro jeho specializaci použít aplikační funkci, nikoli aplikační komponentu.
Zatímco aplikačních funkcí může být uvnitř jedné komponenty libovolně hluboká (detailní) hierarchie, tak aplikační komponenty se takto řetězit nesmí, přinejmenším v modelu fyzických komponent ne. Ve skutečnosti totiž existuje pouze a právě jedna úroveň instalovatelné a provozovatelné komponenty, vše nad touto úrovní je buď Spolupráce (pokud komponenty musí spolupracovat) nebo Seskupení (pokud k sobě jen tak patří, například společně tvoří jeden ISVS. Vše pod instalovatelnou úrovní je aplikační funkce.
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 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.
Metamodel ICT technologické architektury (TA)
Definice prvků metamodelu technologické architektury
Tabulka11) s definicemi prvků metamodelu technologické architektury
Název typu prvku | Definice významu typu prvku | Definice NAR |
---|---|---|
Uzel | A computational or physical resource that hosts, manipulates, or interacts with other computational or physical resources. | Výpočetní technologický uzel je počítačový nebo fyzický zdroj, který hostuje, manipuluje nebo interaguje s jinými výpočetními nebo fyzickými zdroji. |
Komunikační síť | A set of structures and behaviors that connects computer systems or other electronic devices for transmission, routing, and reception of data or data-based communications such as voice and video. | Sada struktur a chování, které spojují počítačové systémy nebo jiná elektronická zařízení pro přenos, směrování a příjem dat nebo datové komunikace, jako je hlas a video. |
Zařízení | A physical IT resource upon which system software and artifacts may be stored or deployed for execution. | Fyzický IT prostředek, na kterém lze systémový software a artefakty uložit nebo zavést k provedení. |
Systémový software | Software that provides or contributes to an environment for storing, executing, and using software or data deployed within it. | Software, který poskytuje nebo přispívá k prostředí pro ukládání, spouštění a používání softwaru nebo dat v něm nasazených. |
Technologická spolupráce | An aggregate of two or more nodes that work together to perform collective technology behavior. | Souhrn dvou nebo více uzlů, které spolupracují při provádění kolektivního technologického chování. |
Technologické rozhraní | A point of access where technology services offered by a node can be accessed. | Místo přístupu, kde lze přistupovat k technologickým službám nabízeným uzlem. |
Cesta | A link between two or more nodes, through which these nodes can exchange data or material. | Spojení mezi dvěma nebo více uzly, prostřednictvím kterého si tyto uzly mohou vyměňovat data nebo materiál. |
Technologická služba | An explicitly defined exposed technology behavior (ArchiMate). A technical capability required to provide enabling infrastructure that supports the delivery of applications (TOGAF). | Explicitně definované chování exponované technologie (ArchiMate). Technická schopnost vyžadovaná k zajištění aktivační infrastruktury, která podporuje dodávání aplikací (TOGAF). |
Technologická funkce | A collection of technology behavior that can be performed by a node. | Souhrn technologického chování, které může provádět uzel. |
Technologický proces | A sequence of technology behaviors that achieves a specific outcome. | Posloupnost technologického chování, které dosahuje konkrétního výsledku. |
Technologická interakce | A unit of collective technology behavior performed by (a collaboration of) two or more nodes. | Jednotka kolektivního technologického chování prováděná ve spolupráci dvou nebo více uzlů. |
Technologická událost | A technology behavior element that denotes a state change. | Prvek technologického chování, který označuje změnu stavu. |
Artefakt | A piece of data that is used or produced in a software development process, or by deployment and operation of a system. | Část dat, která se používají nebo vytvářejí v procesu vývoje softwaru nebo nasazením a provozováním systému. |
Technologická komponenta | An encapsulation of technology infrastructure that represents a class of technology product or specific technology product (TOGAF only). | Modeluje se jako Uzel (ArchiMate) |
Interpretace metamodelu technologické architektury
Typy prvků metamodelu technologické architektury zatím nemají interpretaci.
Metamodel komunikační a fyzické infrastruktury (KI)
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 nebo bude součástí pohledu čtyřvrstvé architektury eGovernmentu.
Po rozšíření standardu ArchiMate o prvky fyzického světa (non-IT) jsou tyto prvky součástí této architektonické domény NAR, neboť velmi blízce odpovídající jejímu původnímu účelu v rámci vize čtyřvrstvé architektury.
Definice prvků metamodelu fyzické architektury
V tabulce12) jsou uvedeny pouze definice prvků metamodelu z vrstvy fyzické architektury ArchiMate, protože pro prvky komunikační architektury se v plné míře použijí koncepty technologické architektury z předchozí části, s výjimkou jejich případné specializace, viz níže.
Název typu prvku | Definice typu prvku | Definice NAR |
---|---|---|
Vybavení/ Nástroj | One or more physical machines, tools, or instruments that can create, use, store, move, or transform materials. | Jeden nebo více fyzických strojů, nebo nástrojů, které mohou vytvářet, používat, ukládat, přesouvat nebo transformovat materiály. Pro NAR zejména ne-IT aktivní technologické prvky (nábytek, regály apod.) |
Budova | A physical structure or environment. | Fyzická struktura nebo prostředí. Pro NAR zejména budovy (například datových center) a stavební a vybavovací technologie (výtahy, klimatizace,..). |
Distribuční cesta | A physical network used to transport materials or energy. | Fyzická síť používaná k přepravě materiálů nebo energie. |
Materiál | Tangible physical matter or physical elements. | Hmatatelná fyzická látka nebo fyzikální prvky. |
Interpretace metamodelu komunikační a fyzické architektury
Typy prvků metamodelu komunikační a fyzické architektury zatím nemají interpretaci.
Specializace prvků metamodelu komunikační infrastruktury
Pokud bude potřeba zdůraznit na úrovni metamodelu odlišnost komunikační infrastruktury, budou moci být všechny použité koncepty metamodelu tzv. specializovány, viz obr. níže.
Pro běžné použití ve zde výše uvedených typech angažmá se ale specializace pro prvky technologické infrastruktury nepředpokládá a nevyžaduje.
Metamodel architektury strategie a směřování (MA)
Strategická architektura dle NAR je první, nejdůležitější a aktuálně nejobsažnější doménou z oblasti jednotlivých motivačních architektur – vertikálních domén.
Spojuje v sobě motivační architekturu dle TOGAF13) a tzv. motivační a strategickou14) vrstvu dle ArchiMate. To je důvodem, proč jsou v metamodelu domény strategicke a směřování v NAR kombinovány prvky více barev.
Metamodel neobsahuje všechny možné vazby, protože každý prvek v motivačním rozlišení může být agregací/specializací prvku stejného typu (např. cíl se může agregovat na dílčí cíle).
Definice prvků metamodelu architektury strategie a směřování
Tabulka15) s definicemi prvků metamodelu architektury strategie a směřování
Název typu prvku | Definice typu prvku | Definice NAR |
---|---|---|
Zainteresovaný | The role of an individual, team, or organization (or classes thereof) that represents their interests in the outcome of the architecture. | Jednotlivec, tým nebo organizace, která má zájem na přínosu architektury. |
Motivátor, vliv | An external or internal condition that motivates an organization to define its goals and implement the changes necessary to achieve them. | Externí nebo interní vlivy, které motivují organizaci k definování cílů a k implementaci změn pro jejich dosažení. |
Zhodnocení vlivu | The result of an analysis of the state of affairs of the enterprise with respect to some driver. | Výsledek analýzy stavu úřadu vzhledem k dopadu určitého motivátoru. |
Strategický cíl | A high-level statement of intent, direction, or desired end state for an organization and its stakeholders (ArchiMate). A high-level statement of intent or direction for an organization. Typically used to measure success of an organization (TOGAF). | Formulace zájmu, směru nebo cílového stavu na vysoké strategické úrovni používaný ke sjednocení přístupu organizace a zainteresovaných. Typicky se užívají k měření úspěchu organizace. |
Výstup / Výsledek | An end result that has been achieved. | Konečný výsledek, kterého má být dosaženo pro naplnění strategického cíle. |
Princip | A qualitative statement of intent that should be met by the architecture (ArchiMate). A qualitative statement of intent that should be met by the architecture. Has at least a supporting rationale and a measure of importance (TOGAF). | Kvalitativní tvrzení, které by mělo být naplněno implementovanou architekturou. Princip obsahuje zdůvodnění a míru důležitosti. |
Požadavek | A statement of need that must be met by the architecture (ArchiMate). A quantitative statement of business need that must be met by a particular architecture or work package (TOGAF). | Vyjádření potřeby, která musí být naplněna cílovou architekturou. |
Omezení | A factor that prevents or obstructs the realization of goals. | Faktor, který brání nebo ztěžuje realizaci cílů. |
Význam | The knowledge or expertise present in, or the interpretation given to, a core element in a particular context. | Znalost nebo odbornost obsažené v základním prvku architektury nebo jeho interpretace v konkrétním kontextu. |
Hodnota | The relative worth, utility, or importance of a core element or an outcome. | Relativní hodnota, užitečnost nebo důležitost základního prvku nebo výsledku. |
«Cíl, úkol» (Objective) | A time-bounded milestone for an organization used to demonstrate progress towards a goal (TOGAF only) | Časově ohraničený milník (úkol) pro organizaci sloužící k prokázání pokroku směrem k cíli (zatím pouze TOGAF). |
Směr změny | An approach or plan for configuring some capabilities and resources of the enterprise, undertaken to achieve a goal (ArchiMate). Direction and focus provided by strategic goals and objectives, often to deliver the value proposition characterized in the business model (TOGAF). | Přístup nebo plán (iniciativa) pro zlepšení vybraných schopností a zdrojů organizace za účelem dosažení strategického cíle. |
Schopnost | An ability that an active structure element, such as an organization, person, or system, possesses (ArchiMate). A particular ability that a business may possess or exchange to achieve a particular purpose. A business-focused outcome that is delivered by the completion of one or more work packages. (TOGAF). | Schopnost organizace nebo jejích částí vytvářet hodnotné výstupy. |
Zdroj | An asset owned or controlled by an individual or organization. | Majetek ve vlastnictví nebo pod kontrolou jednotlivce nebo organizace. |
Hodnotový řetězec | A representation of an end-to-end collection of value-adding activities that create an overall result for a customer, stakeholder, or end-user (TOGAF only). | Reprezentace komplexní kolekce činností s přidanou hodnotou, které vytvářejí celkový výsledek pro zákazníka, zainteresovaného nebo koncového uživatele (zatím pouze TOGAF). |
Interpretace metamodelu architektury strategie a směřování
Metamodel domény strategie a směřování aktuálně neobsahuje koncepty pro všechny součásti strategického řízení. Takovými nyní ještě v NAR nezachycenými objekty jsou:
- Poslání organizace
- Vize organizace
Oba prvky jsou ryzí vnitřní motivací organizace, proto se více než k čemukoli jinému přikláníme k doporučení modelovat je pomocí prvku „Hodnota“, v tomto případě společná, sdílená hodnota pro všechny kategorie zainteresovaných v organizaci. Oba prvky ale představují pojem s jedinečným výskytem v každé organizaci (organizace poslaní a vizi formulovánu má nebo nemá), proto navrhujeme tyto objekty vůbec nemodelovat a do modelu z nich odvodit až prvky obsahově významnější, jako jsou cíle a principy.
Poznámka: Každá změna, v kterékoli z horizontálních domén architektury by měla mít svou motivaci, vycházet ze strategie a směrování, očekávané výkonnosti, nového rizika nebo nové regulace předpisem. Proto lze v modelu úřadu očekávat prvky vertikálních, motivačních domén rozdělené i podle horizontálních domén. Tak najdeme například aplikační drivery, aplikační cíle, aplikační směry aktivit, aplikační výstupy, aplikační principy a aplikační architektonické požadavky.
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 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í16)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:
- Hodnota změny pro zainteresované
- Hodnota produktu / služby pro klienty
Typ prvku „Hodnotový řetězec“ je zatím pouze součástí standardu TOGAF, ale je očekáván i pro standard ArchiMate 3.1.
Metamodel výkonnostní architektury (PA)
Výkonnostní architektura NA VS ČR zatím nemá definované žádné specifické prvky metamodelu. Předpokládáme, že v následujících verzích jazyka ArchiMate se objeví volnější použití objektu Metrika (KGI17), KPI18) (zejména TCO19)), PPI20), PI) než je tomu v současnosti jakožto měřítko výsledku vyhodnocení potřeby, motivátoru, v motivační architektuře.
Doposud každý objekt modelu může mít metriky přiřazeny v profilu atributů. Typy ukazatelů výkonnosti se zatím nemodelují.
Architektura výkonnosti, kvality a zodpovědnosti by měla sloužit na podporu řízení výkonnosti, kvality a zodpovědnosti v orgánech veřejné správy. Řízení výkonnosti, kvality a zodpovědnosti ve veřejné správě je spojeno zejména se snahou organizace dělat správné věci správně, tj. kvalitně, efektivně, hospodárně a včas.
Základní tři sady ukazatelů se obvykle ukrývají pod akronymem 3E:
- Hospodárnost (Economy) – vztahuje se k nákladům na zdroje pro spotřebovávané vstupy. Metriky hospodárnost se používají k posouzení, zda za pořízení nezbytných zdrojů je placena odpovídající cena.
- Účinnost (Efficiency) – účinnost představuje vztah mezi vstupy a výstupy, je poměrem dosažených výstupů ke spotřebovaným vstupům. Účinnost je výrazem dimenze „dělat věci správně“ a ukazuje na výkonnost ve smyslu způsobu, jakým je činnost uskutečňována.
- Účelnost (Effectiveness) – je výrazem míry jakou produkované výstupy vedou k očekávaným výsledkům. Metriky účelnosti se zaměřují na sílu vztahu mezi provedenou intervencí a dosaženým výsledkem. Účelnost je výrazem dimenze „dělat správné věci“ a ukazuje na výkonnost ve smyslu volby činnosti, která je uskutečňována.
S tím souvisí i tzv. Logický model řízení výkonnosti, vypracovaný na základě podkladů Evropského účetního dvora a MF ČR:
Pro řízení výkonnosti, kvality a zodpovědnosti platí obdobné paradigma jako níže u bezpečnosti:
Není možné řídit výkonnost a kvalitu prvků systému úřadu a zodpovědnost za ně, bez toho, že bychom je dobře poznali a porozuměli jim, například prostřednictvím architektury úřadu.
Doména výkonnosti k základním objektům architektury úřadu přidává několik specifických prvků (cílů, ukazatelů, vyhodnocení, opatření). Ty jsou do značné míry modelovatelné pomocí konceptů byznys a motivační architektury, jejich specializací nebo do budoucna samostatných specifických konceptů, obdobně jako u bezpečnostní architektury.
Definice prvků metamodelu architektury výkonnosti
Tabulka21) s definicemi prvků metamodelu architektury výkonnosti
Název typu prvku | Definice typu prvku | Definice NAR |
---|---|---|
«Metrika» (Measure) | An indicator or factor that can be tracked, usually on an ongoing basis, to determine success or alignment with objectives and goals (TOGAF only). | Ukazatel nebo faktor, který lze sledovat, obvykle průběžně, k určení úspěchu nebo souladu s cíli a cíli (pouze TOGAF). |
«Kvalita služby» (Service Quality) | A preset configuration of non-functional attributes that may be assigned to a service or service contract (TOGAF only). | Přednastavená konfigurace nefunkčních atributů, které mohou být přiřazeny ke smlouvě o službě nebo službě (pouze TOGAF). |
Ukazatel výkonnosti | PI, KPI, PPI | Není obsažen v jazyce ArchiMate |
Znak kvality | Není obsažen v jazyce ArchiMate | |
Nejakost | Není obsažen v jazyce ArchiMate | |
Opatření |
Interpretace prvků metamodelu architektury výkonnosti
Mnohé z prvků se budou opakovat z předchozí domény strategie a směřování, ale při svém použití v modelu budou mít jiný účel. Tak například Koncept „Zdroj“ znamená v architektuře výkonnosti, kvality a zodpovědnosti „zdroj pro zajištění činnosti“.
Metamodel bezpečnostní architektury (SA)
Bezpečnostní architektura NA VS ČR zatím nemá definované žádné specifické prvky metamodelu. Předpokládáme, že jimi budou později rizika a opatření spojená s hlavními objekty modelu.
Lze předpokládat podle Whitepaperu The Open Group a vývoje některých modelovacích nástrojů, že jazyk ArchiMate a standard TOGAF v budoucnu přidá tyto koncepty
Specifické koncepty bezpečnosti a řízení rizik se dají v aktuálním standardu ArchiMate modelovat s pomocí konceptů byznys a motivační architektury nebo jejich specializovaných stereotypů, viz schéma:
Diagram mimo jiné zdůrazňuje základní princip bezpečnostní architektury:
Vše, co je součástí systému organizace a co modelujeme v ostatních doménách, může být ohroženo a je potřeba to chránit, ale současně téměř vše z toho je současně pro jiné věci prostředkem takové ochrany.
Z toho také plyne, že dobrý model základních22) prvků architektury úřadu je nezbytným předpokladem a vstupem její bezpečnostní architektury.
Přehled potřebných prvků bezpečnostní architektury a jejich lokalizace
Tabulka23) s definicemi prvků metamodelu bezpečnostní architektury
Původní název | Generický překlad |
---|---|
Threat | Hrozba/ohrožení |
Threat agent / actor | Prostředek/aktér hrozby/ohrožení |
Threat event | Událost hrozby/ohrožení |
Loss event | Událost ztráty |
Risk/security driver | Bezpečnostní motivátor/vliv |
Risk | Riziko |
Vulnerability | Zranitelnost |
Control objective | Kontrolní cíl |
Security principle | Bezpečnostní princip |
Control measure | Opatření |
Security domain | Bezpečnostní doména |
Definice prvků metamodelu bezpečnostní architektury
Tabulka24) s definicemi prvků metamodelu bezpečnostní architektury
Název typu prvku | Definice typu prvku | Definice NAR |
---|---|---|
Hrozba/Ohrožení | A Threat is a negative scenario you want to avoid. | Hrozbu/ohrožení lze považovat za negativní scénář, kterému se chcete vyhnout. |
Prostředek hrozby /ohrožení | The term Threat Agent is used to indicate an individual or group that can manifest a threat. It is fundamental to identify who would want to exploit the assets of a company, and how they might use them against the company. The the person, actor, entity, or organization that is initiating the given threat scenario. Threat agent is modeled with the business actor construct, but other active structure element can be used (e.g. business role, application component, etc.) | Pojem „Prostředek hrozby/ohrožení“ se používá k označení jednotlivce nebo skupiny, která může znamenat hrozbu. Je zásadní určit, kdo by mohl chtít využít aktiv organizace, a jak by je mohl použít proti ní. Osoba, aktér, entita nebo organizace, která spouští daný scénář hrozby. „Prostředek hrozby/ohrožení“ je modelován pomocí typu prvku „byznys aktér“, ale lze použít i jiný aktivní prvek struktury (např. byznys role, aplikační komponenta atd.) |
Událost znamenající hrozbu /ohrožení | A Threat (event) is a negative event that can lead to an undesired outcome, such as damage to, or loss of, an asset. Threats can use—or become more dangerous because of—a vulnerability in a system. Threat event (event with the potential to adversely impact an asset) as well as loss event (any circumstance that causes a loss or damage to an asset) are modeled with the business event construct and are considered as a specialization of it. | Hrozba/ohrožení (událost) je negativní událost, která může mít nežádoucí dopad, jako jsou např. škody na majektu či jeho ztráta. Útočník může využít zranitelnost systému a díky této zranitelnosti může být hrozba/ohrožení ještě nebezpečnější Událost znamenající hrozbu/ohrožení (tj. událost s potenciálem nepříznivého dopadu na aktivum) i událost ztráty (jakákoli okolnost, která způsobí ztrátu nebo poškození aktiva) jsou modelovány pomocí typu prvku byznys událost, resp. jeho specializace. |
Událost ztráty | A Loss Event is a circumstance that produces the loss and harm impacts from actual events and reflect the organisation's own experience. | “Událost ztráty“ je okolnost, která způsobí ztrátu nebo škody a odráží vlastní zkušenosti organizace. |
Bezpečnostní motivátor /vliv | Risk / security driver are the criteria by which risks are analyzed and are represented with the driver construct. | Bezpečnostní motivátor /vliv jsou kritéria, podle nichž jsou analyzována rizika. Je reprezentován prvkem typu motivátor. |
Riziko | A chance of something bad happening combined with how bad it would be if it happened. A Risk is a negative scenario you want to avoid, essentially the combination of its Probability and Impact. Risk is also modeled with the assessment construct and considered as a specialization of it. | Pravděpodobnost, že dojde k něčemu nežádoucímu. Riziko je negativní scénář, kterému se chce organizace vyhnout. Jedná se o kombinaci jeho pravděpodobnosti a dopadu. Riziko je modelováno pomocí typu prvku „hodnocení“ a je považováno za jeho specializaci. |
Zranitelnost | Vulnerabilities are simply weaknesses in the system, vulnerabilities are what make Threats possible and/or more significant. Vulnerability is modeled as a specialization of an assessment in the ArchiMate language, because considered as the result of analyzing the weaknesses of elements in the architecture. | Zranitelnosti představují slabiny v systému, jsou tím, co způsobuje, že jsou hrozby možné nebo jsou významnější. Zranitelnost je modelována pomoci specializace typu prvku Zhodnocení vlivu, protože je považována taktéž za výsledek analýzy slabin prvků architektury. |
Kontrolní cíl | Risk control objective and security control objective are specialization of the objective construct and aim at mitigating risks. They are designed from risks and risk/security drivers and further refined through security requirement and principle. | Kontrolní cíle rizik a bezpečnosti jsou specializací typu prvku cíl, jejich úkolem je zmírňovat rizika. Jsou zpřesňovány pomocí specializovaných typů prvků bezpečnostní princip a bezpečnostní požadavek. |
Bezpečnostní princip | Security principle is considered here as a synonym of security policy and is modeled with the principle construct. | Bezpečnostní princip je zde považován za synonymum bezpečnostní politiky a je modelován s pomocí typu prvku princip. |
Opatření | Security requirement and control measure are two specializations of the requirement construct, a control measure being more specific (i.e. close to the implementation) than a security requirement. | Bezpečnostní požadavek a kontrolní opatření jsou dvě specializace typu prvku požadavek, přičemž kontrolní opatření je specifičtější (tj. blíže implementaci) než bezpečnostní požadavek |
Interpretace metamodelu bezpečnostní architektury
Typy prvků metamodelu bezpečnostní architektury zatím nemají interpretaci.
Metamodel architektury standardizace, shody s předpisy a udržitelnosti
Oblast standardizace a udržitelnosti NA VS ČR zatím nemá v mezinárodních standardech definované žádné specifické prvky metamodelu. Předpokládáme, že dle potřeb budou využity specializované prvky byznys a motivační architektury, ve smyslu cílů, požadavků či omezujících podmínek.
Vedle toho bude obsah standardizace vyjadřován prohlášením každého jednotlivého prvku architektury nebo jejich kombinace za architektonický stavební blok (ABB), za stavební blok řešení (SBB) nebo za architektonický vzor (pattern).
Tato doména se v souladu se svým názvem zaměřuje na oblasti řízení, které regulují činnost úřadů (OVS), a to konkrétně:
- Shoda s předpisy. Podle Ústavy a ZLPS smí veřejné správy v oblasti výkonu veřejné moci konat jenom to, co je jí výslovně předepsáno zákonem, respektive podzákonnými předpisy.
- Standardizace. Veřejná správa omezuje prostor pro samostatné rozhodpování, a tím i komplexitu svého prosředí tím, že „dobrovolně“ vydává standardy (procesů, IT, služeb, bezpečnosti apod.) nebo přebírá nezávislé externí standardy (ISO, ČSN apod.).
- Udržitelnost. Veřejná správa si pro oblasti své regulace (agendy) i pro svoji vlastní organizaci a interní činnosti stanovuje kritéria (limity) udržitelnosti, a to v oblasti ekonomické, sociální a environmentální. Typickou iniciativou v této oblasti je CSR25).
Metamodel shody s předpisy
Základním objektem shody s předpisy je objekt „právní předpis“. Tento objekt není standardní součástí specifikace ArchiMate, proto NAR navrhuje používat specializaci objektu „Kontrakt“ do podoby: «Předpis». Vše ostatní, co tvoří strukturu systému úřadu, musí být ve shodě s právními předpisy. Pokud by tomu tak nebylo, jde o nežádoucí stav. Míru shody není třeba vyjadřovat dalšími koncepty, v rámci NAR stačí objekty modelu, typicky agendy nebo služby, propojit asociační vazbou s objekty «předpis», viz následující obrázek:
Objekty předpis mohou být libovolně specializovány/agregovány, přes dílčí úrovně předpisu: článek, paragraf, odstavec, písmeno. Jinou specializací je struktura předpisů nižší právní síly (prováděcí právní předpisy, podzákonné právní normy či sekundární právní předpisy), tj. typicky vyhlášky a metodické pokyny. Pro tyto druhy specializace obsahu konceptu «předpis» je v této verzi NAR nežádoucí vytvářet další stereotypy.
Metamodel architektury standardizace
V oblasti standardizace se vyskytují standardy dvou typů:
- Standard jako dokument, který vyjadřuje vůli signatářů (autorů standardu) definovat a užívat některé „věci“ jednotně stejně.
- Prohlášený standard, který vzniká tak, že nějakou existující věc (typicky typ výrobku, formát dat apod.) z modelu své vlastní architektury prohlásím standardem.
V metamodelu architektury standardizace je potřebné zachytit jediný nový prvek, a to objekt představující obraz standardizačního dokumentu, například ISO 27000. Pro takovéto objekty navrhuje NAR také specializaci konceptu jazyka ArchiMate „kontrakt“ do podoby «standard», viz následující obrázek:
Metamodel architektury dlouhodobé udržitelnosti
Architektura dlouhodobé udržitelnosti pro NA VS ČR zatím nemá definované žádné specifické prvky metamodelu. Předpokládáme, že v následujících verzích jazyka ArchiMate se objeví volnější použití objektu Metrika (KPI) než je tomu v současnosti jakožto měřítko výsledku vyhodnocení potřeby, motivátoru, v motivační architektuře. Předpokládáme, že Metrika bude vhodným konceptem i pro architekturu dlouhodobé udržitelnost.
Dalšími vhodnými atributy mohou být například Architektonický princip, Architektonický požadavek nebo Omezující podmínka, případně jejich specializované stereotypy.
Interpretace metamodelu architektury shody s předpisy, standardizace a dlouhodobé udržitelnosti
V této doméně zatím není připravena žádná další interpretace.
Metamodel architektury implementace a migrace
Definice prvků metamodelu architektury implementace a migrace
Tabulka26) s definicemi metamodelu architektury implementace a migrace
Název typu prvku | Definice významu typu prvku | Definice NAR |
---|---|---|
Balíček práce | A series of actions identified and designed to achieve specific results within specified time and resource constraints (ArchiMate). A set of actions identified to achieve one or more objectives for the business. A work package can be a part of a project, a complete project, or a program (TOGAF). | Řada akcí identifikovaných a navržených k dosažení konkrétních výsledků pro naplnění jednoho nebo více cílů podniku, v rámci stanovených časových a zdrojových omezení Pracovní balíček může být součástí projektu, celým projektem nebo programem. |
Předmět dodávky /plnění | A precisely-defined outcome of a work package. | Přesně (formálně, smluvně) definovaný výsledek pracovního balíčku. |
Implementační událost | A behavior element that denotes a state change related to implementation or migration. | Prvek chování, který označuje změnu stavu související s implementací nebo migrací. Typicky jde o klíčové milníky implementace. |
Stav architektury | A relatively stable state of the architecture that exists during a limited period of time. | Relativně stabilní stav architektury, který existuje po omezenou dobu. Přechodový (tranzitní) stav (Plateau) architektury, je takový stav, ve kterém byly dokončeny plánované architektonické změny a architektura opět přináší byznys hodnotu. |
Rozdíl/nedostatek | A statement of difference between two plateaus (ArchiMate). A statement of difference between two states. Used in the context of gap analysis, where the difference between the Baseline and Target Architecture is identified (TOGAF). | Vyjádření rozdílu mezi stávající a cílovou (nebo přechodovou) architekturou. |
Interpretace metamodelu architektury implementace a migrace
Jako v základních (core) vrstvách architektury úřadu lze i v architektuře implementace a migrace (IM) rozlišit objekty podle jednotlivých aspektů jazyka ArchiMate, s výjimkou aktivních prvků.
Aktivní prvky IM úřadu
Architektura implementace a migrace nemá vlastní specifické aktivní prvky, těmi jsou prvky byznys architektury.
Prvky chování IM úřadu
Základním prvkem metamodelu architektury Implementace a migrace je Balíček práce. Je řazen mezi aktivní prvky a představuje libovolně velkou část aktivit, kterými se realizuje změna od stávající k cílové architektuře. Balíčkem práce je nejčastěji projekt, ale směrem „dolů“ to může být fáze projektu, podprojekt, jeho dílčí proud nebo jenom jedna aktivita.
Směrem „nahoru“ jsou projekty typicky seskupovány pro koordinovanou dodávku hodnoty benefitů do podprogramů a programů
Implementační událost představuje milník v projektově orientovaném implementačním snažení. Může být vázána na jinou událost v modelu systému úřadu.
Pasivní prvky IM úřadu
Základním pasivním prvkem je výstup projektového úsilí, tedy tzv. výstup či plnění (deliverable). Každý výstup je dílčím nebo celkovým naplněním jednoho nebo více zjištěných a plánovaných rozdílů mezi stávajícím a cílovým stavem nějakého základního prvku (gap), který představuje druhý pasivní prvek metamodelu.
Kompozitní prvky IM úřadu
Kompozitním prvkem této vrstvy, který v sobě zahrnuje řadu ostatních je tzv. stav architektury (plateau). V metodice TOGAF se jedná o tzv. cílovou nebo přechodnou architekturu, tj. o takovou kombinaci prvků a vazeb architektury systému, která je funkční a ve svém stavu přináší úřadu nějakou plánovanou byznys hodnotu.
Pokud projekt skončí nedodělaný, nejedná se v žádném případě o přechodnou architekturu. Přechodná architektura je stav řízený, plně funkční a uspokojivý i v případě, že by se již žádná další změna neuskutečnila.
Kompozitní objekty metamodelu
Definice kompozitních prvků metamodelu architektury
Tabulka27) s definicemi kompozitních prvků metamodelu architektury
Název typu prvku | Definice typu prvku | Definice NAR |
---|---|---|
Seskupení | The grouping element aggregates or composes concepts that belong together based on some common characteristic. | Prvek seskupování agreguje nebo komponuje prvky, které patří k sobě na základě nějaké společné charakteristiky. |
Umístění/Lokace | A location is a place or position where structure elements can be located or behavior can be performed. | Místo je místo nebo pozice, kde mohou být umístěny strukturní prvky, nebo může být provedeno chování. |
Interpretace kompozitních prvků metamodelu
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 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.
Pro umisťování prvků (jako datových center či kontaktních míst) bude v jednolivých konkrétních, centrálně koordinovaných angažná požadováno umístění ve shodě s adresním bodem (ověřitelné v RUIAN).
Obecné objekty metamodelu mimo vrstvy ArchiMate
V této části jsou uvedeny prvky, které nejsou předmětem standardu modelovacího jazyka ArchiMate, přesto jsou z pohledu standardu TOGAF nebo budoucího rozvoje NAR důležité.
Definice obecných prvků metamodelu architektury
Tabulka s definicemi obecných prvků metamodelu architektury.
Název typu prvku | Definice typu prvku | Definice NAR |
---|---|---|
Služba (Service) | An element of behavior that provides specific functionality in response to requests from actors or other services. A service delivers or supports business capabilities, has an explicitly defined interface, and is explicitly governed. Services are defined for business, information systems, and platforms (TOGAF). | Prvek chování, který poskytuje specifickou funkčnost v reakci na požadavky aktérů nebo jiných služeb. Služba poskytuje nebo podporuje byznys schopnosti, má explicitně definované rozhraní a je explicitně řízena. Služby jsou definovány pro byznys, informační systémy a platformy. |
Datová entita (Data entity) | An encapsulation of data that is recognized by a business domain expert as a thing. Logical data entities can be tied to applications, repositories, and services and may be structured according to implementation considerations (TOGAF only). | Zapouzdření dat o něčem, co odborník na byznys doménu považuje za věc. Logické datové entity mohou být spojeny s aplikacemi, úložišti a službami a mohou být strukturovány podle implementačních úvah. |
Předpoklad (Assumption) | A statement of probable fact that has not been fully validated at this stage, due to external constraints. For example, it may be assumed that an existing application will support a certain set of functional requirements, although those requirements may not yet have been individually validated (TOGAF only). | Prohlášení o pravděpodobné skutečnosti, která nebyla v této fázi v důsledku vnějších omezení plně ověřena. Lze například předpokládat, že stávající aplikace bude podporovat určitý soubor funkčních požadavků, i když tyto požadavky ještě nebyly individuálně validovány. |
Obdobně jako služba by se daly společně definovat i pojmy funkce, proces, událost, komponenta - všechny se vyskytující ve více vrstvách buď TOGAF, ArchiMate nebo obou. Je důležité vnímat jejich obecný charakter a význam bez ohledu na vrstvy a architektury, i jejich specifické použití uvnitř vrstvy architektury.
K definici služby je potřebné doplnit, že jakoukoli službu jakékoli vrstvy formálně poskytuje vždy zodpovědná fyzická nebo právnická osoba, nebo její část, která je k poskytování služby oprávněna, zmocněn zákonem nebo smlouvou nebo vnitřním předpisem. To platí i pro služby IS a technologií.
Pro dobré pochopení toho, co je vlastně služba, je přidána ještě definice obecné služby, upravené do pojmů veřejné správy, více tako v NAP:
Služba je funkce úřadu, pokud je poskytnutá konkrétním poskytovatelem konkrétnímu příjemci služby podle předem dané formální dohody (zákon, vyhláška, dohoda o úrovni služby - SLA) tak, že přináší příjemci vnímanou hodnotu, za kterou by byl ochoten zaplatit přiměřenou cenu (nebo platit daně).
Služba je určena vždy konkrétnímu klientovi, je výsledkem funkce nebo procesu. Služba veřejné správy je vždy spojena konkrétním právem nebo povinností klienta vůči veřejné správě a spočívá ve výkonu funkcí úřadu a úředníka, vedoucích k umožnění a usnadnění dosažení tohoto práva nebo splnění této povinnosti klientem.
Typy vazeb mezi objekty metamodelu
Typy vazeb NA VS ČR se plně shodují s aktuálním standardem jazyka ArchiMate, viz Rámec obsahu a výstupu architektur.
Doporučené příklady vazeb
Národní architektonický rámec povoluje použítí všech vazeb popsaných v této části, avšak v rámci zjednodušení doporučuje použití následujících vazeb:
- Kompozice
- Agregace
- Přiřazení
- Realizace
- Obsluhuje
- Přístup
- Ovlivnění
- Asociace
Kompozice
Kompozici je možné vyjádřit jak mimo komponovaný prvek, tak i zanořením (hnízdovým diagramem28). Komponovat je možné vždy prvky stejného typu a stejně tak i jiné, typicky rozhraní s aktivními prvky, či zařízení a uzel, protože jde o podtřídy. Komponovaný prvek může být součástí pouze jedné kompozice.
Agregace
Agregaci lze podobně jako kompozici vyjádřit mimo agregovaný prvek, tak i zanořením. Agregovat lze vždy prvky stejného typu a stejně tak i jiné. Princip je podobný jako u kompozice s tím rozdílem, že agregovaný prvek může být součástí vícero agregací.
Ačkoli jazyk ArchiMate teoreticky připouští agregaci u libovolného typu prvku, z hlediska TOGAF to u některých nedává smysl, zejména u aplikací (zde je to tedy chybně). Jde o to, že aplikační komponenta dle TOGAF je samostatně implementovatelnou29) jednotkou aplikačního SW, říkáme, že jde zapnout/vypnout. Pokud by komponenta obsahovala zase komponentu, pak to není splněno, fyzicky to nejde. Proto agregaci komponent NAR nedoporučuje.
Přiřazení
Přiřazení lze podobně jako agregaci a kompozici vyjádřit mimo přiřazený prvek, tak i zanořením. Přiřazení je vždy vazba mezi prvky chování a aktivními prvky s výjimkou aktérů a rolí.
Realizace
Realizaci je možné také zanořit, ale vzhledem k vyjádření poskytování či vytváření jiného prvku je vhodnější ji mít vždy jako oddělenou. Nejčastěji se vazba využívá při vytváření služeb (vnějšího chování) z funkcí (vnitřního chování).
Slouží / obsluhuje
Vazbu slouží / obsluhuje není možné vnořit a využívá se primárně při přechodech mezi vrstvami, ale třeba také například mezi komponentami nebo službami na téže vrstvě.
Přístup
Přístup není možné vnořit a využívá se pro vztah prvků chování k pasivním prvkům (přístup, čtení, zápis atp.).
Ovlivnění
Ovlivnění je vždy mezi prvkem motivace a jiným prvkem. Jako jediná vazba obsahuje míru své vlastní síly (pozitivní či negativní) a není možné ji vnořit.
Asociace
Asociace/ souvislost je neurčitá vazba, kterou je možné využít mezi všemi prvky, pokud se nehodí žádná jiná vazba.
Nedoporučené příklady vazeb
Vazba agregace a kompozice
Pozor na kompozitní a agregační vazbu u věcí, které nejsou virtuálními, abstraktními pojmy, ale skutečně existují, mají svá evidenční a sériová čísla.
Příkladem je nevhodné použití agregační nebo kompozitní vazby u aplikačních komponent. U nich definice, zejména dle TOGAF, předpokládá, že komponenta existuje, lze ji instalovat, zapnout/vypnout. Takové komponenty se ale nemohu vkládat do sebe jako mističky, takto existovat může jenom jedna z nich, jinak by definiční podmínka nebyla splněna. Abstraktní logická, nadřazená komponenta už by měla být kategorií (Seskupením) nebo Spoluprací. Nižší prvek, obsah komponenty je její funkcí, představuje to, co komponenta dovede.
V obrázku je problematické jak vyjádření pomocí dvou „boxů“ a vazby, tak vlevo vyjádření prostřednictvím hnízdového diagramu (s neznámým typem vazby, resp. bez ohledu na typ vazby).
Atributy prvků metamodelu
U každého výskytu prvku metamodelu, zachyceného v modelu architektury úřadu budou evidovány sady nebo také profily vlastností, tzv. atributů.
Některé atributy budou tzv. řídící atributy, tj. budou sloužit pro řízení a governance tvorby, správy a užití modelů. Příkladem řídících atributů je klasifikace modelů, pohledů a prvků, viz Příloha 1 – Seznam atributů prvků metamodelu a Příloha 2 – Klasifikace souborů, modelů a pohledů.
Všechny ostatní atributy budou tzv. věcné atributy, tj. budou sloužit na podporu užití modelů reálné architektury úřadů v praxi, zejména pro rozhodování a zlepšování. Například pro správu celého aplikačního portfolia úřadu. Model se pak díky atributům prvků stává nositelem inventarizačních Katalogových listů těchto prvků, více v Metodách řízení ICT VS ČR.
Mnohé atributy uvedené v NAR pocházejí z příloh standardu TOGAF, další z praxe pilotních projektů architektury VS, předcházejících vydání NAR.
Pilotních projektů, pracujících s atributy bohužel před vydáním první verze NAR neproběhl dostatek, není co zobecnit do nejlepší praxe - proto budou atributy jednotlivých typů prvků metamodelu publikovány postupně v dalších vydáních NAR.
Některé v NAR definované atributy objektů modelu budou pro modely architektury úřadů povinné, ostatní zde definované jsou volitelně doporučené a další atributy budou úřady moci podle své potřeby přidávat ve své místní úpravě architektonického rámce úřadu.
Všechny identifikované instance objektů architektury úřadu i s jejich atributy musí být zachyceny primárně formou katalogu prvků. Proto budou sady atributů představeny postupně u jednotlivých katalogů a souhrnně v samostatné Příloha 1 – Seznam atributů prvků metamodelu.
Všechny typy prvků metamodelu mají základní sadu atributů identickou, společnou:
Název typu atributu | Definice významu typu atributu |
---|---|
Sada: Stereotyp | |
Stereotyp | |
Sada: Identifikace prvku | |
Lokální ID prvku v modelu | |
Globální ID prvku v modelu | |
Lokální ID prvku v primární evidenci OVS | Například inventární číslo v EkIS |
Globální ID prvku v primární evidenci státu | Pokud na centrální úrovni VS ČR (EU) existuje, například číslo ze základních registrů z ISoISVS apod. |
Sada: Obecný popis | |
Zkratka (kód) prvku | |
Název prvku | |
Popis prvku | |
Vlastník prvku | |
Stav prvku v modelu | |
Sada: Klasifikace prvku | |
Viz další části a samostatná Příloha č. 2. | |
Sada: Standardizace prvku | |
Standard | Ano/Ne |
Datum prohlášení standardu | |
Datum posledního přezkoumání standardu | |
Datum plánovaného přezkoumání standardu | |
Datum opuštění standardu | |
Vlastník standardu | |
Sada: životní cyklus prvku | |
Ve vývoji/ přípravě | |
Přechodná architektura | |
Datum od | |
Stav | Ano/Ne |
V užití | |
Po užití (výběhový) | |
Zastaralý | |
Práce s atributy v jednotlivých nástrojích modelování architektury, jejich přenos ve standardním formátu TOGAMEFF30) a jejich užití v centrálním repozitory musí být ověřeny v praxi. Výsledky se promítnou do úpravy předepsaných sad prvků a pravidel pro práci s nimi v dalších vydáních NAR.
Architektonické výtvory a výstupy
Modely, dokumenty a artefakty (výtvory)
V průběhu procesu tvorby architektury (TOGAF ADM) vznikají „Dodávané výstupy“ či předměty plnění (orig. „deliverable“). Tyto výstupy jsou charakteristické tím, že jsou výslovně (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í.
Každý z dodaných výstupů obsahuje alespoň jeden artefakt, reálně však několik. Artefaktem, tj. výtvorem architekta 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í jednorozměrné seznamy identifikovaných prvků architektury a případných budoucích stavebních bloků.
- Matice – zobrazují dvourozměrné tabulky závislostí mezi alespoň dvěma typy prvků architektury.
- Diagramy – zobrazují prvky architektury a jejich vztahy 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é prvky, IT prvky a určité 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 následující Obrázek.
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 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
První tabulka31) představuje jejich původní název, generický překlad a specifický název pro NAR:
Původní název | Generický překlad | Úprava pro NAR | |
---|---|---|---|
Dodatelné výstupy dle TOGAF | Architecture Building Blocks | Stavební blok architektury | |
Architecture Contract | Architektonická smlouva | ||
Architecture Definition Document | Definiční dokument architektury | Model architektury úřadu | |
Architecture Principles | Architektonické principy | ||
Architecture Repozitory | Architektonické úložiště | ||
Architecture Requirements Specification | Specifikace architektonických požadavků | ||
Architecture Roadmap | Plán realizace architketury | ||
Architecture Vision | Architektonická vize | ||
Business Principles, Business Goals and Business Drivers | Byznys motivátory, cíle a principy | ||
Capability Assessment | Posouzení schopností | ||
Change Request | Změnový požadavek | ||
Communications Plan | Komunikační plán | ||
Compliance Assessment | Posouzení shody | ||
Implementation and Migration Plan | Plán implementace a migrace | ||
Implementation Governance Model | Model dohledu na implementaci | ||
Organizational Model for Enterprise Architecture | Organizační model pro EA | ||
Request for Architecture Work | Požadavek na architektonickou práci | ||
Requirements Impact Assessment | Posouzení dopadů požadavků | ||
Solution Building Blocks | Stavební blok řešení | ||
Statement of Architecture Work | Zadání architektonické práce | ||
Tailored Architecture Framework | Přizpůsobený architektonický rámec | ||
Informační koncepce OVS | |||
Žádost o stanovisko OHA | |||
K vybraným výstupům dle TOGAF postupně doplňuje NAR v praxi české veřejné správy užívané a s architekturou související dodávané výstupy.
Definice výstupů architektury
Druhá tabulka32) přináší vysvětlení významu a úlohy dokumentů:
Název typu výstupu | Definice typu výstupu | Význam pro NAR |
---|---|---|
Stavební blok architektury | A constituent of the architecture model that describes a single aspect of the overall model. | Složka modelu architektury, která popisuje jeden aspekt celkového modelu. |
Architektonická smlouva | Architecture Contracts are the joint agreements between development partners and sponsors on the deliverables, quality, and fitness-for-purpose of an architecture. Successful implementation of these agreements will be delivered through effective Architecture Governance. | Smlouvy o architektuře jsou společné dohody mezi vývojovými partnery a sponzory o dodávkách, kvalitě a vhodnosti architektury. Úspěšné provádění těchto dohod bude dosaženo prostřednictvím účinné správy architektury a dohledu na ni. |
Definiční dokument architektury | The Architecture Definition Document is the deliverable container for the core architectural artifacts created during a project and for important related information. The Architecture Definition Document spans all architecture domains (business, data, application, and technology) and also examines all relevant states of the architecture (baseline, transition, and target). | Dokument definice architektury je kontejner pro hlavní architektonické artefakty vytvořené během projektu a pro důležité související informace. Dokument definice architektury zahrnuje všechny domény architektury (byznys, data, aplikace a technologie) a také zkoumá všechny relevantní stavy architektury (výchozí stav, přechod a cílový stav). |
Architektonické principy | Set of generic Architecture Principles, including: ■ Business principles ■ Data principles ■ Application principles ■ Technology principles | Sada obecných principů architektury, včetně: ■ byznys principů, ■ datových principů, ■ aplikačních principy, ■ technologických principů. |
Architektonické úložiště | The Architecture Repository acts as a holding area for all architecture-related projects within the enterprise. The repository allows projects to manage their deliverables, locate re-usable assets, and publish outputs to stakeholders and other interested parties. | Repozitář architektury slouží jako prostor pro všechny projekty související s architekturou v rámci podniku. Úložiště umožňuje projektům spravovat jejich výstupy, lokalizovat opakovaně použitelná aktiva a publikovat výstupy zúčastněným stranám a dalším zájemcům. |
Specifikace architektonických požadavků | The Architecture Requirements Specification provides a set of quantitative statements that outline what an implementation project must do in order to comply with the architecture. An Architecture Requirements Specification will typically form a major component of an implementation contract or contract for more detailed Architecture Definition. As mentioned above, the Architecture Requirements Specification is a companion to the Architecture Definition Document, with a complementary objective. | Specifikace požadavků na architekturu poskytuje sadu kvantitativních prohlášení, která naznačují, co musí implementační projekt udělat, aby byl v souladu s architekturou. Specifikace požadavků na architekturu bude obvykle tvořit hlavní součást prováděcí smlouvy nebo smlouvy pro podrobnější definici architektury. Jak je uvedeno výše, specifikace požadavků na architekturu je doprovodným dokumentem k definičnímu dokumentu architektury. |
Plán realizace architektury | The Architecture Roadmap lists individual work packages that will realize the Target Architecture and lays them out on a timeline to show progression from the Baseline Architecture to the Target Architecture. The Architecture Roadmap highlights individual work packages’ business value at each stage. Transition Architectures necessary to effectively realize the Target Architecture are identified as intermediate steps. | Plán realizace architektury (Roadmapa) uvádí jednotlivé pracovní balíčky, které realizují cílovou architekturu, a stanoví je na časové ose, aby ukazovaly postup od výchozí architektury k cílové architektuře. Plán architektury zdůrazňuje hodnotu jednotlivých pracovních balíčků pro úřad v každé fázi. Architektury přechodu, nezbytné k efektivní realizaci cílové architektury, jsou identifikovány jako přechodné kroky. |
Architektonická vize | The Architecture Vision provides a summary of the changes to the enterprise that will accrue from successful deployment of the Target Architecture. The purpose of the Architecture Vision is to provide key stakeholders with a formally agreed outcome. | Architektonická vize poskytuje shrnutí změn v podniku, které vzniknou z úspěšného nasazení cílové architektury. Účelem architektonické vize je poskytnout klíčovým zúčastněným stranám formálně dohodnutý výsledek. |
Byznys motivátory, cíle a principy | Business principles, business goals, and business drivers provide context for architecture work, by describing the needs and ways of working employed by the enterprise. | Byznys principy, cíle a motivátory poskytují kontext pro práci na architektuře tím, že popisují potřeby a způsoby práce zavedené v úřadu. |
Posouzení schopností | Before embarking upon a detailed Architecture Definition, it is valuable to understand the baseline and target capability level of the enterprise. Typical contents of a Capability Assessment are: ■ Business Capability Assessment ■ IT Capability Assessment ■ Architecture maturity assessment. | Před zahájením podrobné definice architektury je užitečné porozumět výchozí a cílové úrovni schopností podniku. Typickým obsahem posouzení způsobilosti je: ■ Posouzení byznys schopnosti ■ Posouzení schopnosti IT ■ Posouzení zralosti architektury. |
Změnový požadavek | During implementation of an architecture, as more facts become known, it is possible that the original Architecture Definition and requirements are not suitable or are not sufficient to complete the implementation of a solution. Change Request may be submitted in order to kick-start a further cycle of architecture work. | Během implementace architektury se mohou objevit další skutečnosti, které způsobí, že původní definice a požadavky architektury nejsou vhodné nebo nejsou dostatečné k dokončení implementace řešení. Za účelem zahájení dalšího cyklu architektonických prací lze podat žádost o změnu. |
Komunikační plán | Enterprise Architectures contain large volumes of complex and inter-dependent information. Effective communication of targeted information to the right stakeholders at the right time is a Critical Success Factor (CSF) for Enterprise Architecture. Development of a Communications Plan for architecture allows for this communication to be carried out within a planned and managed process. | Architektury úřadů obsahují velké množství komplexních a vzájemně závislých informací. Efektivní komunikace cílených informací správným zúčastněným stranám ve správný čas je kritickým faktorem úspěchu (CSF) pro architekturu úřadu. Vývoj komunikačního plánu pro architekturu umožňuje tuto komunikaci provádět v rámci plánovaného a řízeného procesu. |
Posouzení shody | Once an architecture has been defined, it is necessary to govern that architecture through implementation to ensure that the original Architecture Vision is appropriately realized and that any implementation learnings are fed back into the architecture process. Periodic Compliance reviews of implementation projects provide a mechanism to review project progress and ensure that the design and implementation is proceeding in line with the strategic and architectural objectives. | Jakmile je architektura definována, je nutné tuto architekturu řídit a dohůlížet na průběh implementace, aby bylo zajištěno, že původní Vize architektury je náležitě realizována a že veškeré poznatky o implementaci jsou vráceny zpět do procesu architektury. Pravidelné kontroly prováděcích projektů poskytují mechanismus pro přezkoumání postupu projektu a zajištění toho, aby návrh a implementace pokračovaly v souladu se strategickými a architektonickými cíli. |
Plán implementace a migrace | The Implementation and Migration Plan provides a schedule of the projects that will realize the Target Architecture. The Implementation and Migration Plan includes executable projects grouped into managed portfolios and programs. | Plán implementace a migrace poskytuje plán projektů, které realizují cílovou architekturu. Plán implementace a migrace zahrnuje spustitelné projekty seskupené do spravovaných portfolií a programů. |
Model dohledu na implementaci | Once an architecture has been defined, it is necessary to plan how the Transition Architecture that implements the architecture will be governed through implementation. The Implementation Governance Model ensures that a project transitioning into implementation also smoothly transitions into appropriate Architecture Governance. | Jakmile je architektura definována, je nutné naplánovat, jak bude prováděn dohled na průběh implementace architektury. Model dohledu na implementaci současně zajišťuje, že s přechodem projektu do implementace přechází do odpovídajícího dohledu na architekturu. |
Organizační model pro EA | In order for an architecture framework to be used successfully, it must be supported by the correct organization, roles, and responsibilities within the enterprise. Of particular importance is the definition of boundaries between different Enterprise Architecture practitioners and the governance relationships that span across these boundaries. | Aby mohl být architektonický rámec úspěšně používán, musí být podporován správnou organizací, rolemi a povinnostmi v rámci úřadu. Zvláštní význam má definice hranic mezi různými odborníky v oblasti architektury úřadu a vztahy správy a řízení, které přesahují tyto hranice. |
Požadavek na architektonickou práci | This is a document that is sent from the sponsoring organization to the architecture organization to trigger the start of an architecture development cycle. | Toto je dokument, který je odeslán ze sponzorující organizace do útvaru architektury, aby spustil začátek cyklu vývoje architektury. |
Posouzení dopadů požadavků | A Requirements Impact Assessment assesses the current architecture requirements and specification to identify changes that should be made and the implications of those changes. | Posouzení dopadů (nových) požadavků posoudí současné požadavky na architekturu a specifikaci za účelem identifikace změn, které by měly být provedeny, a důsledků těchto změn. |
Stavební blok řešení | Detailed description of candidate solution which conforms to the specification of an Architecture Building Block (ABB). | Podrobný popis kandidátního řešení, které odpovídá specifikaci Stavebního bloku architektury (ABB). |
Zadání architektonické práce | The Statement of Architecture Work defines the scope and approach that will be used to complete an architecture development cycle. The Statement of Architecture Work is typically the document against which successful execution of the architecture project will be measured and may form the basis for a contractual agreement between the supplier and consumer of architecture services. | Zadání definuje rozsah a přístup, které budou použity k dokončení cyklu vývoje architektury. Zadání architektonické práce je obvykle dokumentem, podle kterého bude měřeno úspěšné provedení projektu architektury, a může tvořit základ pro smluvní dohodu mezi zadavatelem a dodavatelem architektonických služeb. |
Přizpůsobený architektonický rámec | Before the TOGAF framework can be effectively used within an architecture project, tailoring at two levels is necessary. 1) to tailor the TOGAF model for integration into the enterprise. 2) to tailor the framework for the specific architecture project. | Před tím, než lze rámec TOGAF efektivně využít v rámci architektonického projektu, je nezbytné přizpůsobení na dvou úrovních: 1) přizpůsobit model TOGAF pro integraci do úřadu, 2) přizpůsobit rámec pro konkrétní projekt architektury. |
Interpretace výstupů architektury
NAR v této části iniciálně zavádí nové typy dodatelných výstupů / plnění, v podobě dokumentů nebo modelů v architektonickém úložišti.
Tyto budou postupně zpřesňovány na základě zkušeností z prvních projektů. Dále budou provazovány s ostatními dokumenty a zodpovědnostmi v materiálu Metody řízení ICT VS ČR, tak aby tvořily ucelený a vyvážený systém bez zbytečných překryvů, duplicit nebo naopak mezer.
Příkladem je nutnost provázání řady zde uvedených obecných dodatelných výstupů architektury s konkrétními výstupy jednotlivých angažmá, specifikovaných výše, jako Architektonická vize, Informační koncepce OVS nebo Žádost o stanovisko OHA.
Zde bude další vysvětlení obsahu, významu a vzájemných souvislostí dodávaných výstupů.
Zájmové skupiny, hlediska a pohledy
Hlediska33) vycházejí z myšlenky, že existuje několik různých skupin zainteresovaných lidí, kteří potřebují ke své práci pouze určitý typ informací a různou míru detailu. Kdyby jim 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 (úhel pohledu), ze které je možné vidět pohled 34) na model. Jedná se o specifikaci konvencí pro vytvoření a použití pohledu. Zatímco Pohled je konkrétní diagram, tak Hledisko říká, jak má diagram vypadat a co má prezentovat uživateli.“
Tuto definici hezky doplňuje obrázek znázorněný níže, převzatý pro změnu ze specifikace ArchiMate 2.1:
Každé hledisko tedy odpovídá potřebám a možnostem jiné skupiny zainteresovaných osob 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 typů prvků a jejich vzájemných vazeb), případně definicí pohledů, tj. návodem na grafické vyjádření topologie a barevnosti modelu.
V dalších částech proto budou vymezena použitá hlediska a stanoveny role zainteresovaných, odpovídající těmto hlediskům. Pěkným znázorněním kategorií zainteresovaných, jejich potřeb a jim odpovídajících typů pohledů na celek modelu, který ale v praxi sám celkové grafické vyjádření nemá, ukazuje následující ilustrace na Obrázek níže:
Každý ze zainteresovaných v obrázku výše obdrží svůj vlastní pohled (katalog, matici, diagram), odpovídající jeho potřebám a jeho hledisku. Celkový diagram, pokud je vůbec realizovatelný, využívá pouze hlavní architekt a správce modelu pro kontrolu modelu.
Za téměř synonyma a víceméně zástupné se považují pojmy „Hledisko“ a „Definice pohledu“. Zatímco „Hledisko“ může více hovořit o tom, odkud, s jakými potřebami a s jakými možnostmi vnímání modelu se zainteresovaný na model dívá, stanovuje „Definice pohledu“ jaké má mít „Pohled“ náležitosti (dimenze, prvky metamodelu, formu, jazyk, apod.), aby přinesl zainteresovanému hledícímu na model z určitého „Hlediska“ očekávaný užitek.
Obě definice architektonických výstupů, jako pohledy a jako kategorie artefaktů spolu úzce souvisí. Všechny tři kategorie artefaktů (katalogy, matice a diagramy) představují pohledy a musí odpovídat příslušným hlediskům zainteresovaných.
Vzhledem k tomu, že katalogy a matice jsou současně výchozím předpokladem pro správné grafické vyjádření, spojuje NAR pojem pohled převážně s artefatem typu grafický diagram pohledu na model.
Hlediska a definice pohledů Národní architektury VS ČR
Přehled hledisek NAR
Národní architektonický rámec v následujících částech přináší přehled všech známých hledisek a jim odpovídajících definic pohledů, které mohou být přínosem pro architekty veřejné správy při komunikaci jejich poznání pro zainteresované.
Hlediska a definice pohledů jsou převzata jak z klíčových standardů pro NAR, tj. z TOGAF a ArchiMate, tak z dalších de facto standardů jako je Zachman35) nebo z nejlepší praxe rámců jiných států, například GEA-NZ Nového Zélandu36).
Důležitým zdrojem hledisek je pro NAR architektonická praxe úřadů VS ČR. Teprve praxe ukazuje, kdo jsou v OVS typičtí zainteresovaní, jaké mají potřeby a jaké pohledy na EA úřadu se pro ně osvědčily. NAR bude postupně přebírat a zobecňovat do podoby nejlepší praxe osvědčená hlediska ze všech lokálních architektonických metodik, o nichž se OHA dozví.
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 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í.
U jednotlivých hledisek a definic pohledů, případně s nimi spojených dodatelných výstupů rozlišuje NAR související úroveň hierarchie veřejné správy, tj. zda se jedná o výtvory a výstupy, které jsou výlučně celostátní (AoG37)), nebo mohou být i korporátní či se jedná výlučně o výtvory a výstupy jednotlivých úřadů.
Přehled výtvorů a výstupů současně upozorňuje, které katalogy a jim odpovídající grafické výstupy jsou pro rozvoj NA z pohledu NAR nové a naprosto klíčové:
- Mapa byznys schopností úřadu – co můj úřad všechno dovede a do jaké míry je to podporováno IT
- Mapa agend, služeb veřejné správy, případně procesů a funkcí – přesnější vyjádření schopností úřadu pomocí prvků jeho byznys chování.
- Mapa aplikačních komponent úřadu – jaké aplikace můj úřad používá a v jaké stavu jsou
- Mapa technologické infrastruktury úřadu – kde a v jakých platformách můj úřad provozuje svoje IS
- Mapa komunikační infrastruktury úřadu – jakými všemi způsoby můj úřad propojuje svoje vyýpočetní kapacity s vnějším světem
- Roadmapa změn (alespoň aplikační architektury) – kdy a proč budeme měnit, rozvíjet nebo ukončovat naše informační systémy
- Motivační mapa – přehled vlivů, cílů a očekávaných výstupů úřadu
Pro vnitřní potřebu zavedení tvorby, správy a užití EA je nutné vytvořit a užívat pohled na dílčí schopnost úřadu:
- Model řízení úřadu pomocí EA
NAR předpokládá, že pro každé portfoliové klasifikační hledisko typu Mapa bude k dispozici akcelerátor modelování v podobě referenčního modelu (RM). Aktuáně jsou k dispozici RM byznys architektury a aplikační architektury.
Hlediska převzatá z TOGAF
Přehled typových hledisek, definovaných v části TOGAF, zvané Rámec obsahu architektury (ACF38)), vyznačení a intepretace hledisek převzatých do NAR se nachází ve Znalostní bázi NA VS ČR.
Hlediska převzatá z ArchiMate
Jazyk ArchiMate ve verzi 2.1 definoval 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 NAP bylo převzato 12 v ČR nejpoužívanějších konkrétních hledisek, která byla vybrána s výhledem na jejich další praktické využití. Jejich přehled se nachází ve Znalostní bázi NA VS ČR.
Vedle toho se ve specifikaci ArchiMate 2.1 uvádělo obecné hledisko představující grafické vyjádření matic a klasifikací architektury, zvané hledisko přehledové (krajinné) mapy39). V NAR je toto obecné doporučení rozpracováno pro každou z vrstev byznys, aplikační a technologické architektury a pro architekturu schopností ve strategické doméně. 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 funkcí, 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 či přesto, že se následně v diagramech individuálních architektur použijí dvakrát, pro IT technologie a pro komunikační infrastrukturu, není třeba i jejich definice zdvojovat a specializovat, ale je to přípustné.
Hlediska převzatá z rámce Zachman
Z architektonické rámce Zachman, verze 3.0, který je tzv. ontologií architektonických modelů, dosud nebyla převzata žádná hlediska jim odpovídající definice pohledů. Budou-li nově nějaká hlediska zařazena, pak bude jejich přehled a definice ve Znalostní bázi NA VS ČR.
Aktuálně doporučovaná hlediska NAR
Následující schéma představuje podmnožinu hledisek a jim odpovídajících definic grafických pohledů na model architektury úřadů (diagramů), vybraných ze souhrnu hledisek TOGAF, ArchiMate a z praxe a aktuálně zařazených do přizpůsobeného rámce Národní architektury tak, jak mají sloužit pro jednotnost zpracování a navigaci ve sdíleném architektonickém úložišti.
Dále je přehled doporučených hledisek předem rozšířen o hlediska tzv. Evropské referenční architektury pro interoperabilitu (EIRA40)), verze 2.1.0.
Všechna dále ve schématech uvedená hlediska odpovídají grafickým diagramům, hlediska pro katalogy a matice nejsou uvedena, ale tvoří jejich předpoklady.
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 ACF41), pokud v pokynu pro vybrané architektonické angažmá, viz 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.
Přehledová hlediska
Mezi přehledovými hledisky je aktuálně definováno tzv. hledisko Přehledu služeb čtyřvrstvé architektury eGovernmentu. Toto hledisko udržuje kontinuitu s předchozími strategickými dokumenty eGovernmentu ČR a poskytuje zainteresovaným přehled o vzájemném předávání služeb mezi jednotlivými vrstva architektury. Hledisko odpovídá struktuře metamodelu ArchiMate a standardnímu hledisku vrstev architektury, ale z důvodu členění zodpovědnosti vyděluje zvlášť vrstvu architektury technologické komunikační (a stavební) infrastruktury a zdůrazňuje úlohu služeb.
Dále se zde uplatní dle potřeby standardní ArchiMate hlediska, tzv. úvodní hledisko a hledisko vrstev architektury.
Za přehledové hledisko je možné považovat i Přehled (Mapu) schopností úřadu42), která ukazuje rozdělení úřady na menší části (segmenty a schopnosti) podle toho, jaké byznys výstupy (interní a externí) dokáží poskytovat, ale bez ohledu na to, co obsahují uvnitř, ve své architektuře. Ve standardní specifikaci ArchiMate je toto hledisko součástí strategie, pro NAR bude plnit zejména úlohu nezbytného přehledu.
Hledisko Přehledu služeb čtyřvrstvé architektury
Hledisko služeb čtyřvrstvé architektury je skutečně zaměřeno na vyjádření vztahu mezi interním chováním (tj. zejména funkcí) aktivního prvku dané vrstvy a externím projevem tohoto chování (schopnosti) vůči prvku vyšší vrstvy, tj. službou.
Ostatní prvky metamodelu ArchiMate jsou pro zdůraznění hlavní myšlenky spolupráce vrstev záměrně vynechány.
Ú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. Typické je pro vyjádření architektonické vize.
Rysem tohoto hlediska je, že se často v zájmu lepšího porozumění zainteresovanými odchyluje od striktní vizuální notace ArchiMate. Tak je to možné i v této metodice NAR.
Definice tohoto hlediska může vypadat například následovně:
Hledisko vrstev architektury
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 „slouží“). 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ě.
Počet vrstev není pevně stanoven. Metamodel tohoto pohledu vychází z celkového metamodelu jazyka ArchiMate 3.1. Na Obrázku níže 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 je z tohoto ArchiMate hlediska odvozeno specializované hledisko pro vyjádření naplnění tzv. vize čtyřvrstvé architektury eGovernmentu konkrétní architekturou úřadu, jeho segmentu nebo schopnosti.
Zjednodušené hledisko vrstev architektury
V praxi se často setkáváme s potřebou vyjádřit objekty ve více vrstvám architektury, ale bez možnosti zdůraznit servisní vrstvy, například proto, že služby dané vrstvy (byznys, aplikační či technologické) nejsou v organizaci známy a udržovány, funkce aktivních prvků nejsou jako služby řízení, a proto je tak nelze ani modelovat.
Potom se uplatní tzv. Zjednodušené hledisko vrstev (bez rozdělení vrstev na dedikované a servisní). Příklad z praxe:
Hledisko přehledu schopností úřadu
Hledisko přehledu schopností úřadu (Capability Map) se používá tehdy, je-li třeba na jedné ploše, jednom snímku PowerPointu představit zainteresovaný přehled všeho, co úřad dokáže. A to bez toho, že by již v této fázi bylo analyzováno, které to dělá oddělení, jakým procesem, na základě jakého zákona či s jakým informačním systémem.
Jde o strukturální model, ve kterém je přehled schopností úřadu vyjádřen hierarchickou strukturou objektu „Schopnost“, ať již v podobě hierarchického Katalogu schopností úřadu, nebo diagramu Přehled (mapa) schopností úřadu.
Schopnosti, zachycené v modelu jsou dlouhodobě stabilní, pouze se zlepšují. Mohou být složeny z dílčích schopností, přiřazených kompozitní vazbou.
Přestože schopnosti mohou být hierarchické, viz výše, je možné k modelování schopností přistoupit ještě dvojím způsobem a) podle struktury Enterprise dle TOGAF a podle příkladu klasifikačních map v ostatních doménách. Oba přístupy společně a ve vzájemném vztahu shrnuje Obrázek níže.
Podle dělení TOGAF je celý Enterprise považován za strategický, dále dělí na (vertikální, odvětvové) segmenty a tyto se teprve dělí na schopnosti (vertikální a průřezové, horizontální). Pro případné modelování segmentů úřadu je navrženo použít specializovaného stereotypu schopnosti, nazvaného «Segment úřadu», respektive jenom zkráceně «Segment». Oblasti na nejvyšší úrovni, které nejsou segmentem výkonu veřejné správy se modelují rovnou jako nespecializovaná Schopnost.
Je možné uvažovat pouze na schopnosti na nízké úrovni (větším detailu) a pro jejich seskupování (klasifikaci, třídění) nevyužívat schopnosti, nýbrž Seskupení, viz Obrázek výše (vlevo). Který ze způsobů modelování schopností se skutečně vžije, ukáže až praxe.
Obrázek - Přehled schopností úřadu, nebo také základní mapa úřadu je vynikajícím výrazovým prostředkem, do něhož lze promítnou vyhodnocení nějakého aspektu schopností v jednotlivých oblastech, například míru či kvalitu IT podpory výkonu schopností. Takovému vyjádření říkáme Heat Map43) a v NAR se vyskytuje opakovaně na více místech. Barvy v příkladu znamenají: modrá – průměr, zelená – nadprůměr, červená – podprůměr, potenciál pro zlepšení.
Hlediska motivační architektury
Ze všech čtyř vertikálních domén motivační architektury (strategické směrování, výkonnost, bezpečnost a shoda s pravidly) je ve shodě se standardem ArchiMate aktuálně pro NA VS ČR definován obsah diagramů pro tzv. Motivační hledisko - strategické směřování. Ve specifikaci ArchiMate odpovídá tzv. Motivačnímu rozšíření a v TOGAF odpovídá motivační části byznys architektury.
Pro ostatní domény motivace jsou definovány pouze katalogy, bez matic a grafického vyjádření.
Motivační hledisko strategického směřování
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ů.
Pohledy vytvořené podle tohoto hlediska postihují motivaci úřadu ke strategické změně a s ní spojené změně architektury. Hledisko nezohledňuje ostatní průběžné motivační aspekty, například motivaci k výkonu a kvalitě služby.
Pro modelování diagramů podle tohoto hlediska jsou předpokladem následující katalogy motivační architektury:
- Katalog zainteresovaných stran44)
- Katalog motivátorů45) a potřeb
- Katalog architektonických principů
- Katalog klíčových architektonických požadavků48) a omezujících podmínek
Celkové motivační hledisko může být při velkém množství motivačních prvků s výhodou rozděleno na:
- Hledisko zainteresovaných stran
- Hledisko architektonických principů
Hlediska architektury výkonnosti
Architektura výkonnosti aktuálně nemá definována žádná hlediska pro grafické diagramy, nemá ani specifický metamodel, přestože by bylo možno alespoň částečně využít objekt specializovaný typ prvků „Metrika“.
Pro výkonnostní architekturu jsou navrženy tyto katalogy:
- Katalog ukazatelů výkonnosti a kvality, kam se počítají ukazatele 3E, dělené na:
- Katalog výsledků, dopadů a multiplikačních efektů politiky (strategické iniciativy)
Pro výkonnostní architekturu aktuálně nejsou navrženy žádné matice ani diagramy.
Hlediska architektury bezpečnosti
Architektura bezpečnosti aktuálně nemá definována žádná hlediska pro grafické diagramy, nemá ani specifický metamodel, protože objekty typu „Riziko“ a „Opatření na zmírnění rizika“ nejsou dosud součástí standardní specifikace jazyka ArchiMate 3.1.
Připravuje se využití bezpečnostní architektury v duchu a na podporu zákona o kybernetické bezpečnosti (ZoKB), resp. ISO 27001. Tj. v duchu doporučení The Open Group budou pro tuto oblast vytvořeny prvky metamodelu (potřebné stereotypy) specializací jiných existujících prvků a jejich dedikováním pro aktivum, hrozbu, riziko, opatření, … tj. pojmy dle ZoKB. Vzhledem ke zdrženlivosti při rozšiřování metamodelu to nebude v nejbližší době a musí tomu předcházet pilotní projekty.
Pro bezpečnostní architekturu jsou zatím navrženy tyto katalogy:
- Katalog pasivní bezpečnostní architektury, tj. katalog prvků architektury úřadu, které vyžadují specifickou ochranu. Používá se zejména v architektuře připravovaných projektů (PSA52)) pro zdůraznění nově implementovaných prvků hodných mimořádné ochrany, kterou úřad dosud nedisponuje.
- Katalog aktivní bezpečnostní architektury, tj. katalogů prvků úřadu, které svojí přítomností poskytují jiným prvkům mimořádnou (dodatečnou) ochranu. Používá se zejména v PSA (viz výše) pro zdůraznění nově implementovaných bezpečnostních prvků.
Pro bezpečnostní architekturu aktuálně nejsou navrženy žádné matice ani diagramy.
Hlediska architektury shody s pravidly, standardizace a udržitelnosti
Architektura shody s pravidly, standardizace a udržitelnosti aktuálně nemá definována žádná hlediska pro grafické diagramy, nemá ani specifický metamodel.
Pro tuto architekturu jsou navrženy tyto katalogy:
- Katalog předpisů a norem
- Katalog standardů
- Katalog stavebních bloků architektury a řešení
- Katalog zásad a opatření dlouhodobé udržitelnosti úřadu
Pro architekturu shody s pravidly, standardizace a udržitelnosti aktuálně nejsou navrženy žádné matice ani diagramy.
Hlediska byznys architektury poskytování služeb VS
Hlediska byznys architektury VS definují především několik zásadních katalogů, v nichž je inventarizováno vždy několik blízkých objektů. Jsou to:
- Katalog organizačních jednotek, útvarů a pozic,
- Katalog aktérů (jejich typů) a jejich rolí – konkrétní aktéři se obvykle neinventarizují (například fyzická osoba, občan, zaměstnanec), nahrazující se typem aktérů a odhadem počtu.
- Katalog funkcí a procesů
- Katalog služeb veřejné správy
- Katalog komunikačních (obslužných) rozhraní veřejné správy
Pro byznys architekturu výkonu služeb veřejné správy aktuálně nejsou navrženy žádné matice.
Pro byznys architekturu jsou v NAR aktuálně definována tato následující hlediska.
Hledisko funkcí veřejné správy
Hledisko funkcí veřejné správy znázorňuje hlavní byznys funkce organizace a vztahy mezi nimi. Byznys funkce se využívají k zobrazení hlavních činností, které podnik vykonává, bez ohledu na organizační změny nebo technologický vývoj. Proto také byznys architektury společností, které působí na stejném trhu, často vykazují podobnosti. Toto hledisko poskytuje podrobný pohled na provoz společnosti a lze ho využít k identifikaci nezbytných kompetencí nebo ke strukturování organizace podle hlavních činností.
Hledisko spolupráce aktérů
Toto hledisko v nejjednodušší formě ukazuje vztah mezi dynamickým účastníkem (rolí) a bytostí nebo organizací, která na sebe role bere (aktér).
Podstatné je, že existence aktéra je trvalá, kdežto roli na sebe bere jenom v případě, že vstupuje do interakce (poskytuje nebo konzumuje funkci jako službu).
Případnou specializaci aktérů na organizace a útvary bude třeba nejprve ověřit v praxi.
Hledisko spolupráce byznys procesů
Hledisko spolupráce 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í. 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 prezentační pomůcka pro provozní manažery, kterým poskýtá nezbytný přehled závislostí jimi řízených procesů.
Hledisko byznys procesů se používá k podrobnému zobrazení struktury a složení byznys procesů. Kromě vlastních procesů hledisko obsahuje i jiné přímo související koncepty, jako jsou například:
- Služby poskytované byznys procesy navenek; zobrazují, jak proces přispívá k realizaci produktů společnosti
- Přiřazení byznys procesů k rolím, které vypovídají o zodpovědnostech přiřazených aktérů
- Další informace využívané byznys procesy prostřednictvím aplikačních služeb
Hledisko organizační struktury
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.). Model je možné prezentovat digramem ve formě vnořených bloků, nebo ve formě tradičního organizačního schématu.
Hledisko organizační struktury je užitečné při identifikaci kompetencí, pravomocí a zodpovědností v organizaci. 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.
Příklad:
Produktové hledisko
Hledisko portfolia byznys funkcí a služeb (Mapa)
Základem obsahu tohoto hlediska 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ždý zařadit právě do jedné z byznys oblastí, kategorií a skupin.
Současně jsou v referenčních modelech představena grafická vyjádření rozmístění klasifikovaných domén, jejich oblastí, kategorií a skupin, tj. jejich tzv. topologie. Důsledné využití topologie z referenčních modelů významně zrychlí tvorbu diagramů typu Mapa a výrazně usnadní jejich čtení a interpretaci.
NAR zde doporučuje používat pro vyjádření klasifikace a její topologie v modelech objekt „Seskupení“.
Naopak – 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.
Výjimkou jsou specializované koncepty jako tzv. «stereotypy», například «agenda» a «agendová činnost», které ale nejsou součástí diagramu Mapa portfolia, pokud nejsou klasifikovány společně a konzistentně s ostatními nespecializovanými byznys funkcemi.
Hlediska architektury informačních systémů
Základem architektury informačních systémů a jejích artefaktů jsou katalogy klíčových objektů. Jsou to zejména:
- Katalog byznys a datových entit úřadu. V jednom katalogu lze zachytit jak byznys, tak datové objekty. Alternativně (v případě rozvinutější datové architektury) je účelné datovou architekturu rozdělit do několika katalogů a u obou typů entit evidovat rozdílné atributy (vlastnosti). Tedy zvlášť:
- Katalog objektů / subjektů veřejné správy (úřadu)
- Katalog datových objektů úřadu
- případně Katalog datových artefaktů, fyzických souborů, tabulek a jiných úložišť dat.
- Katalog aplikačních komponent a funkcí. Tento katalog je možné v případě potřeby rozšířit ještě o prvky aplikační spolupráce a aplikační interakce
- Katalog aplikačních rozhraní
- Katalog aplikačních služeb, je odvozen od interních aplikačních funkcí, může mít jinou podrobnost a jiné evidované vlastnosti služeb, než u aplikačních funkcí.
Pro aplikační architekturu výkonu služeb veřejné správy aktuálně nejsou navrženy žádné matice.
Hledisko struktury informací
Toto hledisko, stejně jako celý výše uvedený metamodel tzv. datové architektury dle TOGAF, pokrývá objekty napříč všemi třemi vrstvami architektury dle ArchiMate.
V rámci tohoto hlediska je možné v notaci ArchiMate použít „Objekty/subjekty VS“, tzv. Business Object, pro zachycení tzv. konceptuálního datového modelu klíčových objektů evidence.
Nebo je možné využít „Datové objekty“ pro zachycení diagramu logického datového modelu.
Velmi častá a doporučená je také kombinace obou typů, ukazující, jak skutečné objekty mají své obrazy v datových objektech.
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é Rámec obsahu a výstupu architektur.
Hledisko struktury aplikací
Toto hledisko se zaměřuje pouze na aktivní a pasivní prvky aplikační architektury, záměrně opomíjí jejich chování. Hledisko struktury aplikací zobrazuje strukturu jedné nebo více aplikací a komponent. Hledisko se využívá k navrhování či pochopení základní struktury aplikací nebo komponent a souvisejících dat; například lze rozebrat strukturu systému ve výstavbě nebo identifikovat komponenty starší aplikace, které jsou vhodné pro migraci či integraci.
Hledisko chování aplikací
Hlavním objektem a centrem zájmu tohoto hlediska je aplikační funkce. Cílem hlediska je co nejlepším způsobem postihnout, co aplikační komponenty nebo jejich spolupráce dovedou, tedy jakými funkcemi disponují.
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.
Příklad:
Hledisko spolupráce aplikací
Těžištěm zájmu tohoto hlediska je postihnout, jak jsou spolu aplikační komponenty integrovány přes aplikační rozhraní. Hledisko spolupráce aplikací popisuje vztahy mezi aplikačními komponentami ve smyslu informačních toků mezi nimi a nabízených služeb včetně jejich využití. Hledisko je typicky využíváno k vytvoření přehledu o aplikačním vybavení organizace. Dále se využívá k vyjádření (interní) spolupráce či uspořádání služeb, které podporují vykonávání byznys procesů.
Toto hledisko primárně slouží k názornému až detailnímu zobrazení vazeb na aplikační úrovni.
Příklad (bez použití objektu rozhraní):
Hledisko využití aplikací
Hledisko využití aplikací popisuje, jak jsou aplikace využívány k podpoře byznys procesů, a také jak jsou využívány dalšími aplikacemi. Lze ho využít při navrhování aplikací prostřednictvím identifikace aplikačních služeb, potřebných pro byznys procesy nebo při navrhování byznys procesů popsáním dostupných služeb. Vzhledem k tomu, že se identifikují závislosti byznys procesů na aplikacích, hledisko mohou využít i provozní manažeři zodpovědní za tyto procesy.
Toto hledisko představuje logickou návaznost mezi byznys a aplikační vrstvou.
Příklad:
Hledisko aplikačního portfolia (Mapa)
Základem obsahu tohoto hlediska je třístupňová klasifikace všech prvků aplikační architektury. S trochou nepřesnosti je možné říci, že jak aplikační komponenty, jejich funkce, jejich služby a s nimi spojené datové objekty lze jednoznačně klasifikovat, tj. každou zařadit právě do jedné z aplikačních kategorií.
Současně jsou v referenčních modelech představena grafická vyjádření rozmístění klasifikovaných domén, oblastí, kategorií a skupin, tj. jejich tzv. topologie. Důsledné využití topologie z referenčních modelů významně zrychlí tvorbu diagramů typu Mapa a výrazně usnadní jejich čtení a interpretaci.
Doporučení NAR je používat pro vyjádření klasifikace a její topologie v modelech objekt „Seskupení“.
Naopak – tato metodika považuje za nevhodné, používat pro úrovně klasifikace objekty vyhrazené skutečně jsoucím prvkům architektury (aplikační komponenty, 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.
Výjimkou jsou specializované koncepty jako tzv. «stereotypy», například «logický IS».
Hledisko realizace požadavků aplikacemi
Toto hledisko je příkladem a specializací obecného motivačního (strategického) hlediska Realizace požadavků.
Hlediska IT technologie a komunikační infrastruktury
Hlediska technologické architektury VS definují především několik zásadních katalogů, v nichž je inventarizováno vždy několik blízkých objektů. Jsou to:
- Katalog uzlů, zařízení a systémového SW
Pro technologickou architekturu výkonu služeb veřejné správy aktuálně nejsou navrženy žádné matice.
Pro technologickou architekturu v Národním architektonickém rámci aktuálně definována následující hlediska.
Všechna technologická hlediska je možno použít jak pro vyhodnocování a řízení technologií z hlediska jejich umístění do DC (topologie infrastruktury v lokalitách), tak z hlediska konsolidace využívaných technologických platforem.
Hledisko technologické infrastruktury - obecné
Hledisko IT technologií obsahuje prvky SW a HW infrastruktury, které podporují aplikační vrstvu; jedná se o fyzická zařízení nebo systémový software (například operační systémy, databáze a middleware).
Příklad:
Hledisko využití infrastruktury
Hledisko využití technologické infrastruktury zobrazuje, jak jsou aplikace podporovány SW a HW infrastrukturou. Infrastrukturní služby jsou dodávány zařízeními; systémový software a sítě jsou poskytovány aplikacemi. Toto hledisko hraje důležitou roli v analýze výkonnosti a škálovatelnosti, protože se týká fyzické infrastruktury podporující logickou oblast aplikací. Hledisko je užitečné při určování požadavků na výkon a kvalitu infrastruktury, které vycházejí z požadavků jednotlivých aplikací využívajících danou infrastrukturu.
Zjednodušené hledisko nasazení informačních systémů
Z praktického užití architektury úřadu na MZe bylo do metodiky NAR převzato zjednodušené hledisko propojující technologické uzly, v nich uchovávané datové artefakty (soubory, databáze) a na nich provozované aplikační komponenty.
Hledisko technologického portfolia (mapa)
Základem obsahu tohoto hlediska je třístupňová klasifikace všech prvků technologické architektury. S trochou nepřesnosti je možné říci, že jak aplikační komponenty, jejich funkce, jejich služby a s nimi spojené datové objekty lze jednoznačně klasifikovat, tj. každou zařadit právě do jedné z aplikačních kategorií.
Další komentáře totožné jako u ostatních portfolií výše.
Hledisko využití komunikační infrastruktury (specifické pro ČR)
Specifický diagram na podporu vyjádření rozdělené zodpovědnosti poskytovatelů služeb výpočetního výkonu (datových center) a služeb komunikační infrastruktury.
Pro koncepty komunikační infrastruktury je možné využít běžné prvky technologické infrastruktury nebo zdvojené (specializované) objekty pro komunikační infrastrukturu. V architektuře konkrétního úřadu je možné modelovat IT technologie i komunikační infrastrukturu jednou sadou prvků metamodelu technologické vrstvy a až v tomto hledisku a v hledisku čtyřvrstvé architektury vyjádřit rozdělení technologické (zelené) vrstvy ArchiMate ve dvě, IT technologickou a komunikační.
Jak technologickou tak komunikační infrastrukturu je přirozené kombinovat s prvky vrstvy fyzické architektury, představující zejména další non-IT objekty datových center - budovy, klimatizace, zabezpečení apod.
Hledisko portfolia komunikační architektury (Mapa, specifické pro ČR)
Portfoliové hledisko oblasti komunikační architektury bude obdobné hledisku technologické mapy, ale není zatím specifikováno.
Hledisko implementace a migrace
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 prvků, které jsou ovlivněny. Způsob, jakým se jednotlivé elementy ovlivňují, může být znázorněn vhodnou anotací jejich vazeb.
Příklad:
Hlediska referenční architektury evropské interoperability EIRA
Popis hledisek a jejich praktického využití bude doplněn do další verze metodiky NAR.
Navazující detailní modelovací metody
Modelování architektury úřadu na úrovni Enterprise architecture, s využitím metodiky TOGAF a jazyka ArchiMate, obvykle na jedné straně předchází modelování strategie a tzv. byznys modelu a na druhé straně za nimi následuje podrobnější modelování architektur řešení a modelování design řešení.
K obojímu se využijí specifické metody a modelovací notace, například:
- Strategie: SWOT, PESTEL, Porter’s Five Forces, Balanced Scorecard, Business Model Canvas, Ecosystem model, Business Motivation Model, atp.
- Detail nebo speciality: UML, SysML, BPMN, DMN, ERD, Customer Journey Map, Business Outcome Journey Map, atp.
Důvodem, proč zde v NAR tyto metody a notace zmiňujeme, není snaha formulovat jejich národní specifikaci, nýbrž upozornit na to, že objekty v jazyce ArchiMate je nutné modelovat tak, aby na zachycení existence nějaké věci (procesu, služby, datového prvku apod.) v jazyce ArchiMate mohl navazovat její detailní model v jiné notaci.
Například při modelování chování úřadu v byznys vrstvě je vhodné prohlásit za proces jenom taková chování, která splňují atributy procesu a bude je následně možné modelovat jako bazén BPMN modelu. A naopak, všechno, pro co bude v BPMN modelován proces, podproces nebo volaná aktivita, by mělo mít i svůj odpovídající obraz v ArchiMate modelu.
Proto by modelování pro potřeby digitální transformace veřejné správy mělo být podpořeno integrovaným společným modelem úřadu na úrovni NAP i PMA3.
Pro úřady, které s výhodou využijí více modelovacích notací, doporučuje NAR tento fakt zdůraznit v zadávací dokumentaci k VZ na modelovací nástroj tak, aby bylo zajištěno nejenom jedno modelovací prostředí pro tyto různé notace, ale také možnost plynulého přechodu (navigace a trasování) mezi modely v různých notacích, viz příklad na obrázku níže.
Provázání ArchiMate a BPMN
Na vztahu těchto dvou notací je plně zřejmý rozdíl mezi architekturou úřadu na úrovni EA, kladoucí si zejména otázku „Co a proč je?“ a architekturou řešení (SA), kladoucí si otázku „Jako to funguje?“, zde na úrovni byznys vrstvy.
Model EA v ArchiMate pro příklad objednání pizzy zachytává jenom základní role zákazník a dodavatel a existenci všech klíčových procesních krků a hrubých vazeb mezi nimi, jak ukazuje následující diagram:
Naproti tomu digram v notaci BPMN v tomto příkladu zachovává 1:1 procesní kroky, ale přidávání dílčí zodpovědnosti (role) a prováděcí detaily (rozhraní, čekání apod.):
V běžné praxi je BPMN model ještě mnohem podrobnější, tj. pro každý jeden proces v ArchiMate je typicky modelován v BPMN jeden „bazén“ s mnoha procesními rolemi a mnoha kroky.
Diskuze
v aplikačním plném metamodelu je použita vazba specializace mezi Spolupráce aplikací a Aplikační komponentou. Tato vazba ale není povolena mezi elementem spolupráce a elementem komponenta v rámci definice jazyka Archimate. Existuje, prosím, nějaký příklad, kdy je v reálu element spolupráce specializací komponent?
Děkuji.
S pozdravem
Vaněček František
opravdu ve specifikaci není specializace přípustná https://pubs.opengroup.org/architecture/archimate3-doc/ch-relationships-Normative.html a to i přesto, že jak kolaborace, tak komponenta jsou samy specializací elementu vnitřních aktivních struktur v aplikační vrstvě https://pubs.opengroup.org/architecture/archimate3-doc/ch-Application-Layer.html. I proto to asi v předchozích verzích byla povolená vazba.
Takže nyní je toto využití nemožné, při příští aktualizaci to opravíme.
S pozdravem,
Tomáš Šedivec
v plném metamodelu bysnys vrstvy je obráceně popis vazby u elementu Funkce / proces / interakce VS, je tam jmenovka "spouští" u vazby flow a "tok" u vazby triggering. V redukovaném metamodelu je to již správně.
S pozdravem
Vaněček František
děkuji za připomínky, při příští verzi je zapracujeme.
S pozdravem,
Tomáš Šedivec
jedna "kosmetická" připomínka. V definici barev chybí ten odstín modré pro "předpis", resp. standardizační doménu. A jedna k redukovanému základnímu metamodelu - neměl by tam přeci jen být i systémový software? Realizace aplikačních komponent s využitím systémového sw není předmětem zájmu (dbms, as, ..)?
David Knespl
děkuji za připomínky. Ten předpis je možné modelovat jako součást byznys architektury. Ač současný stav NAR říká, že je to "aspekt" standardizace, tak akceptujeme i tuto variantu. Proto barvené spektrum je možné mít stejné jako byznys objekty.
Co se týče systémového SW, tak ten je součástí i zjednodušeného metamodelu.
S pozdravem,
Tomáš Šedivec
děkuji, upraveno, snad je to nyní pochopitelnější.
S podzravem,
Tomáš Šedivec
Má tento prvek v modelu opravdu být?
pokud myslíte prvek "Funkce/proces/interakce VS", tak ten je vedený jak metamodelu, tak i zde v BA.
Nebo máte na mysli jiný?
S pozdravem,
Tomáš Šedivec
bohužel nastavení levého ToC je globální a současná úroveň mi přijde pro přehlednost nejlepší.
Zkusím se ještě podívat, zda to jde kódově upravit.
S pozdravem,
Tomáš Šedivec
rozumím vašemu názoru, přesto já mám spíše pozitivní zpětnou vazbu, že s takovímto omezením je to pro ně uchopitelnější a pro nás (formulář OHA) dostatečné.
S pozdravem,
Tomáš Šedivec
zjednodušený s doporučenými prvky pokládám za potřebný. Respektive, dost to omezí množinu prvků, které musí lidé, kteří s architekturou třeba tolik nepracují, vstřebat.
S pozdravem,
Tomáš Šedivec
děkuji za tento dotaz. V době vzniku těchto hledisek bych si spíše tipnul, že šlo o nejednotnost, která neměla za cíl odlišit význam hledisek a vztahu mezi uzlem a SW či zařízením. Ve starší specifikaci byly všechny aktivní prvky technologické vrstvy specializací uzlu, to už nyní neplatí, takže by to stálo za předělání.
S pozdravem,
Tomáš Šedivec
popis klasifikací je zde https://archi.gov.cz/nar_dokument:referencni_modely_a_klasifikacni_ramce. Pokud by byl nedostatečný, pokusíme se jej rozšířit.
S pozdravem,
Tomáš Šedivec
zde jsem bohužel zaspali. NAR byl psán v době, kdy vazba access sice byla směrová, ale rozlišení funkce (R,W,RW) bylo pouze doménou architektonických nástrojů. Specifikace to nyní pro access umožňuje, proto bychom to měli doplnit.
S pozdravem,
Tomáš Šedivec
ano, nejčistší je vždy realizační vazba mezi interním chováním (např. funkcí) a externím chováním (tedy službou). Uvedený příklad bez bližšího vysvětlení používá derivovanou vazbu, tedy vynechání prvku vnitřního chování a rovnou jejího přenesení na vazbu mezi aktivní prvek a externí chování.
Doplním vysvětlení k příkladu.
S pozdravem,
Tomáš Šedivec
Nepůsobí dojmem, že by se na něm příliš řešila problematika "spolupráce byznys procesů".
ano je. Spolupráce se zde vyznačuje rekurzí byznys procesů, které následně poskytují službu. Samozřejmě jsem ale přístupni návrhu na změny.
Ideálně ale nechceme používat prvek "kolaborace", pokládáme jej za zbytný.
S pozdravem,
Tomáš Šedivec
junction se v hledisku nemusí vyskytovat, bereme ho jako grafické zjednodušení více vazeb stejného typu. Jediná logika je v tom, zda vstupy a výstupy do junction platí všechny naráz nebo alespoň jeden.
Váš návrh tedy spočívá v tom přidat do hlediska i tok mezi procesy? To by neměl být problém.
S pozdravem,
Tomáš Šedivec
https://archi.gov.cz/nar_dokument:ramec_obsahu_a_vystupu_architektur#hledisko_vrstev_architektury
Je zmíněn v textu ("Na Obrázku níže je tedy uveden pouze příklad ...")
odkazuje se na stejný obrázek, jak následující podkapitola https://archi.gov.cz/_detail/nar-dokument:image69.png?id=nar_dokument%3Aramec_obsahu_a_vystupu_architektur
S pozdravem,
Tomáš Šedivec
rozumím. Proberu to s Pavlem Hrabětem, zda není k dispozici lepší diagram. Pokud byste měl vlastní či návrhy na zlepšení, určitě je uvítáme.
S pozdravem,
Tomáš Šedivec