TOGAF

1. TOGAF Část 1.

2. Motivace • Doposud jsme si ukazovali, jaké architektury informačních systémů existují, z čeho se skládají a jaké mají vlastnosti • Zatím jsme se nezabývali uměním, jak takovou architekturu navrhnout • Dobrá metoda: využít existující metodiku založenou na best practices

3. TOGAF • TOGAF = The Open Group Architecture Framework • Světově velmi populární framework pro podnikovou architekturu (EA = Enterprise Architecture), od roku 1994 • Možnost kvalifikačních zkoušek • Jen několik příkladů společností, které TOGAF vytvářejí a podporují:

4. Příklady (1)

5. Příklady (2)

6. Historie • Verze 9 - verze uvolněná v únoru 2009 - je výsledkem velkých přepracování • Rodina verzí 8 vznikala od roku 2002, přičemž nejpodstatnější změnou, kterou přinesly, bylo zavedení pojmu Enterprise Continuum = podnikové kontinuum

7. Nevýhody TOGAF • Jako mnoho jiných frameworků v IT, TOGAF 9 nejde "použít hned po vybalení z krabice" • Má totiž kolem 780 stránek a je především velkou výzvou pro čtení. • Dozvíte se v něm více o tom, co udělat, než jak to udělat.

8. Nevýhody TOGAF • Tudíž nelze jednoduše spustit program Enterprise Architect (přestože ten s TOGAF pracovat umí) a začít tvořit • Neexistují začátečnické příručky, šablony dokumentů ani fungující příklady • Dobrá zpráva: jsou k dispozici checklists = kontrolní seznamy

9. Úvodní shrnutí • TOGAF se prezentuje (a prodává) jako nástroj, framework pro podnikové architektury (EA) • Je velmi dobrý na vývoj architektur EA • Ale je mnohem slabší na řízení EA

10. Co je Enterprise Architecture? • Jak už víme z dřívějška, EA je definována jen velmi vágně • Z hlediska frameworku TOGAF můžeme rozlišit 3 způsoby přístupu: • Přístup z hlediska IT • Akademický přístup • Pragmatický obchodní přístup

11. Přístup z hlediska IT • Tento přístup vychází z architektury IT systémů. • Systémoví architekti se snaží „přiohnout“ své vžité metody na úroveň podniku • TOGAF je tím silně ovlivněn

12. Akademický přístup • Tento přístup se nejprve ptá „co to je podniková architektura?“ • Z toho vychází a teprve následně hledá metody pro modelování podniku, vytváří meta-modely libovolného podniku, zabývá se jejich vývojem apod. • Jde o vývoj shora dolů.

13. Pragmatický obchodní přístup • Základní otázka: „Co se musí udělat, aby se z podnikových zdrojů IT získalo co nejvíc?“ • V hantýrce se tomu říká „IT / Business Alignment“ čili „sladění IT s obchodem“ • Není to deterministická úloha • Optimální postup závisí na stupni vyspělosti organizace

14. Sladění IT s obchodem Obchodní hodnota IT IT umožňuje realizaci obchodu IT následuje obchodní strategii IT je centrem nákladů

15. Ředitel pro IT (CIO) • Podnik, který pracuje s jinými komoditami a nehledí na IT jako na strategický faktor určující pozici podniku proti konkurenci, nemívá složitou strukturu ředitelství IT • Podnik, přes jehož IT účet se valí milióny ročně, bude mít všechny funkce které zde popíšu (a patrně ještě několik dalších)

16. Typické části řízení IT Podnikové architektury a jejího řízení se týkají jen části označené hvězdičkou. Ostatní části se jí nijak netýkají, a proto se jimi nebudeme zabývat.

17. Řízení IT • IT strategie: Někdo musí definovat strategii řízení podnikových zdrojů IT • PPM = Project Portfolio Management: Účty za IT existují mnohem déle než EA (dokonce než IT), proto manažeři mívají někoho, kdo zodpovídá za účty IT, kdo vyrovnává příjmy a výdaje a kdo plánuje výdaje na příští období

18. Enterprise Architecture, EA • O tom budeme hovořit za chvilku

19. IT Audit • Tato funkce je kritická pro úspěch podniku • IT audit se dělá ve většině organizací • De facto standard ve světě je COBIT (bude se na VŠMIE učit od příštího roku) • Ale s TOGAF to nijak nesouvisí, proto o tom nebudeme hovořit

20. IT Bezpečnost • Pro reputaci, integritu a bezpečnost organizace naprosto klíčová • Pro zajištění bezpečnosti existuje mnoho frameworků • S TOGAF to souvisí jen vzdáleně; dotkneme se toho na konci semestru, pokud na to zbyde čas.

21. Řízení dodavatelů • Řada organizací přenáší činnosti na své subdodavatele • To se týká také celého IT, resp. mnoha částí jejich práce s výjimkou těch klíčových • Dodavatele je třeba řídit (ve všech smyslech toho slova)

22. Pozor: • Od tohoto momentu dále se budeme zabývat jen těmi částmi označenými hvězdičkou • To znamená: • IT Strategie • EA = Enterprise Architecture

23. Struktura EA • Struktura EA se dá rozdělit do tří hlavních bloků: • Strategické úlohy, • Operativní úlohy • Základní úlohy

24. Strategické úlohy • Architekti EA často pomáhají řediteli IT (CIO) vyvinout strategii IT. Ale vedle toho existují ještě další strategické úlohy (tzn. úlohy s horizontem delším než 3-5 let): • Řízení portfolia IT dodá základní data potřebná pro strategické plánování, které spojuje strategické cíle se současným stavem (hrubý plán portfolia projektů)

25. Operativní úlohy • Každodenní úlohy architekta: aplikace a implementace strategií. • Architecture Governance = řízení • Nejdřív je potřeba vyhledat kritické projekty (mohou změnit architekturu) tak, že se sleduje portfolio projektů • Jakmile jich je identifikováno ~10%, už je potřeba na ně napojit tým architektů a tím z nich udělat normální proces

26. Základní úlohy • Když začínáte vytvářet EA, začnete od několika základů, zejména: • Často to je spuštění nástroje pro EA, třeba Enterprise Architect, aby vůbec byla šance to usledovat • Dále je potřeba najít vhodný meta-model • Pro zjednodušení stanovit (nebo vymyslet) standardy platné pro organizaci

27. Softwarový architekt jako profese • Ukážu krátkou historii software a architektury softwaru. • Historie vývoje softwaru přinesla řadu abstrakcí a metafor, které se v průběhu času postupně rozrůstají. • To platí pro software i příbuzných oborech, včetně návrhu programovacích jazyků, platforem, procesů, organizace a nástrojů používaných k rozvoji softwaru.

28. Softwarový architekt jako profese • Důvodem je skutečnost, že jsme konfrontováni s množstvím software, který roste exponenciálně • Pojem softwarový architekt sám se objevil v půlce padesátých let. • Název pozice softwarového architekta je dnes velmi v módě • Většina lidí v obchodu se definuje jako „softwaroví architekti“, protože jejich plat je pak mnohem lepší a protože titul je přitažlivější než pouhý „programátor'

29. Trocha historie • Software jak jej známe dnes, artefakt nezávislý na hardwaru, začal se vyvíjet v 50. létech • GUIDE / SHARE organizace, která se zabývala výměnou software pro počítače IBM, byla založena v roce 1955 a zasloužila se o vývoj mnoha operačních systémů (System OS/360 byl typickým představitelem těchto projektů). Fred Brooks, hlavní designér tohoto projektu publikoval své zážitky v knize „The Mythicam Man month“

30. Úplné začátky • Vůdčí osobnosti programování se setkali v roce 1968 na slavné konferenci NATO v Garmisch, aby přemýšleli o tom, jak léčit "softwarovou krizi" s použitím nových metafor softwarového inženýrství. • Softwaroví architekti na této konferenci, nebo v té době, ještě nebyli. • V té době byly položeny základy pro techniky, jako je abstrakce dat a modularizace.

31. Začalo to vývojem jazyků • Výzkum byl zaměřen především na programování: místo tehdy běžných strojových jazyků, zavedli vyšší programovací jazyky (ALGOL 68, COBOL, ADA 1980). • Pojem „softwarová architektura“ se začal systematicky objevovat po roce 1995 [Gerlan, Shaw, Bass]

32. Softwarová architektura • Softwarová architektura softwarového inženýrství je metafora, která se snaží vysvětlit procesy kolem tvorby softwaru pomocí analogie jiných oborů (strojírenství, stavebnictví) • Lidé se snažili převést metody a postupy ze stavební architektury na vytváření softwarových architektur

33. Gang čtyř • V té době Gang čtyř [Gang of Four] vytvořil základ k popisu opakujících se postupů v softwaru. • Doporučili používat návrhové vzory. • Je třeba poznamenat, že Go4 nebyli první, kdo převedli návrhové vzory • Programátoři, kteří se vyvíjeli tyto vzory, se později začali nazývat softwarovými architekty.

34. Dnešní stav • Od té chvíle se softwarový architekt začal vyvíjet jako samostatná profese: učí se na seminářích a univerzitách, dělají se certifikace pro softwarové architekty, existují dohody o učebních osnovách pro softwarové architekty. • A jak tato skupina dostává daleko lépe zaplaceno než 'jen obyčejná programátoři', můžeme pozorovat tendenci přesouvat se do softwarové architektury místo jen obyčejného programování 

35. Podniková architektura • Růst softwaru se nezastavil na hranicích jednotlivých (i když velkých) softwarových systémů. • Metafora architektury a softwaru se neosvědčuje při vysvětlování, jak se vypořádat s krajinnými komplexy, které se skládají ze stovek či dokonce tisíců velkých softwarových systémů. • Proto zavádím novou metaforu s názvem městské plánování (viz později)

36. Podniková architektura • Rozsáhlé systémy jsou dobře provázané vertikálně: od uživatelského rozhraní až k databázové vrstvě, • Ale nebyly (a mnohdy nejsou) tak dobré v horizontálním provázání. Dodnes zůstávají na úrovni integrace dat nebo dokonce jen dávkového kopírování dat.

37. Rozsah • Pokud se Softwarový Architekt zabývá jedním systémem, nebo možná shlukem 7 nebo 10 systémů, pak Enterprise Architect musí řešit souhrn všech aplikací v podniku. Pro malé podniky to může být 50 aplikací, pro významnou pojišťovnu by to mohlo být 300 systémů a globální výrobce automobilů typicky má ve svém portfoliu více než 3000 až 4000 IT aplikací - jednotlivé aplikace, pro zaměstnance a pracovní stanice nepočítaje.

38. EA jako urbanista • Enterprise Architekt je jako urbanista: musí řešit spolupráci s téměř každou skupinou subjektů ve společnosti, ať už je to vrcholového vedení, ať už to jsou skupiny uživatelů, nebo vazba na veřejné agentury (třeba Komise pro cenné papíry), nebo orgány, které se zabývají ochranou dat, a v neposlední řadě se skupinami, které chtějí novou aplikaci.

39. EA jako urbanista • Protože tyto úkoly mají některé podobnosti s prací městského urbanisty, Enterprise Architekt se někdy též nazývá urbanista. • Urbanisté neposkytují podrobné plány pro jednu budovu. • Poskytují územní plány, které určují, jaké druhy staveb budou uspořádány ve které zóně. • Starají se o soubor staveb města (i když by také měli mít kvalifikaci na projektování jen jedné).

40. Příklad: rozdělení zón (Vídeň)

41. Poznámky k akademickému přístupu • Jako příklad pro akademický přístup k podnikové architektuře můžeme použít přístup univerzity ze St. Gallen • Tato univerzita používá následující definici podnikové architektury, která je také podporována Open Group

42. EA: Definice (1) • Podle ANSI / lEEE Std 1471-2000, je architektura definovaná jako 'základní organizace systému, zakotvená v jeho komponentech, jejich vztazích k sobě navzájem a k okolnímu prostředí a zásady jeho designu a vývoje ‚ (lEEE 2000). • Enterprlse Architecturu (EA) tudíž je třeba chápat jako (1) základ organizace řízení společnosti, a to buď jako celek, nebo společně s partnery, dodavateli a / nebo zákazníky („extended enterprise“), nebo po částech (např. divize, oddělení, atd.), stejně jako (2) zásady jeho konstrukce a vývoje (Open Group 2003).

43. EA: Definice (2) • Protože EA model je reprezentací architektury (současného nebo cílového stavu) skutečné organizace, EA framework poskytuje: • 1 nebo více meta-modelů pro popis EA, • 1 nebo více metod pro návrh a vývoj EA, • Společný slovník pro EA, • a případně i Referenční modely, které lze použít jako šablony, nebo doporučení pro design a vývoj EA.

44. EA: Definice (3) • Tuto definici konkretizujete tím: • Jak modelujete podnik jako celek od strategií přes schopnosti a obchodní procesy až na úroveň infrastruktury, • Jak jste schopni odvodit vlastnosti nebo určit, co je dobré nebo špatné s ohledem na strategické cíle podniku • Jak naleznete správný meta-model pro podnikové architektury ve vašem podniku

45. EA: Definice (4) • Jak budete vyvíjet nebo sdružovat meta-modely

46. TOGAF verze 9 • Důraz je na vytvoření konkrétní architektury: pro systém, pro soubor systémů nebo architekturu podniku jako celku. • Důraz se neklade na: • Rozvoj IT strategie založené na obchodní strategi • Řízení portfolia aplikací: Nakládání s tisíci existujících aplikací a rozhodnutí, které mají budoucnost, které je třeba změnit a které je třeba nahradit • Řízení architektury: Toto je zmíněno, ale nepovažuje za hlavní

47. TOGAF verze 9 • Jádrem TOGAF je ADM (Architekture Development Method) • Během vývoje TOGAF bylo jeho jádro, ADM, poměrně stabilní a bylo jen rozšiřováno (zavedení podnikového kontinua) • TOGAF se vypracoval z jednoduchého frameworku do komplexní metodiky pro EA

48. Shrnutí • Zatím jsme viděli, že existují různé přístupy k Enterprise Architecture v závislosti na individuálních východiscích a cílech. • Dále ukážu používání seznamu úkolů Enterprise Architekta • Popíšeme si hlavní bloky úkolů, které prokazují, co TOGAF dovede • Dáme si odkazy na další materiály, které budete moci používat

49. Děkuji za pozornost