TOGAF

The Open Group Architecture Framework (TOGAF) je rámec pro podnikovou architekturu, který poskytuje přístup pro navrhování, plánování, implementaci a řízení architektury podnikových informačních technologií. TOGAF je design na vysoké úrovni. Typicky je pomocí něj architektura modelována na čtyřech úrovních: business, aplikační, datové a technologické. TOGAF je silně závislý na modularizaci, standardizaci a již existujících, osvědčených technologiích a produktech.

TOGAF byl vyvinut od roku 1995 skupinou The Open Group, na základě DoD's TAFIM. Od roku 2016 skupina The Open Group tvrdí, že TOGAF používá 80 % společností Global 50 % a 60 % společností Fortune 500.^[1]

TOGAF je v současné době nejrozšířenějším "standardem" určujícím, co by mělo být součástí popisu organizace a jak by se tento popis měl provádět. Cílem TOGAFU je vyhledat způsob "rychlého" vývoje architektury a zároveň dodržet efektivní podnikové řízení. Nepopisuje jaké modely by měly být v architektuře, ale vede procesy, kdy by se měly vytvořit uvnitř architektur. Díky jeho škálovatelnosti lze tento standard využít ve vládní organizacích, velkých korporacích či dokonoce v středně až malých společnostech. TOGAF podporuje všechny úrovně architektury, počínaje business architekturou až po data a technologickou architekturu. Hlavními benefety TOGAFu jsou:^[2]

• Dokázaná metoda s dlouholetým výzkumem a vyvíjen předními business archiktekty
• Použitý společný slovník, tak aby každý v organizaci pochopil získanou informaci z cílové architektury.

Dále TOGAF má několik základních částí:

• Definuje metodu, jak by péče o enterprise architekturu měla vypadat (ADM metoda); metoda zahrnuje i řadu doporučení, jak ji používat
• Popis obsahu enterprise architektury a techniky, jak zajistit dlouhodobou životaschopnost v organizaci
• Formální popis všech elementů Enterprise architektury (specifikaci v XML), která je užitečná především pro tvůrce nástrojů podporujících modelování a správu EA
• Definice zralosti architektury, což může uživatelům pomoci v postupném zlepšování schopností práce s Enterprise architektury

Přehled^[3]

Architektonický rámec je sada nástrojů, které lze použít pro vývoj široké škály různých architektur. Měl by:

• popisovat způsob definice informačního systému z hlediska souboru stavebních bloků
• ukázat, jak do sebe stavební bloky zapadají
• obsahovat sadu nástrojů
• poskytovat společnou slovní zásobu
• zahrnovat seznam doporučených norem
• zahrnovat seznam vyhovujících výrobků, které lze použít k realizaci stavebních bloků

Specifikace architektury ANSI / IEEE 1471–2000 může být popsána jako základní organizace systému, ztělesněná v jeho složkách, jejich vzájemné vztahy a prostředí a zásady, kterými se řídí jeho design a vývoj.

TOGAF má svůj pohled, který může být specifikován buď jako formální popis systému, nebo podrobný plán systému na úrovni komponent, který řídí jeho implementaci, nebo jako struktura složek, jejich vzájemné vztahy a principy a pokyny upravující jejich návrh a vývoj v čase.

Metoda vývoje architektury (ADM) je jádrem TOGAF, který popisuje metodu vývoje a správy životního cyklu podnikové architektury.

Historie

Proces plánování architektury na bázi standardů DoD v systému TAFIM.

Vývoj TOGAF byl zahájen počátkem devadesátých let minulého století jako metodika pro rozvoj technické architektury a byl vyvinut společností The Open Group do rozsáhlého rámce podnikové architektury.^[4] V roce 1995 byla představena první verze TOGAF (TOGAF 1.0). Tato verze byla založena především na Technickém architektonickém rámci pro správu informací (TAFIM), který byl vyvinut koncem 80. let americkým ministerstvem obrany.

V prosinci 2001 bylo zveřejněno "Technické vydání" TOGAF 7.^[5] TOGAF 8 ("Enterprise Edition") byl poprvé publikován v prosinci 2002 a v prosinci 2003 byl publikován v aktualizované podobě jako TOGAF 8.1. Kolem roku 2005 se TOGAF stala ochrannou známkou The Open Group.^[6] V listopadu 2006 Open Group vydala TOGAF 8.1.1. Podle The Open Group má od února 2011 více než 15 000 osob certifikaci TOGAF. Od dubna 2018 má oficiální registr přes 77 500 certifikátů.^[7]

Evoluční vývoj z TOGAF 8 s názvem TOGAF 9, obsahuje mnoho nových funkcí, jako je:

• Zvýšená přísnost, včetně formálního obsahu metamodelů, který propojuje jednotlivé artefakty TOGAF modelu
• Architektonické úložiště a podnikové kontinuum
• Eliminace zbytečných rozdílů a přidání dalších příkladů a šablon

Další přidané pokyny a techniky zahrnují:

• Formální obchodní přístup k architektuře
• Plánování založené na obchodních schopnostech
• Návod, jak používat TOGAF pro vývoj bezpečnostních architektur a SOA

Nejnovější verze je TOGAF 9.2, která byla vydána 16. dubna 2018.

Open Group poskytuje organizacím TOGAF zdarma pro vlastní interní nekomerční účely.^[8]

Pilíře

Domény podnikové architektury

TOGAF je založen na čtyřech vzájemně propojených oblastech specializace zvané architektura domén:

• Obchodní architektura, která definuje obchodní strategii, správu, organizaci a klíčové obchodní procesy organizace
• Datová architektura, která popisuje strukturu logických a fyzických datových prostředků organizace a přidružených prostředků pro správu dat
• Architektura aplikací, která poskytuje plán pro jednotlivé systémy, které mají být nasazeny, interakce mezi aplikačními systémy a jejich vztahy k základním podnikovým procesům organizace s rámcem pro služby, které mají být vystaveny jako obchodní funkce pro integraci.
• Technická architektura nebo technologická architektura, která popisuje hardwarovou, softwarovou a síťovou infrastrukturu potřebnou pro podporu nasazení základních, kriticky důležitých aplikací

Metoda vývoje architektury(ADM)

Metoda ADM (Architecture Development Method) se používá k vývoji podnikové architektury, která bude splňovat obchodní a informační potřeby organizace. Může být přizpůsobena potřebám organizace a poté je využita k řízení provádění činností plánování architektury.

Proces je iterativní a cyklický. Každý krok kontroluje požadavky. Fáze C zahrnuje určitou kombinaci architektury dat a architektury aplikací. Mezi kroky B a C může být přidán další pohled za účelem poskytnutí kompletní informační architektury.

Pracovní postupy pro výkonnostní inženýrství jsou aplikovány ve fázi Požadavek a ve fázích Architektura podniku, Architektura informačních systémů a Technologie. V rámci architektury informačního systému je aplikován na architekturu dat a architekturu aplikací.

Podnikové kontinuum

Podnikové kontinuum(Enterprise continuum) je způsob, jak klasifikovat řešení a architektury na kontinuum, která sahají od generických základních architektur až po specifické organizace v rámci i mimo rámec architektonického úložiště. Patří mezi ně architektonické modely, architektonické vzory, popisy architektury a další artefakty. Tyto artefakty mohou existovat uvnitř podniku a také v IT průmyslu jako celku.^[9]

Podnikové kontinuum se skládá z architektonického kontinua a kontinua řešení. Architektonické kontinuum specifikuje strukturování aktiv opakovaně použitelné architektury a zahrnuje pravidla, reprezentace a vztahy informačních systémů dostupných podniku. Kontinuum řešení popisuje implementaci architektonického kontinua definováním opakovaně použitelných řešení.

Kultura TOGAF

TOGAF certifikované nástroje

The Open Group má certifikační program pro TOGAF 9 nástroje. Pro nejnovější registrace certifikačních nástrojů se odkazujte na The Open Group Register.^[10]

Kvalifikace

Open Group dohlíží na formální kvalifikace v TOGAF na dvou úrovních, které lze absolvovat po formálním vzdělávání nebo samostudiu. Studenti mohou tyto kvalifikace absolvovat prostřednictvím školicích společností.^[11]

Školení

(Level 1)Zajišťují, že jednotlivec pochopí podnikovou architekturu spolu s klíčovými pojmy a terminologií TOGAFcertifikace.

(Level 2) V návaznosti na kvalifikaci v základech se zajistí, že uchazeč je schopen analyzovat a aplikovat své znalosti na obchodní problémy.

Získání certifikovaného statusu TOGAF automaticky uděluje bezplatné členství v Asociaci podnikových architektů.

Struktura

Architektonický rámec je soubor nástrojů, které mohou být použity na vývoj široké škály různých architektur. Každý rámec by měl obsahovat následující vlastnosti:

• popsat metodu, která definuje informační systém ve formě stavebních bloků
• ukázat jak na sebe stavební bloky navazují
• obsahovat soubor nástrojů
• poskytnout společný slovník
• zahrnout doporučené standardy
• mít schválené produkty, které budou implentovát stavební bloky

ANSI/IEEE Standard 1471–2000 pro specifikace architektury IT systému je shrnuto jako soubor komponent, jejich vzájemných vztahů, prostředí a principů řízení jejich strukrury a další vývoj. Avšak TOGAF má svojí definici pro IT systém, kterou spefikuje jako formální popis systému nebo její části na komponentové úrovní implementace.^[12]

The enterprise continuum

Na rozdíl od ADM je kladen důraz v podnikovém kontinuum na podporu komunikace v podnikové architektuře, tak že uživatelé z různých oddělení dokážou najít společný jazyk a dokázali diskutovat na stejné úrovni. Mimo komunikace také podporuje znovupoužití architektonických elementů a aktiv. Součástí kontinuum jsou:

• Architektonický kontinuum – obsahuje soubor vazeb mezi různými architekturami
• Kontinuum řešení – obsahuje soubor řešení v jednotlivých architektur

Technický referenční model

TOGAF foundatation architekture je architektura obsahují množství generických služeb a funkcí, které poskytují základ pro specifické architektury a architektonické komponenty, ze kterých je lze sestavit. Architektura je rozdělena do dvou částí:^[12]

• Technický referenční model – obsahuje taxonomii generickou platformu služeb.
• Standardní informační báze – poskytuje databázi standardů, se kterými lze definovat určité služby a jiné komponenty podnikově orientovanou architekturu založenou na TOGAFu

Knihovny

Součástí standardu jsou knihovny TOGAFu, které podporují praktickou aplikaci přístupů TOGAFU. Knihovna slouží jako návod, šablona, struktura a dalších pomocných materiálů, které pomáhají a zrychlují tvorbu firemní IT architektury. Knihovna je udržována pod dohledem sdružení The Open Group Architecture Forum The TOGAF Library is maintained under the governance of The Open Group Architecture Forum.

Knihovna je rozdělena do 4 sekcí:

• Sekce 1: Zakládající dokumenty
• Sekce 2: Generické pokyny a techniky
• Sekce 3: Průmyslově-orientované pokyny a techniky
• Sekce 4: Podnikově-orientované pokyny a techniky

Dále obsahem TOGAFu jsou standardy používané při řízení enterprise architektury. To zahrnuje nejen už výše zmíněné organizační řízení ve firmě, tzv. architecture governance, ale také podporu práce architektů jako například standardy pro strukturované repozitáře technologií a dostupných komponent v organizaci. TOGAF také obsahuje sadu dalších technik, které architekti mohou využívat podle potřeby.

Postup dle TOGAF^[13]

Příprava

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.

Pohledy architektury

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ů.

Kritika

Ačkoliv bývá TOGAF považován takřka za standard v EA praxi, neobejde se bez následujících kritik:

• Výzkumy ukazují, že většina doporučení TOGAF je obvykle považována za nepoužitelnou a ani v organizacích zahrnutých do seznamu uživatelů TOGAF, které poskytuje skupina Open Group, není používána. To je důvod, proč lze TOGAF považovat pouze za sadu náhodných podniko-architektonických doporučení a použití TOGAF lze nejlépe vysvětlit jako studium jeho samého, tedy TOGAF, a poté praktikování něčeho jiného^[14]
• Chybí reálné příklady demonstrující skutečné praktické využití doporučení TOGAF. Existuje naléhavá potřeba některých podrobně zpracovaných příkladů a případů použití. Ačkoliv byly požadovány, nebyly připraveny od školitelů TOGAF nebo skupiny Open Group.
• Odborníci na podnikovou architekturu uvádějí, že krok za krokem může být TOGAF jen těžko následován. Naše počáteční předpoklady o TOGAF byly v tom, že by to byl jakýsi metodologický postup, který bychom mohli dodržet, abychom mohli vytvořit naší podnikovou architekturu, ale to se nezdařilo.
• Předpisy TOGAF jsou vágní a nesrozumitelné, protože pouze uvádí, že ADM by mělo být aplikováno bez upřesnění jakým způsobem.
• Jason Bloomberg tvrdí, že pro mnoho organizací získal TOGAF trakci pouze proto, že je lepší než nemít žádnou metodiku k tvorbě architektury^[15]
• Nedávné změny zavedené v TOGAF v9.2 se nezabývaly základními problémy přístupu mechanického plánování, které prosazoval TOGAF, ani dalšími předcházejícími metodologiemi architektury, včetně EAP a BSP^[16]
• Historická analýza ukazuje, že ohromující popularitu TOGAF lze považovat za čistě náhodnou a přisuzovanou pouze její účinné propagaci ve správném časovém období.

Výhody

TOGAF pomáhá organizacím implementovat softwarovou technologii do strukturovaného a orgranizovaného přehledu se zaměřením splnění business cílů. Vývoj spoléha na kolaboraci IT a business odděleními napříč celé orgranizace a cílem TOGAFu je vyřešit problém, aby všichni klíčoví stakeholdeři byli zahrnuti. Účelem TOGAFu je vytvořit systematický přístup vývoj, který by byl replikovatelný a s každou další fází vývoje obsahoval, co nejméně chyb. Cíle TOGAFU jsou:

• kvalitnější a efektivnější business operace
• kvalitnější a efektivnější digitální transformace a IT operace
• dosáhnout lepší návratnost investic (ROI)
• redukce rizika investic do budoucnosti
• zrychlení, zjednodušení a levnější procedura

Silné stránky TOGAF^[17]

TOGAF sám ideově vychází z modelu Zachman Framework a ve srovnáním s ním jsou patrné i jeho hlavní výhody:

o   Formalizace způsobu, jak se o enterprise architekturu starat (procesní rámec enterprise architektury)

o   Zkušenosti a postupy

o   Definuje nejenom co je součástí EA, ale i jak to dokumentovat

Nesporným přínosem TOGAF je, kromě popularizace významu samotné EA, usnadnění práce – rámec účinně radí, jak začít. Standard také pomáhá ideu v organizaci prosadit.

TOGAF samozřejmě pomáhá i firmám, které se podílejí na jeho vytváření, především formou systému certifikací pracovníků i samotné EA v organizacích. Zejména pro to je důležitá část přesně formalizující popis elementů EA, díky čemuž je možné dobře certifikovat i nástroje pro její správu. Z hlediska organizace – běžného uživatele a tvůrce Enterprise Architektury – tato formalizace i na ní navázaná certifikace fakticky nemá praktický význam.

Seznam použitých zdrojů

Externí odkazy

• Obrázky, zvuky či videa k tématu TOGAF na Wikimedia Commons