Architektonické úložiště a nástroj

Každý úřad má navrhnout a s OHA MV projednat, jaké vlastnosti má mít jeho „architektonické repozitory“ jako podmnožina „enterprise repozitory“ pro správu znalostí úřadu, jak bude na jedné straně sloužit jako sdílené úložiště pro ostatní organizace úřadu (resortu, krajské korporace, ORP) a jak (a kdy) bude na druhé straně integrováno na centrální národní architektonické úložiště veřejné správy.

Je připravován projekt centrálního architektonického repozitory Národní architektury, které na jedné straně bude konzistentním centrálním úložištěm modelů všech úřadů a na druhé straně umožní vybraným úřadům přístup k modelovacímu nástroji. Ostatní úřady mohou modelovat ve svých vlastních nástrojích, včetně Open Source nástroje ARCHI, který je zdarma. Podmínkou bude sdílet svoje modely s centrálním repozitory ve standardizovaném formátu The Open Group ArchiMate File Exchange Format, v rozsahu a obsahu podle povinných náležitostí jednotlivých typů architektonických angažmá.

Veškeré vytvořené modely a pohledy na ně budou, společně se všemi souvisejícími a navazujícími dokumenty, uloženy v architektonickém úložišti (repozitory), které je nedílnou součástí celkového úložiště úřadu/podniku (enterprise repozitory) a jeho mechanismů (procesů a systémů) správy znalostí. Z hlediska modelování je repozitory primárně úložištěm metamodelů, referenčních modelů, resp. povinných vzorů a individuálních modelů architektury úřadu a podřízených organizací. Tyto tři typy (balíčky) modelů se v případě potřeby dekomponují do větších detailů. Z modelů se odvozují pohledy, které zobrazují prvky a vazby z dílčích modelů dle nahlížené perspektivy.

Potřeba jednotně udržovat architektury jednotlivých OVS (tzv. lokální), společně s potřebou centrálně udržovat architekturu sdílených centrálních prvků a služeb eGovernmentu a společně s potřebou vyhodnocovat a řídit společně lokální i centrální architektury, vede k následujícím formulacím požadovaných vlastností jednotlivých architektonických úložišť.

Popisy architektur v úřadu tvoří systém výstupů, kategorizovatelný z mnoha úhlů pohledu, například podle účelu a míry podrobnosti modelů, viz Struktura modelovaných architektur.

Architektonické úložiště, národní i lokální, popisované v následujících částech slouží pro úroveň popisu „podniková architektura (Enterprise Architecture)“. V celkovém úložišti úřadu se však nachází společně s výstupy o všech dalších detailnějších úrovních popisu „architektura řešení“, „Design řešení“ a provozní dokumenty dodávky služeb. Optimálně jsou v cílové podobě všechny odpovídající a navazující dokumenty provázány odkazy.

Součástí úložiště pro úroveň „architektura úřadu/podniku“ musí být dle této metodiky NA VS ČR, s odkazem na standard TOGAF, prostředky pro ukládání výstupů (modelů, dokumentů) z následujících oblastí, jak je hrubě a podrobněji ukazuje následující Obrázek:

• Architektonický rámec (orig. Architecture metamodel) - definice (dokumentace) upraveného architektonického rámce NA VS ČR, včetně metodiky pro architektonický obsah (slovník pojmů, metamodel, definice úhlů pohledu, apod.) a metodiky tvorby a údržby architektury (procesů a postupů dle fází, rolí a zodpovědností apod.).
• Architektonické schopnosti úřadu (orig. Architecture Capability) – definice (dokumentace) všech náležitostí (strategie, org. struktury, znalostí, rolí, kontrolních mechanismů, atd.) oddělení architektury úřadu.
• Knihovna individuálních architektur (orig. Architecture landscape) – dokumentace popisu vlastních individuálních architektur úřadu a jeho podřízených organizací, přes všechny domény a úrovně. Architektury jsou ukládány jako modely a artefakty (katalogy, matice a pohledy) odvozené z modelů i jako dokumenty, používající, komentující a rozšiřující tyto artefakty.
• Referenční knihovna (orig. Reference Library) – obsahuje návody, klasifikační a referenční modely, předlohy a vzory výstupů, příklady a všechny další formy akcelerátorů pro usnadnění a urychlení tvorby a údržby popisů individuálních architektur úřadu.
• Knihovna standardů (orig. Standards Information Base) – zahrnuje dokumentaci všech standardů a povinných návrhových vzorů, kterým navrhované individuální architektury úřadu a jeho podřízených organizací musí vyhovět.
• Auditní záznamy (orig. Governance Log) – dokumentace všech aktivit, kterými se uskutečňovala architektonická governance, například výsledky posuzování architektury projektů, zápisy a rozhodnutí z architektonické rady, udělené výjimky apod.

Oblasti obsahu architektonický rámec, knihovna individuálních architektur, referenční knihovna a knihovna standardů, tedy první čtyři oblasti shora v následujícím obrázku, vzhledem k charakteru svého obsahu, vycházejícího z architektonických modelů, vyžadují IT podporu modelovacím nástrojem pro správu architektonických modelů (EAM – Enterprise Architecture Management).

Efektivní práce každé architektonické kanceláře, včetně OHA MV, musí být přirozeně doplněna ještě sadou dalších nástrojů pro správu, sdílení a komunikaci znalostí, například nástrojem pro správu dokumentů (DMS – Document Management System) a správu znalostí (KMS – Knowledge Management System), společnou údržbu a sdílení znalostí (Wiki), portál se sociální sítí apod. Přístup ke všem těmto systémům by pro uživatele znalostí (nikoli pro editory modelů) měl být umožněn interním portálem úřadu. V případě OHA hovoříme také o Knihovně nebo Znalostní bázi Národní architektury VS ČR jako české GEA BoK (Body of Knowledge).

Vzhledem k tomu, myšlenkově je Národní architektura konceptuálním základem dalších modelovacích disciplín veřejné správy, předpokládáme, že úložiště NAP se stane klíčovým prvkem souboru informačních systémů, představujících spolu meta-informační systém státu, jako jsou ISoISVS, RPP a IS Modelovací a další. Proto centrální EAM nástroj bude vedle povinné notace ArchiMate podporovat i navazující notace, a to určitě BPMN, ERD a klíčové modely UML. Ostatní modelovací notace zatím není plánováno používat a nemusí být centrálním nástrojem podporovány.

Všechny architektonické výstupy - modely, pohledy na ně a varianty těchto pohledů musí být v lokálních úložištích úřadů i v centrálním architektonickém úložišti NA VS ČR klasifikovány dle jednotné sady atributů.

Ať už je přístup k modelu v kterémkoli úložišti zprostředkován v menu nebo navigaci jakoukoli kombinací (pořadím) níže uvedených dimenzí, vždy musí být model povinně klasifikován všemi níže uvedenými atributy, pokud není v pravidlech pro některý atribut stanoveno jinak. Linearizovaný klasifikační řetězec modelu (pohledu) se může stát technickou, kódovou součástí jeho označení.

Organizace VS a jejich modely jsou pro účely řízení a governance NA VS ČR klasifikovány v těchto skupinách dimenzí:

• Klasifikace modelovaných (modelujících) subjektů veřejného sektoru
• Klasifikace architektonických modelů
• Klasifikace pohledů na model

Zvláštní formou klasifikace úřadů a jejich modelů je jejich:

• Segmentace úřadů a modelů podle podobnosti

Výčet definovaných klasifikačních a segmentačních dimenzí v jednotlivých skupinách se nachází v Příloze 2 a ve Znalostní bázi.

Různé druhy modelů, lišící se podle účelu v procesu tvorby, údržby a užití modelů architektury veřejné správy, se budou lišit také svojí možností, potřebou a povinností klasifikace podle výše uvedených dimenzí prostoru architektur. V této části jsou provedeny analýzy a návrhy výběru klasifikačních a segmentačních atributů podle druhů modelů, kterými jsou:

• IM - Modely individuálních architektur úřadů
• MM - Model s metamodelem a definicemi pohledů (úhly pohledu).
• RM - Referenční modely
• VM - Modely povinných a doporučených vzorů
• PM - Modely teoretických a anonymizovaných praktických příkladů

Všechny druhy modelů mohou být označovány jedním společným řetězcem (Atribut1=hodnota;Atribut2=hodnota;…;AtributN=hodnota), přičemž u některých druhů modelů bude řada atributů nabývat hodnoty „0 – prázdný“

Příklady naplnění řetězce atributů hodnotami u různých druhů modelů a jejich vysvětlení obsahují následující části.

Jedno společné úložiště pro celostátní vizi a přehledové modely, pro sdílené prvky eGovernmentu a pro lokální architektury úřadů tedy bude obsahovat následující modely a pohledy na ně:

• Celkovou hierarchii a navigaci v modelech NA VS ČR
• Modely definic architektonického rámce NAR (metamodely, hlediska, metodická schémata, vzorové struktury modelů apod.)
• Referenční modely rozmanitého účelu a rozsahu
• Knihovnu standardů, stavebních bloků a architektonických vzorů
• Modely individuálních (skutečných) architektur úřadů

Tato struktura se bude opakovat v modelech na jednotlivých stupních hierarchie veřejné správy, která je z podstaty federativní. To znamená, že obecnější celostátní referenční model pro například ÚSÚ nebo kraje si resort nebo krajská korporace musí převzít, bude-li publikován, ale mohou si k němu doplnit svoje specifika a takto upravený referenční model resortu nebo kraje uložit ve své (lokální) knihovně referenčních modelů. A to bez ohledu na to, zda resort nebo kraj budou využívat jediné společné centrální úložiště nebo budou moci / muset využívat pouze svůj lokální nástroje nebo oba.

Těžištěm výstupů architektonické práce je soubor individuálních modelů všech úřadů/podniků (enterprise) veřejné správy ČR, zahrnující současně architektury současného stavu (As-Is), budoucího stavu (To-Be), všechny identifikované potřebné přechodné architektury na cestě mezi nimi a v případě potřeby výjimečně i architektury minulého stavu (As-It was).

Metodika NAR předpokládá, že každý úřad/podnik VS (ve významu enterprise) bude muset mít pro korektní modelování a poznání architektury své vlastní a architektur organizací, za něž ve smyslu této metodiky odpovídá, ve svém vlastním lokálním úložišti (architektonickém repozitory) také objekty modelů a vybrané pohledy všech „architektonicky“ nadřazených (širších, vyšších, obecnějších) architektur veřejné správy. A to architektury těch nadřazených úřadů, jejichž sdílené nebo obecné prvky musí nebo může užívat v současném stavu či plánuje užívat kdykoli do budoucnosti ohraničené horizontem modelování.

Naopak se nepředpokládá, že by samostatně modelující jednotky (např. ministerstvo nebo kraj) měly ve svém úložišti objekty modelů ostrých individuálních architektur svých „sousedů“ na téže úrovni hierarchického segmentu (např. ostatních krajů) nebo dokonce úřadů, s nimiž nemají nic společného. S výjimkou případů, kdy úřad užívá (sdílí) prvky poskytované jiným úřadem – pak tyto prvky a modely těchto úřadů musí v nezbytné míře zahrnout i do hierarchie úložiště svých architektonických modelů. Přesný způsob a rozsah této „nezbytné míry“ bude nejprve ověřen pilotními projekty.

Obsah centrálního úložiště umožňují některé vyspělejší nástroje dělit nejenom na tzv. modely, ale tyto seskupovat do tzv. projektů nebo balíčků (package). Při potřebě načíst do editoru nějaký model, je potřeba otevřít a načíst celý projekt, package, v němž je dílčí model obsažen. Z toho pohledu je výkonově výhodnější rozdělit obsah úložiště do více projektů (package), například po jednom pro každý resort či krajskou korporaci, ad absurdum pro každý jednotlivý OVS.

Na druhou stranu všechny pohledy uvnitř jednoho projektu (package) mohou sdílet libovolně objekty ze všech modelů navzájem a každá změna objektu je okamžitě patrná ve všech pohledech, na rozdíl od integrace mezi projekty (cross-package), která je v nástrojích omezenější a obtížnější. Slovenský příklad demonstruje umístění architektur všech ÚSÚ jako jednotlivé modely do jediného společného package.

Doposud neexistuje veřejně dostupné a obsahem naplněné centrální úložiště NA a dílčí již vytvořené modely ještě netvoří ucelenou hierarchii. Ta bude postupně vznikat podle zde uváděných pravidel.

Model, použitý jako prostředek pro vytvoření ilustrací tohoto dokumentu, tj. definic meta-modelu a definici hledisek NAR, je uložen a veřejně k dispozici ve výměnném formátu ve Znalostní databázi NA VS ČR, kde bude také pravidelně aktualizován.

Z modelů referenční knihovny jsou aktuálně ve Znalostní bázi NA VS ČR k dispozici:

• RM-BA, referenční model byznys architektury veřejné správy (obecný, neškálovaný pro jednotlivé kategorie OVS),
• RM-AA, referenční model aplikační architektury veřejné správy (obecný, neškálovaný pro jednotlivé kategorie OVS).

Další modely zde budou přibývat v průběhu rozvoje NAP a aktualizace NAR.

V knihovně standardů a vzorů NAP (a celé NA VS ČR) je v současné době pouze sada modelů architektur řešení pro připojení AIS k centrálním prvkům eGovernmentu, zvaná Architektonické vzory sdílených služeb eGovernmentu.

V této části budou uvedeny příklady, jak by mohla/měla vypadat struktura repozitory ArchiMate modelů v lokálním EAM nástroji typických modelujících jednotek v hierarchii veřejné správy, nebo odpovídající výseky obsahu v centrálním repozitory, které, jak uvedeno níže, budou vzájemně synchronizovány. Existují první návrhy OHA, jak by struktura mohla vypadat, ale neproběhl žádný pilotní projekt, který by navrženou strukturu ověřil v reálném režimu sdíĺení modelů mezi lokálním a centrálním úložištěm.

Také v hierarchiích modelů jednotlivých ÚSÚ mohou být pro snazší porozumění a navigaci modely jednotlivých úřadů kapitoly seskupovány do adresářových struktur, a to volitelně například podle způsobu zřízení, financování a kontroly organizací resortem, jako například u MZE jsou to:

• Organizační složky státu
• Státní fondy
• Státní příspěvkové organizace
• Státní akciové společnosti
• Státní podniky
• Národní podnik
• Veřejné výzkumné instituce

U jiných ministerstev, s velkým počtem podřízených organizací, se může hodit členění dle podobnosti v segmentech. Ministerstva s malým počtem řízených organizací nemusí svoji strukturu architektury dělat adresáři „za každou cenu“, může zůstat zcela plochá, viz příklad MPO.

V jiném projektu resortní organizace jednoho ministerstva se pracuje zatím také s plošší strukturou, rozdělenou do řady samostatně udržovaných souborů. Ty by po případném převedení do výkonnějšího nebo centrálního nástroje představovaly projekty nebo package.

• Projekt (package, soubor) - Individuální modely úřadu XY
  • „úřad xy“
    • Navigační diagramy
    • Pohledy
      • Strategická architektura
        • Motivační architektura
        • Byznys architektura
        • Aplikační architektura
        • Technologická architektura – IT infrastruktura
        • Technologická architektura – komunikační infrastruktura
      • Segmentová architektura
        • Schopnostní architektura
      • Prvky
        • Byznys architektura
        • Aplikační architektura
        • Technologická architektura
        • Motivační architektura
• Projekt (package, soubor) - Referenční modely
  • Referenční modely eGovernmentu ČR
    • dále struktura jako u individuálního modelu výše
  • Referenční modely odpovídajícího ministerstva „úřadu xy“
    • dále struktura jako u individuálního modelu výše
• Projekt (package, soubor) - Vzorové (sdílené) modely
  • Vzory eGovernmentu ČR - Architektonické vzory sdílených služeb
    • dále struktura jako u individuálního modelu výše
  • Vzory ministerstva
    • dále struktura jako u individuálního modelu výše
• Projekt (package, soubor) - Příkladové modely
  • Příklady publikované OHA MV
    • dále struktura jako u individuálního modelu výše
  • Příklady v rámci resortu
    • dále struktura jako u individuálního modelu výše
  • Ostatní získané příklady
    • dále struktura jako u individuálního modelu výše
• Projekt (package, soubor) – Metamodel a definice pohledů
  • Centrální metamodel a definice pohledů eGovernmentu ČR
  • Upravený metamodel a definice pohledů ministerstva
  • Dále upravený metamodel a definice pohledů „úřadu xy“.

Rozdělení do balíčků modelů v repozitory (package) nebo u menších nástrojů do samostatných souborů vychází z potřeby nekombinovat v jednom modelu objekty reálně existující v úřadu s objekty teoretickými (referenční modely a vzory), objekty jiných úřadů (příklady) a s definičními objekty (meta-úroveň).

Zde jako nadřazené vystupují prvky celostátní a krajské (sdílené navzájem mezi více kraji), pokud by takové existovaly. Architektura individuálních organizací kraje je navržena k seskupení podle odvětví veřejné správy, jak byla dosud u těchto organizací identifikována. Tento proces zpřesňování odvětví bude nadále probíhat, aktuálně na pilotním projektu MsK.

Zde je uveden příklad bohatého využití intuitivního členění a navigace adresářovou strukturou při tvorbě a údržbě architektur krajské korporace s cca 250 organizacemi z řady odvětví veřejné správy. Za každým uzlem této struktury se nachází jeden nebo mnoho EA modelů, vždy po jednom pro konkrétní organizaci.

Vedle zařazení každého modelu a do adresářové struktury podle některé ze segmentačních dimenzí (hierarchie VS, odvětví VS nebo forma financování a kontroly organizace, případně dalších) bude každý model ve svých vlastnostech (atributech, properties) klasifikován, tj. označen odpovídající hodnotou k klasifikačního modelu dané dimenze.

Aktuálně metodika NA VS ČR předpokládá, že struktura architektonického úložiště pro subjekty územní samosprávy na úrovni měst a obcí bude obdobná, jako struktura architektur samosprávních organizací na úrovni krajů.

Hypotetickou strukturu modelů a pohledů na umělém příkladu pro organizace města Benešova, jak by se mohla vypadat zařazena do centrálního architektonického úložiště.

Přitom platí, že model každé podřízené organizace bude mít tutéž strukturu jako MěÚ Benešov.

Zatím ale neproběhl žádný pilotní projekt, který by navrženou strukturu ověřil. Vzhledem k tomu, že se nepředpokládá v nejbližších letech synchronizace modelů města a obcí do centrálního repozitory, viz dále, nebude tlak na jednotnou strukturu lokálních EAM nástrojů příliš silný.

Stávající úroveň poznání potřeb řízení NA VS ČR a možností EAM nástrojů vede OHA k rozhodnutí, že celková správa nástrojů pro správu NA bude kombinovaná, tj. v části povinných osob centrální, poskytovaná jako sdílená služba a v části distribuovaná, provozovaná lokálně, s modely periodicky nahrávanými do centrální databáze.

Centrální nástroj EAM budou mít k dispozici pro aktivní editaci modelů architekti OHA a architekti vybraných povinných osob, tj. OVS na úrovni ÚSÚ, KRJ a ORP s tím, že se počítá s postupným náběhem. Prvními uživateli centrálního EAM nástroje budou architekti kapitol (ministerstev), architekti správců centrálních sdílených služeb eGovernmentu, významných samostatných ÚSÚ a architekti krajských korporací, v počtu cca do 50 modelujících organizací. Následně se předpokládá, že bude nástroj postupně rozšířen jako volitelná možnost pro všechny organizace ústřední statní správy, krajské korporace a vybraná města v počtu cca 300 modelujících organizací. Pokud se centrální nástroj EAM vždy po každém rozšíření rozsahu nadále osvědčí, bude v této podobě nabídnut také všem zbývajícím ORP a dalším obcím a podřízeným organizacím krajských korporací a ORP.

Výhodou tohoto centrálního modelování je plně konzistentní používání centrálních sdílených prvků eGovernmentu v modelech jednotlivých organizací, podstatně snazší využívání předloh, sdílení modelů a governance tvorby architektury VS. Na druhou stranu to vyžaduje velmi výkonné centrální repozitory s efektivní podporou týmové práce.

U uživatelů centrálního EAM nástroje se předpokládá, že zejména strategické modely architektur úřadů budou minimálně v povinném rozsahu podle pravidel Národního architektonického rámce udržovat přímo vzdáleným přístupem v tomto nástroji. Respektive udržovat je mohou i lokálně, ale budou mít plnou zodpovědnost za „svůj“ modelovací obsah i v centrálním úložišti.

Díky plné kompatibilitě centrálního nástroje se standardem výměnného formátu The Open Group ArchiMate File Exchange Format budou moci svoje modely exportovat do XML a importovat je do svých lokálních nástrojů, pokud již nějaké mají nebo si budou chtít pořídit. A stejně tak i naopak, pokud upřednostní jejich lokání vývoj. Předpokládáme, že takto lokálně budou povinné modely rozšiřovat o další objekty evidované pro vlastní potřebu a zejména budou prohlubovat modely architektury úřadu (Enterprise Architecture) na podrobnější úrovně architektur řešení a designu řešení. K tomu budou pravděpodobně vedle notace ArchiMate užívat i centrálně nepoužívané notace jako UML a další.

Ostatní organizace veřejné správy než ty, které budou povinně nebo volitelně přizvány k využití centrálního EAM nástroje, budou pro modelování architektury svého úřadu využívat výhradně své lokální nebo vzájemně ve skupině úřadů sdílené EAM nástroje. A to s tím, že budou-li mít takovou povinnost, budou povinnou část svých modelů periodicky odesílat DS k „nahrávání“ do centrálního úložiště. Obě úrovně správy architektonického úložiště budou sladěny vzájemně, obousměrně. To znamená, že všechna lokální úložiště budou mít k dispozici a budou muset povinně využívat pro modelování všechny jim kontextově příslušné informace o obecných, centrálních a sdílených prvcích architektury NA VS ČR, referenčních modelech, standardech a povinných architektonických vzorech. Obráceným směrem budou všechna lokální úložiště povinně synchronizovat veškeré povinné výstupy tvorby a údržby architektury úřadu (vlastní, skupinové i rozšířené) v rozsahu a způsobem stanoveným aktuálními pravidly jednotlivých typů angažmá.

Distribuce architektonického úložiště NA VS ČR může (smí) být i více stupňová. To znamená, že organizace, zodpovědné za synchronizaci svých skupinových modelů „korporátní EA“ do centrálního úložiště, mohou svá lokání úložiště spravovat v lokálně-centrálním režimu a svěřit lokální správu dílčí části oblasti své zodpovědnosti podřízeným organizacím. Pak ale musí zajistit, že informace poskytované do centra NA VS ČR (a zpět) budou včasné, úplné a správné. To znamená, že musí své lokálně-centrální úložiště synchronizovat směrem dolů k podřízeným úložištím obdobně, jako je ono samo synchronizováno nahoru. A obráceně – modely vzniklé lokálně musí organizace s povinností centrálního modelování importovat do svých částí centrálního modelu, tam uplatnit všechny nástroje governance, tj. například jedinečným způsobem použít ve svých modelech již existující prvky eGovernmentu. Podstatné je, že organizace budou plně zodpovídat za správnost svých modelů v centrálním repozitory, ať již modely vzniknou manuální editací nebo importem.

Základním prostředkem synchronizace modelů bude jednotný a všemi účastníky respektovaný a jejich nástroji podporovaný XML formát výměny ArchiMate souborů, vyhlášený The Open Group jako standard v srpnu 2015¹⁾²⁾. Je pravděpodobné, že struktura tohoto XML standardu bude pro potřeby synchronizace údajů v rámci NA VS ČR o několik údajů rozšířena, čemuž budou muset být schopny se přizpůsobit všechny ve VS používané EAM nástroje. V pracovní skupině The Open Group ArchiMate forum byl v souvislosti novou verzí specifikace ArchiMate 3.0 vyhlášen přístup, že při certifikaci nástrojů je za shodný se specifikací prohlášen jenom takový nástroj, který bude plně podporovat export i import pomocí standardního výměnného formátu. Lze tedy předpokládat, že pak většina nástrojů, podporujících ArchiMate, přijme i výměnný formát.

Pro případ rozšíření EA ve veřejné správě, kdy povinně nebo dobrovolně modelujících organizací a jejich modelů bude velké množství a správa těchto modelů v aktivním úložišti centrálního EAM nástroje, tj. v jeho úložišti přímo určeném pro editaci grafických diagramů nad modely, bude již komplikovaná a málo výkonná, vzniklo tzv. pasivní (sekundární) centrální úložiště. Má podobu grafové databáze, ve které jsou všechny modely a jejich diagramy uloženy v objemově a pro rychlost vyhledání optimalizované indexované podobě. Součástí tohoto sekundárního repozitory bude, kromě již existujících funkcí, také na míru vytvořený obslužný program, který umožní podle lineární indexace (klasifikace) modelů a jejich objektů sestavit libovolný řez uloženými daty, vytvořit z něj soubor ve výměnném formátu TOGAMEFF, a tak jej převzít k vytvoření grafických diagramů v aktivní části centrálního úložiště, odtutd i publikovat a zase vrátit zpět. Například může jít o úlohu sestavit aplikační mapu všech typů ERP systémů nebo spisových služeb všech modelujících subjektů napříč celou VS.

Tento postup je důležitý zejména pro možnost využít analytických schopností centrálního EAM nástroje pro vyhodnocení atributů modelů přes řadu vazeb mezi objekty, což jedna z nejsilnějších stránek zvoleného modelovacího jazyka ArchiMate.

Řešení centrálního (primárního) úložiště s podpůrnou databází sekundárního úložiště) bylo navrženo pro ideální kombinaci a využití silných stránek obou prostřední, a to již od počátku. V takové databázi, která ukládá strukturu všech objektů a jejich vazeb, je možné ukládat hromadné kontrolní a statistické úlohy nad celým souborem modelů, které by v aktivním týmovém editačním nástroji a jeho prostředky byly obtížné nebo málo výkonné. Naproti tomu editační nástroj následně převezme svoji roli při zpracovávání identifikovaných rozporů v modelech, při společných projektech tvorby modelů nebo při přípravě manažerských analytických výstupů a grafů nad modely.

Na trhu existuje nejméně několik desítek komerčních i freeware nástrojů pro EAM, v ČR je běžně užíváno do deseti z nich. Každý z nich je vybaven jinou sadou funkčních a nefunkčních vlastností a de-facto nejsou vzájemně porovnatelné a vzájemně si konkurující.

Tato situace klade vysoké nároky na tým a manažera architektury úřadu, aby dobře posoudili, jaké mají a v budoucnosti budou mít požadavky na tvorbu, údržbu a užití modelů a diagramů architektury úřadu v notaci ArchiMate a detailnějších modelů v navazujících notacích (jako BPMN a ERD nebo UML). Nelze soutěžit komoditní nástroj na cenu.

NAR usnadňuje vedoucím architektů volbu lokálního nástroje několika pravidly a pomůckami:

• EAM nástroj musí podporovat práci v notaci ArchiMate, včetně rozšíření specializovanými stereotypy podle NAR a včetně plné podpory výměnného formátu TOGAMEFF pro import i export modelů. A to nejlépe formou ověřené certifikace nástroje pro ArchiMate v The OpenGroup.
• EAM nástroj musí vedle ArchiMate podporovat ještě nejméně notaci BPMN (potřebnou pro procesní modelování a optimalizaci) a notaci ERD nebo část UML (pro konceptuální a logický datový model úřadu).
• Dodavatel EAM nástroje se musí smluvně zavázat k (automatické, neprodlené a v ceně investice a regulérní SW podpory zahrnuté) podpoře vždy poslední nejvyšší verze ArchiMate a přinejmenším ještě BPMN a ERD/UML.
• Nástroj by měl disponovat podporou hromadných editačních operací, přinejmenším podporou importu a exportu modelů ve formátu Excel/CSV.

Další již volitelné požadavky může zadavatel vybírat z kontrolního seznamu a vzorové funkční a ne-funkční specifikace pro zadávací dokumentaci VZ, které jsou součástí Znalostní báze NA VS ČR.

Seznam požadavků pro výběr nástroje EAM v úřadu by měl umožnit vedoucímu architektovi úřadu posoudit, jaké jsou reálné potřeby jeho týmu vůči nástroji, přinejmenším v následujících kategoriích:

Tabulka - Přehled kategorií požadavků na EAM nástroj.

Detailní dokumentace požadavků na EAM nástroj bude na základě zobecňování zkušeností komunity architektu veřejné správy udržována ve Znalostní bázi NA VS ČR.