Co mají funkční informační systémy společného? Stabilní základ. Za špatně budovanou architekturou ICT jsou padající aplikace, pomalé systémy, problémy s upgradováním a ve výsledku nespokojený uživatel. Mezi typické problémy neřešené Enterprise architektury patří nedokumentovaná rozhraní mezi aplikacemi, problematické přepoužití komponent, více zdrojů pro stejná data, hodně platforem a s tím rostoucí náklady na rozvoj a údržbu ICT. Že vám to něco říká? Pojďme se podívat, jak je možné tyto problémy Enterprise architektury řešit pomocí metodiky TOGAF. V článku si popíšeme co je TOGAF, jak se liší od ostatních metodik a jak jej využít.

Co je TOGAF, jak se liší od ostatních metodik

Požadavky na funkčnost a komplexnost IT stále narůstají. IT aplikace a systémy se stále více otevírají. Je kladen důraz na mobilitu, dostupnost a bezpečnost. Nejedna organizace se tak dostala do těžkých problémů při upradu či rozvoji ICT. Enterprise architekt požaduje po solution architektech spolupráci při dokumentaci a rozvoji celého informačního systému. Pokud je dodavatel schopen rozumět těmto potřebám zákazníka a ví, jak fungují frameworky pro řešení Enterprise architektury, tak se to pro něj automaticky stává konkurenční výhodou, která mu ve výsledku přináší i úspory MD. TOGAF je jednou z metodik, která říká jak řídit návrh komplexních aplikací a jak ukládat výstupy architektury do architektonického repository k dalšímu využití jak pro Enterprise architekta, tak pro solution architekta dodavatele.

Přehled metodik pro Enterprise architekturu

Rozdíly mezi rolemi Enterprise a Solution architekt

Aplikace, které v Cleverlance vyvíjíme a pomáháme u zákazníků integrovat, se stanou součástí portfolia desítek až stovek aplikací, které tvoří např. informační systém banky. My jako dodavatel máme na projektu vždy svého solution architekta, který pomáhá detailně s technickou specifikací a ví o aplikaci vše. Cílem zákazníka je udržovat si detailní informace o všech částech informačního systému a být schopen řešit změny, které integruje buď Cleverlance nebo někdo jiný. Celá řada firem má problémy převzít a udržet detailní informace od solution architektů, které bude potřebovat při změně aplikací nebo integraci aplikace s jinými částmi systému. Celkovou koncepci a rozvoj všech aplikací u zákazníka si zajišťuje Enterprise architekt, který musí vědět, co ty desítky až stovky aplikací mají za funkcionalitu, jak jsou tyto aplikace propojené a jaká sdílí data. Je naprosto nezbytné, aby Enterprise architekt měl prostředky, jak řídit celou architekturu informačního systému.

Na schématu níže je modelový informační systém, kde CPS představuje penzijní systém Cleverlance se svým Solution architektem, který je dodán ze strany Cleverlance. Další systémy pro správu dokumentů (DMS), péči o zákazníky (CRM) či hlavní podnikový systém (ERP) mají "své" (často externí) solution architekty. Je zřejmé, že se skončením projektu odejde se solution architektem i detailní know-how. Enterprise architekt je ten, kdo toto know-how bude schopen nejen uchovat v architektonickém úložišti, ale i poskytnout stávajícím i budoucím solution architektům v podobě informací o jednotlivých rozhranních a sdílených datech jednotlivých aplikací. Z existence řízené Enterprise architektury tak těží jednak interně firma, tak i případný externí Solution architekt.

Role Enterprise a Solution architekta v prostředí ICT

Kdo kromě architektů TOGAF využije?

Pro business analytika Cleverlance TOGAF přináší jasné požadavky na artefakty (matice, schémata, diagramy), které mají být v rámci business architektury dodány např. Use-case diagramy, Class diagramy apod. dále říká, jaké nástroje mají být použity (Visio, Enterprise architekt, Archimate apod.) pro tvorbu schématu a do jaké míry má být proveden detail popisu business architektury. Cílem je zajistit, aby výstup business architektury nejen vypadal stejně, ať už jej udělá Hana nebo Honza z Cleverlance, ale aby zákazník měl sjednocený popis i napříč různými dodavateli. Pokud pak zákazník má takto dokumentovanou architekturu (nejen tu business), tak při rozvoji IS a provádění změn je pro všechny dodavatele příjemnější orientovat se ve schématech, které dodal někdo jiný, což zrychluje práci nejen Cleverlance, ale celého týmu zákazníka. Tím sjednocujícím dokumentem, který TOGAF přináší a po kterém se jako dodavatel máme ptát, je tzv. „Architecture method“ dokument, který drží Enterprise architekt ve svém architektonickém repository. Takže až po vás bude chtít zákazník vytvořit „Business Footprint diagram“, tak víte, že jej najdete v „Architecture method“ dokumentu, který se nachází v architektonickém repository ve složce „Architecture metamodel“, kde si jej sami stáhnete, protože vám zákazník dal do architektonického repository přístup pro čtení. Zákazníkovi odpadne složité vysvětlování spoustě analytikům/solution-architektům, co mají a jak popisovat při návrhu architektury aplikace, což ve výsledku šetří čas a peníze všem.

Pro vývojáře, databázové specialisty, technické architekty analogicky „Architecture method“ dokument jasně přináší seznam a vzory výstupů architektury, jak mají být dodány pro business, aplikační, datovou a technologickou vrstvu budoucí aplikace. TOGAF zároveň řeší kdy a kdo má být příjemcem těchto architektonických výstupů pomocí „Stakeholder mapy“.

TOGAF je trend v Enterprise architektuře, který se poslední 2-3 roky značně rozšiřuje už i ve státní správě okolo e-govermentu. V soukromém sektoru se s prvky aplikace TOGAFu setkáváme v Komerční bance, v O2, ve Vodafone, v KBC a servisních organizacích, které se starají o implementaci IS pro tyto subjekty – zde stojí za zmínku T-Systems nebo pro PPF skupinu Embedit. Celá řada firem a našich zákazníků nyní v březnu 2016 poptává Enterprise architekty (Komerční banka, Embedit, Microsoft, Česká spořitelna a další). Tím je jasně dán trend řešit Enterprise architekturu a Cleverlance se bude stále více potýkat s požadavky na zajištění souladu dodávky s metodikou TOGAF. Ve státní správě se TOGAF a modelovací jazyk ArchiMate ustanovil v Národním architektonickém plánu eGovernmentu ČR. Je tedy nutné, aby klíčoví lidé na našich projektech (architekti, vývojáři ale i projektoví manažeři) měli nejen povědomí o metodice TOGAF, ale i získali certifikaci TOGAF alespoň na stupeň Foundation.

Jak TOGAF funguje a příklady užití

TOGAF využívají manažeři a Enterprise architekti jako "manuál", resp. best practice pro návrh Enterprise Architektury (EA) společně s Archimate - podpůrným modelovacím jazykem; oba standardy patří do mezinárodně akreditovaných programů "The Open Group Architecture". Navíc poslední aktualizace Archimate 2.1 spolu s TOGAF 9.1 integrovala nejmodernější poznatky z oblasti EA, které nově zahrnují i řešení servisně-orientované architektury (SOA) a informační bezpečnosti. TOGAF si poradí s integrací na procesy ITIL, Prince2 či SCRUM.

Jádro TOGAF tvoří Architecture development method (ADM) a jeho fáze, které si stručně popíšeme:

Preliminary

Popisuje přípravné aktivity vedoucí k ustavení útvaru architektury včetně definice architektonických postupů s ohledem na kontext organizace s cílem odstranit problémy neřešení Enterprise architektury a to i z pohledu bezpečnosti IS. Zde se zakládá architektonické úložiště, které má jasně definovanou strukturu - nejde jen o složku s projektovými adresáři, jak to známe z mnoha firem, ale jde o 3 úrovně detailu architektury - obecné schéma architektury celého systému na jednom listu, pak segmentová architektura jednotlivých aplikací a v třetí úrovni detailní architektura jednotlivých aplikací. S obecným schématem a segmenty pracuje spíše Enterprise architekt, solution architekt potřebuje detailní architekturu v třetí úrovni.

Architecture Vision

Připravuje variantní návrh řešení. Fáze A představuje prvotní návrh např. celého nového IS nebo jeho části včetně identifikace klíčových vlastníků aktiv a procesů (stakeholders) a indikace rozpočtu pro sponzora. Vytvoření Architecture Vision dokumentu v souladu s požadavky businessu a s ohledem na architektonické principy včetně bezpečnostní politiky. V Komerční bance jde o tzv. „Project Definition“. Řeší se zde rovněž analýza rizik na projektu.

Fáze B: Business Architektura popisuje rozpracování Business Architektury k podpoře odsouhlasené Architektonické vize (návrhu). Modelace use-case a diagramu tříd může být pomocí UML, nicméně TOGAF má vlastní modelovací jazyk ArchiMate, který je k dispozici zdarma včetně modelovacího nástroje Archi.

Fáze C: Information Systems architektura popisuje rozpracování Information Systems Architektury k podpoře odsouhlasené Architektonické vize. Jde o přípravu podkladů ve formě entitně-relačních diagramů a data-flow diagramů v databázové vrstvě. V aplikační vrstvě architekt pro vývojáře připravuje seznamy služeb pro programování dílčích XML kódů (WSDL).

Fáze D: Technologická architektura popisuje rozpracování Technologické architektury k podpoře odsouhlasené architektonické vize. Modeluje se nová topologie sítě, zapojení serverů, definice datových úložišť či revize havarijních plánů a plánů kontinuity.

Pro fáze B, C, D ve společných krocích popisujeme Baseline (AS-IS) a Target (TO-BE) architekturu, identifikujeme GAPy, tvoříme Road mapu projektu. Klíčovým výstupem je Architecture definition document, což je rozsáhlejší obdoba Technické specifikace v Cleverlance či poměrně věrná obdoba dokumentu „Solution Design“ v Komerční bance.

Fáze E: Příležitosti & Řešení popisuje prvotní návrh implementačního a migračního plánu včetně architektonické roadmapy. Zahrnuje identifikaci pracovních balíčků k implementaci na základě výstupů architektonické práce v předchozích fázích B, C, D. Zde je již významné zapojení projektového managementu třeba dle Prince2. Zde se řeší detailní rozpočet a alokace v čase na implementaci. Rovněž může dojít k rozslotování projektu pomocí tzv. Transition architektury.

Fáze F: Plánování migrace popisuje finalizovaný implementační a migrační plán případně tranziční architekturu s cílem dodat cílovou architekturu aplikace či IS. V případě, že nejsme v souladu s indikativním rozpočtem z Fáze A, tak je zde prováděno škrtání v projektu na základě cost/benefit a value delivery s klíčovými stakeholdery a sponzorem.

Fáze G: Řízení implementace je implementační. Enterprise architekt předává hotové architektonické návrhy a účastní se celé řady procesů, mezi které patří zajištění dodávky security do projektu včetně subdodavatelů, zajištění Compliance Review (audit), řízení Solution Architektů, dodávky bezpečnosti v rámci vývoje, post-implementační review a zaštiťuje Risk management v průběhu implementace.

Fáze H: Změny návrhu pokrývají celou řadu typů změn přes jednoduché změny k inkrementální m změnám až po rearchitektonické změny. Togaf rozlišuje, zda je nutné provádět popis architektury pro situace, kdy zákazník chce, aby tlačítko bylo modré a ne červené a pro situaci, kdy se významně zasahuje do více vrstev architektury (třeba do business a datové).

Fáze Management požadavků poskytuje rámec na dodávku jakýchkoliv funkčních i nefunkčních (např. bezpečnostních požadavků) kdykoliv v rámci vývoje nových IS. Řeší prioritizaci požadavků a vyhodnocení jejich dopadů.

Závěrem

TOGAF je aktuální trend řízení Enterprise architektury a vývoje IS s přesahem do procesů fungování organizací. Nyní se prosazuje i ve státní správě s ohledem na kybernetický zákon a metodiky NBÚ. Ministerstvo vnitra pomocí TOGAF nyní zahájilo evangelizaci EA do ostatních ministerstev s cílem podpořit e-government v ČR. Díky propojení řetězce dodávek a subdodávek požadavky propadají i k našim zákazníkům a s požadavky na řešení Enterprise architektury se budeme na projektech potkávat stále více. Je tedy naprosto nezbytné kromě porozumění typickým problémům neřešené Enterprise architektury i být schopen problémy řešit a pokud jste článek dočetli až sem, tak víte, že metodika TOGAF tyto problémy Enterprise architektury umí řešit a věřím, že tento článek pro vás bude prvotním impulzem k dalšímu seznamování se s metodikou TOGAF.

Martin Tobolka