Zjednodušení procesu rozvoje podnikové architektury

Zjednodušení procesu rozvoje podnikové architektury Martin Hladík IBM Česká republika Vysoká škola ekonomická v Praze Fakulta informatiky a statistiky Katedra informačních technologií [email protected] Abstrakt: Rozvoj podnikové architektury je prezentován různými rámci odlišným způsobem. Článek srovnává přístupy rámců TOGAF, Federal Enterprise Architecture a Pragmatic Enterprise Architecture s cílem navrhnout společný generický postup. Následuje úvaha o využití těchto přístupů v prostředí malých a středních podniků. Klíčová slova: Podniková architektura, postup rozvoje, malé a střední organizace Abstract: Enterprise architecture development process is defined differently by various frameworks. This text compares development process approaches of TOGAF, Federal Enterprise Architecture and Pragmatic Enterprise Architecture, to propose a common generic process. Then it is discussed how to apply this approach in landscape of small and medium businesses. Key words: Enterprise architecture, development process, small and medium business

1. Úvod Rámce (angl. framework) o podnikové architektuře se téměř shodují ve smyslu, cílech i zaměření této disciplíny (např. Schekkerman, 2003). Jinak tomu však je v detailním pohledu na postupy, metody a nástroje, které poskytují. Základ každého rámce tvoří tzv. proces – postup rozvoje podnikové architektury (angl. enterprise architecture development process development). Proces obvykle popisuje časovou souslednost kroků, které se v rámci rozvoje podnikové architektury řeší (viz podrobně dále). Pro jednotlivé kroky definuje jejich cíle a obsah. Vzhledem k faktu, že zavedení a využívání podnikové architektury v praxi organizace je netriviální a dlouhodobý úkol, je proces rozvoje podnikové architektury obvykle charakterizován (např. The Open Group, 2009) jako:  postupný – inkrementální;  opakovaný – iterativní;  kontinuální. Postupný rozvoj podnikové architektury má smysl především z důvodu zjednodušení řešené úlohy a tím snížení rizika neúspěchu, stejně jako z důvodu podpory konkrétních strategických cílů organizace. Tento postup se kontinuálně opakuje a v principu končí až při zániku organizace. Opakování procesu však neznamená realizaci stejných úkolů. Naopak každý průchod procesem má jiné zadání, které odpovídá aktuálním potřebám organizace. Přesto lze

22

SYSTÉMOVÁ INTEGRACE 4/2011

Zjednodušení procesu rozvoje podnikové architektury

konstatovat, že každý proces se primárně soustředí na potřeby organizace a sekundárně se zabývá rozvojem samotné disciplíny podnikové architektury. Životní cyklus se v kontextu podnikové architektury využívá spíše v souvislosti s projekty, které podniková architektura podporuje, nebo dokumenty či jinými výstupy, které podniková architektura využívá a tvoří. V další části se budeme zabývat procesem, resp. postupem rozvoje podnikové architektury. Proces je obvykle formulován jako sekvence několika kroků. Nabízí se však řada možností, jak proces aplikovat v praktickém využití – některé kroky procesu lze opakovat, může existovat tzv. hierarchie procesů dle úrovně, na které se řeší podniková architektura, či je proces uváděn v kontextu jiných pohledů. Cílem tohoto příspěvku je porovnat procesy rozvoje podnikové architektury ve zvolených rámcích (viz násl. kap.), identifikovat jejich společné společné znaky a odlišnosti, následně navrhnout zjednodušený proces. Dalším úkolem je posoudit využitelnost zkoumaných rámců v prostředí malých a středních organizací.

2. Přístupy k procesu rozvoje podnikové architektury Pro srovnání různých přístupů k procesu rozvoje podnikové architektury jsem zvolil rámce TOGAF 9, Federal Enterprise Architecture (FEA) a Pragmatic Enterprise Architecture (PEA). Důvodem mého výběru je skutečnost, že každý rámec staví svůj přístup na jiných základech, poskytují tedy i značně odlišné přístupy. TOGAF je rozvíjen zástupci širokého komerčního i akademického spektra a je využíván řadou největších podniků ve světě. FEA je nástroj pro řízení architektury státní správy USA, často je však využívaný jako inspirace i jinými organizacemi. PEA akcentuje, jak již jeho název vypovídá, pragmatický přístup k řešení podnikové architektury. Kritici PEA však upozorňují na častou strohost tohoto rámce. TOGAF poskytuje metodu Architecture Development Method (ADM), která popisuje základní proces rozvoje podnikové architektury. Součástí procesu je deset kroků (podrobně viz kap. 3, také obr. 1), které se často spojují do fází (resp. iterací v terminologii TOGAFu). Stručně lze jednotlivé fáze charakterizovat následovně: 1. Kontext architektury (angl. Architecture context), jejímž smyslem je mobilizovat práce na podnikové architektuře, zvolit vhodný přístup, definovat základní rozsah práce a vizi (součástí vize je dohoda se sponzory, tedy i vyčíslení přínosů). 2. Definice architektury (angl. Architecture definition) slouží pro rozpracování rozsahu a náplně práce přes všechny architektonické vrstvy (TOGAF rozlišuje tři základní vrstvy: byznysová, informačního systému, technologická). Cílem této fáze je identifikace možností řešení. 3. Plánování změny (angl. Transition planning) navazuje na předchozí fázi a rozpracovává detailní plán změny pro zvolené řešení. Kontrola architektury (Architecture governance) zajišťuje architektonický dozor nad prováděnými změnami. 4. Kontrola architektury (Architecture governance) zajišťuje architektonický dozor nad prováděnými změnami.


23

Martin Hladík

Obr. 1 – Proces rozvoje podnikové architektury, angl. Architecture Development Method (The Open Group, 2009) TOGAF nabízí několik možností použití ADM, počínaje jediným průchodem procesu (v takovém případě je cílem vytvořit kompletní podnikovou architekturu v rámci jediného cyklu) až po tzv. hierarchické průchody. Hierarchické uspořádání procesů umožňuje rozlišit rozdílný přístup na strategické (celopodnikové) úrovni a přístup k realizaci podnikové architektury na nižších úrovních. Na nižších úrovních rozlišuje tzv. segmenty (podobně jako FEA, viz níže) a domény (volně přeloženo, angl. capability). Podrobněji se touto problematikou zabývám v kap. 4. Dalším zkoumaným rámcem je Federal Enterprise Architecture (FEA). Z důvodu aplikace tohoto rámce ve státní správě USA je klíčovým stavebním kamenem tzv. segmentová architektura. Segment lze vnímat jako konkrétní agendu, kterou státní správa zajišťuje (hlavní segment – například registr občanů, nebo podpůrný segment – například řízení lidských zdrojů). Jednotlivé organizace státní správy zajišťují několik agend současně. S ohledem na podrobné rozpracování segmentové architektury v rámci FEA se zde soustředím na proces rozvoje segmentové architektury. Ve srovnání s TOGAF je také třeba upozornit, že FEA považuje za klíčový (ne-li hlavní) přínos podnikové architektury ve zvyšování výkonnosti organizace. Díky tomu je i samotný proces rozvoje architektury postaven na principu zvyšování výkonnosti. Například v úvodní fázi procesu se obhajuje zadání s ohledem na příspěvek k výkonnosti, posléze se měří reálný přínos atp. 24



FEA pro tento účel vytvořila specifickou vrstvu podnikové architektury, která se zabývá měřením výkonnosti organizace. Oporu této vrstvy tvoří referenční model výkonnostních parametrů (tzv. Performance Reference Model). Tato vrstva je integrována do procesu rozvoje architektury (viz obr. 2 – Proces rozvoje segmentové architektury, horizontální osa Performance Improvement Lifecycle), který je složen z těchto kroků: 1. Analýza architektury (angl. Architecture analysis) – identifikace požadavků a priorit na základě současného a očekávaného stavu organizace. 2. Definice architektury (angl. Architecture definition) – návrh na úrovni konkrétních řešení (IT i byznys), která odpovídají identifikovaným prioritám. 3. Finanční plán (angl. Investment & funding strategy) – návrh realizačních a finančních plánů jednotlivých řešení. 4. Řízení programu (angl. Program management & execution) – vytvoření programového plánu a realizace jednotlivých projektů. Měření výkonnosti a zpětné vyhodnocení příspěvku k cílům organizace. Údržba architektury (není v obrázku zobrazena) – zpětná kontrola přínosů architektury, případná adaptace a sběr požadavků.

Obr. 2 – Proces rozvoje segmentové architektury (US Federal Government Office - 1, 2007) Pro úplnost uvádím architektonické vrstvy, které FEA rozlišuje:  Výkonnost (angl. Performance) – poskytuje soubor výkonnostních parametrů, které jsou sledovány v rámci státní správy, resp. v jednotlivých segmentech;  Byznysová (angl. Business) – funkční model popisující byznysové oblasti, linie a funkce, rozdělené na služby pro občany (hlavní část) a podpůrné funkce; SYSTÉMOVÁ INTEGRACE 4/2011

25

Martin Hladík

Datová (angl. Data) – standard pro formát, obsah a sdílení dat; Služeb (angl. Services) – servisní model odvozený od funkčního modelu, tvoří propojení mezi funkčními (byznysovými) částmi a IT;  Technologická (angl. Technology) – obsahuje standardy a vymezuje technologie, kterými lze realizovat služby. Rámec Pragmatic Enterprise Architecture (PEA) označuje vlastní přístup za řešení umístěné „mezi minimalistickými rámci, které nepokrývají veškeré potřeby, a rozsáhlými rámci, které je pro jejich mohutnost obtížné použít“ (Pragmatic EA Ltd - 1, 2010). Proces rozvoje dle PEA se skládá ze tří fází: 1. Příprava (angl. Prepare) – vytváří rámcové zadání (popisuje tzv. model současné a požadované vyspělosti), plán implementace, plán řízení rizik a rozpočet, v závěru získává souhlas s pokračováním prací; 2. Implementace (angl. Implement) – připravuje organizaci na použití podnikové architektury, zejména zajišťuje vzdělání dotčených lidí, nastavuje motivaci, nástroje (např. metamodel) a kontrolní mechanismy pro podnikovou architekturu; 3. Řízení (angl. Operate) – se zaměřuje na skutečné „provádění“ podnikové architektury; na základě strategického plánování a analýzy současného stavu identifikuje možnosti řešení; dále se věnuje nastavení kontrolních mechanismů nad realizací vybraných řešení.  

Obr. 3 – Proces rozvoje podnikové architektury (Pragmatic EA Ltd - 1, 2010) 26



PEA dále poskytuje podrobná schémata provádění jednotlivých kroků (viz příklad na obr. 4, který prezentuje obsah kroku Příprava, resp. jeho hlavní aktivity Získání souhlasu k aplikaci podnikové architektury).

Obr. 4 – Příklad detailního schéma (Pragmatic EA Ltd - 1, 2010) Bližší poznání PEA vyvolává dojem „prázdné schránky“. Na jedné straně obsahuje kompletní popis procesu, nicméně například chybí doporučení pro složité procesy (viz např. výše uvedený hierarchický průchod), rozlišení architektonických vrstev, specifikace výstupů atp. PEA však srovnává sama sebe s ostatními rámci poměrně ambiciózně – například vyčítá rámci TOGAF nedostatečnou orientaci na strategické plánování, organizaci jako celek (naopak se příliš soustředí na problematiku IT), kompletní pokrytí problematiky a použitelnost (Pragmatic EA Ltd - 2, 2010).

3. Srovnání přístupů k procesu rozvoje podnikové architektury Z výše uvedeného je patrné, že jednotlivé rámce podnikové architektury volí často poměrně rozdílné přístupy k definici procesu rozvoje. Pro srovnání procesů uváděných v rámcích TOGAF, FEA a PEA jsem se rozhodl analyzovat cíle dílčích kroků procesů a na tomto základě porovnání provést. Základ srovnání tvoří rámec TOGAF, který nabízí nejpodrobněji definované cíle (viz obr. 5 a 6). U rámce FEA jsem pro potřeby srovnání sloučil kroky Definice architektury a Finanční plán, neboť ostatní rámce tyto problematiky spojují, navíc i FEA vnímá tyto kroky jako úzce související (viz obr. 2). Výsledek analýzy srovnání jasně dokladuje podobnost procesů rámců TOGAF a FEA (např. „Vize architektury“ dle TOGAF odpovídá „Analýze architektury“ dle FEA atd.). FEA postrádá přípravný krok, což je dáno koncepcí analyzované segmentové architektury, která je součástí podnikové architektury zajišťující tyto přípravné práce. FEA nerozlišuje na úrovni procesu práce na jednotlivých architektonických vrstvách. Akcentuje však vrstvu výkonnostní (tu naopak postrádá TOGAF, hovoří pouze obecně


27

Martin Hladík

o vazbě na strategické cíle organizace) a samostatný krok „Finanční plán“, který odpovídá specifickému procesu řízení státní správy USA. I když FEA nepokrývá veškeré cíle uváděné v TOGAF, nepovažuji toto za významné a to s ohledem na často blízké definice jednotlivých cílů. Jak již bylo uvedeno výše, rámec FEA obsahuje také postupy pro řízení architektury na úrovni celé organizace (tedy podnikové architektury). V tomto kontextu zdůrazňuje tzv. přechodovou architekturu (angl. Transition architecture; podobně také TOGAF). Proces přechodové architektury na úrovni celé organizace je na první pohled jiný, obsahuje 6 kroků s odlišnými názvy: 0. krok: Stanovení výchozí a cílové architektury (a identifikace klíčových segmentů); 1. krok: Identifikace překryvů a rozdílů mezi výchozím a cílovým stavem; 2. krok: Zpřesnění a prioritizace architektonických segmentů; 3. krok: Návrh rámcového plánu; 4. krok: Vytvoření segmentových architektur (tedy zde uvažovaný proces FEA); 5. krok: Definice realizačních programů a projektů. Při bližším pohledu na cíle a obsah těchto kroků jsou však patrné shody s procesem na úrovni segmentové architektury (viz obr. 2). Rozdíly souvisejí především s detailem a šíří záběru, tedy se strategickým pohledem versus pohledem na část organizace, resp. její podnikovou architekturu (podrobněji viz kap. 4). Z pohledu procesu se rámec PEA liší od TOGAFu a FEA (viz obr. 5 a 6). Přípravný krok dle PEA je nutné vnímat jako relativně podrobné zmapování situace v organizaci s cílem získání rozhodnutí, zda má smysl investovat do podnikové architektury. Z tohoto důvodu se tento krok překrývá s prvními dvěma kroky dle TOGAF (nicméně i TOGAF doporučuje pro první iteraci propojení prvních dvou kroků – viz kap. 2). V samotném rámci PEA se však jedná o sekvenčně řazené samostatné kroky, které mají různé poslání. V této chvíli se však PEA nezabývá formálními náležitostmi podnikové architektury, jako například nastavením procesu, metod, výběrem nástrojů atp. Tento úkol je zajištěn následujícím krokem nazvaným „Implementace“. Prakticky celý další průběh procesu rozvoje podnikové architektury má v rukou krok „Řízení“. Z obr. 5 a 6 je patrné, že PEA se soustředí na požadavky, posouzení současného stavu a výběr vhodného řešení, nezabývá se však detaily návrhů a posouzení jednotlivých architektur. Pro realizaci změny poskytuje podobný servis, jako TOGAF či FEA (alespoň z pohledu procesu).

28


Zjednodušení procesu rozvoje podnikové architektury PEA Cíle

Fáze

Cíle

Fáze

Cíle

X X X

Implementace

X

X

X X X

Legenda:

X X X

X X X X

X X X

X

X

X

X

X

X

X X

X

Řízení

Posouzení podniku pro vypracování podnikové architektury Identifikace sponzorů podnikové architektury, zjištění jejich požadavků Ujištění, že spolupracující osoby podporují úspěch podnikové architektury Požádání sponzorů o vytvoření požadavků napříč dotčenými oblastmi podniku Vymezení částí organizace dotčených záměrem podnikové architektury, včetně omezení a předpokladů Výběr lidí odpovědných za realizaci podnikové architektury, stanovení jejich odpovědnosti Definice rámce a metod pro zavedení podnikové architektury (např. ADM), včetně kontrolních a podpůrných aktivit, výběru podpůrných nástrojů Stanovení architektonických principů formujících omezení pro vytváření podnikové architektury Ujištění, že zahajovaný cyklus rozvoje podnikové architektury má dostačné pochopení a podporu managementu Rozpracování plánu a organizace zahajovaného cyklu v plném rozsahu zadání Ověření podnikových cílů a principů podniku Definice rozsahu a priorit podnikové architektury Výběr sponzorů a zjištění jejich zájmu a plánů Stanovení klíčových byznysových požadavků a jejich omezení, které budou adresovány zahajovaným cyklem Sestavení architektonické vize a vymezení přínosů podnikové architektury vůči byznysovým požadavkům Vytvoření plánu, jehož součástí je harmonogram, financování, komunikace, rizika, omezení, předpoklady a souvislosti v souladu s používanou metodou projektového řízení Zajištění souhlasu s realizací

FEA Fáze

Příprava

Příprava Vize architektury

Cíle dle TOGAF

Analýza architektury

TOGAF Fáze

X

- rámec obsahuje stejný cíl jako Togaf

Obr. 5 – Srovnání procesů rozvoje podnikové architektury rámců TOGAF, FEA a PEA, 1. část (zdroj: autor)


29

Martin Hladík

Popis vychozí byznysové architektury Vytvoření cílové byznysové architektury, zejména definice produktů, dále organizačních, funkčních, procesních, informačních a geografických aspektů prostředí podniku, vycházející z byznysových principů, cílů a strategie Analýza rozdílů mezi výchozí a cílovou byznysovou architekturou Výběr a vytvoření relevantních pohledů na architekturu, které umožní demonstrovat sponzorům jejich potřeby Výběr nástrojů a technik pro vytvoření těchto pohledů Vytvoření cílové datové a aplikační architektury v doménách dle zadání projektu Identifikace data a aplikací, které podporují byzynsovou Vytvoření datové architektury Vytvoření aplikační architektury Identifikace technologických komponent (hardware, software) podporujících aplikační architekturu Definice současné a cílové technologické architektury Identifikace klíčových součástí umožňujících přechod ze současného do cílového stavu Posouzení byznysových cílů a možností, konsolidace rozdílů v byznysové architektuře, architektuře informačního systém a technologické architektuře, poté organizace stavebních bloků adresovaných k byznysovým cílům Posouzení podniku z důvodu schopnosti absorbovat změnu Odvození přechodných architektur pro postupnou realizaci změny a současně zajištění kontinuální hodnoty

FEA Fáze

Nastavení procesu řízení změny pro novou architekturu Maximalizace přínosů z architektury a souvisejících činností Zajištění kontrolního rámce Nastavení procesu pro identifikaci, uložení a komunikaci požadavků v průběhu celého procesu rozvoje

Cíle

Fáze

Cíle

X

X X X X X X X

X

X

X

Řízení programu

X X

Údržba architektury

Plánování realizace Kontrola realizace Řízení změny architektury Řízení požadavků

Zhodnocení změn rámce a principů přijatých v předchozí fázi

Fáze

X

Vytvoření a schválení hrubého plánu implementace a migrace Vytvoření detailního plánu implementace a migrace Ujištění, že plán je v souladu s používanými manažerskými metodami Prioritizace výstupů, projektů a stavebních bloků na základě analýzy nákladů a přínosů Dokončení architektonické vize a definice architektury v souladu se záměrem implementace Potvrzení přechodných architektur se sponzory Příprava zdrojů pro podporu implementace Definice doporučení pro každý implementační projekt Dohled nad aplikací architektonických standardů a procesů Provádění kontroly nad implementací, včetně shody s definovanou architekturou Mobilizace dodatečné podpory v případě problému Ujištění, že výchozí architektura vyhovuje Zhodnocení přínosů architektury a návrh zlepšení

PEA Cíle

Řízení - pokr.

Byznysová architektura Architektura Technologick informačního á architektura systému Možnosti a řešení

Cíle dle TOGAF

Definice architektury & Finanční plán

TOGAF Fáze

X

X

X X

X

X X X X

X X X X

X

X Legenda:

X

- rámec obsahuje stejný cíl jako Togaf

Obr. 6 – Srovnání procesů rozvoje podnikové architektury rámců TOGAF, FEA a PEA, 2. část (zdroj: autor)

30



4. Proces v kontextu života organizace Podniková architektura podporuje snadnější (ve smyslu rychlejší, s menším rizikem a nižšími náklady) provádění změn v organizaci (Hladík, 2011). Disciplína podnikové architektury se řadí mezi manažerské nástroje pro strategické řízení. Jaký je tedy ekosystém podnikové architektury, zejména pak v tomto textu zkoumaného procesu rozvoje podnikové architektury? TOGAF, FEA i PEA shodně prezentují podnikovou architekturu jako partnera pro strategické plánování (viz obr. 7). Strategické plánování organizace stanovuje základní směr pro podnikovou architekturu (strategie), současně však podniková architektura umožňuje lépe posoudit dopady strategických rozhodnutí. Na operativní úrovni poskytuje podniková architektura standardy, pravidla a vzory pro realizaci nových řešení a to v celém životním cyklu projektů. Stejně tak zajišťuje kontrolu dodržování těchto standardů a pravidel. Podobnou vazbu má podniková architektura na provoz, jak ve smyslu podílení se na vytváření podmínek provozu, tak ve smyslu získání zpětné vazby. Domnívám se, že nepochopení přínosů podnikové architektury ze strany vrcholového managementu vede k izolovanému rozvoji podnikové architektury (často ze strany oddělení IT) a díky tomu nenaplnění potencionálních přínosů této disciplíny.

Obr. 7 – Návaznost podnikové architektury na další manažerské disciplíny (The Open Group, 2009) Hierarchické složení procesů, resp. více úrovní architektury (např. podniková/strategická, segmentová, doménová) je další rozměr úvahy o integraci podnikové architektury do prostředí organizace. Potřeba konkrétní úrovně souvisí se složitostí organizace a řešeným problémem (US Federal Government Office - 1, 2007). Základní pohled na hierarchii procesů na jednotlivých úrovních záběru podnikové architektury uvádí např. US Federal Government Office - 1, 2007 (viz obr. 8). Jednotlivé úrovně se liší šíří záběru i detailem zpracování.


31

Martin Hladík

Obr. 8 – Hierarchie úrovní architektury (US Federal Government Office - 1, 2007)

5. Návrh zjednodušení procesu rozvoje podnikové architektury Podstatou této části textu je návrh zjednodušeného procesu rozvoje podnikové architektury, který lze využít pro snadnější pochopení rámců, pochopení souvislostí mezi jednotlivými rámci či použití v méně složitém prostředí (např. malých a středních podniků). Je však třeba si uvědomit, že v praktickém použití je nezbytné pracovat s rámci jako celky, proto je tento článek pouze dílčím zkoumáním a případnou inspirací pro komplexní práci. Na základě analýzy v kap. 3 a souvisejícího studia zde uvedených rámců navrhuji následující členění procesu rozvoje podnikové architektury, které dle mého názoru lze snadno mapovat na milníky s jasně definovanými cíli a rozhodovacími body (pokračovat / nepokračovat): 1. Záměr – pochopení potřeb a stavu organizace, formulace cíle, návrh postupu a řešení, odhad rozpočtu, získání souhlasu s rozpracováním záměru (tzn. vytvoření Návrhu řešení); 2. Návrh řešení – podrobné poznání potřeb, současného stavu, identifikace možných řešení, výběr optimálního řešení, rozpracování rozpočtu, návrh realizačního plánu, získání souhlasu s realizací; 3. Podpora realizace – podpora realizace řešení, průběžná kontrola, případně pomoc při nápravě nedostatků; 4. Vyhodnocení – analýza průběhu realizace, zhodnocení příspěvku podnikové architektury, zajištění případných změn. Výše navržený proces odpovídá rámcům TOGAF a FEA (viz obr. 9), vyjma rozličného vnímání přípravy realizace. TOGAF i FEA považují tento krok za součást realizace, já jsem však názoru, že patří do návrhu řešení (mimochodem základní realizační plán vzniká dle TOGAF již v rámci kroku Příležitosti a řešení.

32



TOGAF

Vize architektury

Příprava

Byznysová architektura

Analýza architektury

FEA

Architektura informačního systému

Technologická architektura

Možnosti a řešení

Plánování realizace

Definice architektury & Finanční plán

Kontrola realizace

Řízení programu

Řízení změn architektury

Řízení požadavků

Údržba architektury

Příprava

PEA Řízení

Implementace

Vlastní návrh

Záměr

Návrh řešení

Podpora realizace

Vyhodnocení

Obr. 9 – Návrh zjednodušeného procesu rozvoje podnikové architektury Většina rámců (v tomto textu TOGAF a FEA) rozlišují tzv. úrovně architektury, podrobněji rozebrané v kap. 4. Ze stejného důvodu doporučuji sledovat i v kontextu zjednodušeného procesu dvě úrovně. První – strategická – úroveň slouží pro nastavení hlavní cesty rozvoje podnikové architektury (dle členění FEA se jedná o Enterprise architecture, viz obr. 8). Předpokládám, že tato úroveň je klíčová při prvotní aplikaci podnikové architektury jako disciplíny v organizaci, nebo při zásadních změnách, například fúze organizací nebo zásadní změna byznysového modelu. Druhá úroveň v předložené úvaze podporuje organizaci při taktickém a operativním řízení (dle členění FEA se jedná o Solution architecture, viz obr. 8; mezivrstvu – Segment architecture – v tomto konceptu neuvažuji). Konkrétně se jedná o realizaci projektů (podpora při návrhu řešení, architektonický dozor při realizaci atp.), případně o řešení provozních záležitostí (analýza provozní výkonnosti, řešení provozních problémů atp.). Výše uvedené lze vyjádřit následující tabulkou (viz tab. 1). Tab. 1 – Generický proces rozvoje podnikové architektury na strategické a taktické/operativní úrovni řízení (zdroj: autor) Strategické řízení Taktické a operativní řízení Příklady úloh:

Fúze Změna obchodního modelu

Projekty Provozní problémy

Pochopení změny organizace Formulace cíle Návrh řešení a postupu Odhad dopadů Získání souhlasu Podrobná analýza změny Identifikace řešení Výběr vhodného řešení Rozpracování rozpočtu Návrh realizačního plánu Získání souhlasu

Pochopení požadavků na projekt, formulace zadání Návrh řešení a postupu Odhad rozpočtu Získání souhlasu

Krok zjednodušeného procesu 1. Záměr

2. Návrh řešení


Podrobná analýza požadavků Návrh řešení (obvykle není třeba uvažovat varianty) Rozpracování rozpočtu Návrh realizačního plánu Získání souhlasu

33

Martin Hladík

Krok zjednodušeného procesu

Strategické řízení

Taktické a operativní řízení

3. Podpora realizace

Podpora při realizaci Průběžná kontrola realizace Případné řešení problému

Podpora při realizaci Architektonický dozor Případné řešení problémů

Analýza průběhu realizace Zhodnocení příspěvku Zajištění případných změn

Analýza průběhu realizace Zhodnocení příspěvku Zajištění případných změn

4. Vyhodnocení

Jednotlivé činnosti se liší především rozsahem záběru (realizační plán fúze versus realizační plán implementace nového IT řešení) a detailem pohledu (kontrola realizace při fúzi versus architektonický dozor při implementaci IT řešení).

6. Závěr Páteří rámců podnikové architektury je rozvojový proces. Přestože v jednotlivých rámcích, v tomto textu zkoumané TOGAF, FEA a PEA, mají řadu společných znaků (kontinualita, inkrementálnost, iterativnost), ve svém obsahu a členění se značně liší. Domnívám se, že přílišná složitost procesu znesnadňuje uživateli praktické použití rámce. Vedle složitosti má jistě vliv na použitelnost i angličtina, ve které jsou rámce publikovány. Pro malé a střední organizace je charakteristické omezení zdrojů, lze se tedy domnívat, že obvykle nedisponují specialisty na podnikovou architekturu. Z tohoto důvodu považuji za podstatný znak rámce použitelnost. Přestože tento text nemůže svým rozsahem nabídnout adekvátní řešení, poskytuje alespoň porovnání tří často využívaných rámců a návrh na zjednodušení procesu rozvoje podnikové architektury. Dle mého soudu je TOGAF vhodný pro velké organizace, které mají k dispozici zkušené specialisty. FEA, byť je určená pro vládní organizace USA, může být adaptována i do komerčních organizací. Bez zkušeného specialisty však může být i její použití problémové. PEA je pragmatická, ale spíše ve významu „zabývejme se tím, co souvisí se strategií, pracujme výhradně na základě souhlasu sponzorů“, nikoliv v nabídce triviálního postupu. Obávám se tak, že žádný ze zkoumaných rámců nenabízí řešení pro malé a střední organizace. Ani řada dalších autorovi dostupných publikací zaměřených na srovnání rámců podnikové architektury, (např. Schekkerman, 2003; Urbaczewski, 2006) nepřinesla významně podrobnější srovnání obsahu (principů, metod, nástrojů, vzorů atp.) těchto rámců. Vždy šlo jen o manažerské hodnocení podobného typu jako výše uváděné srovnání od tvůrce PEA. Naopak jiné tituly věnující se praktickým doporučením často zavádějí další vlastní přístupy (např. van den Berg, 2006). S ohledem na nedostatečné zkušenosti s výběrem vhodného rámce i aplikací podnikové architektury v praxi organizací, alespoň posuzuji-li situaci na základě mých znalostí, je nezbytné tato srovnání a návody poskytnout. Stejně tak vnímám absenci jednoduchého rámce, který by mohly využít malé a střední organizace.

34



Poděkování Tento článek vznikl za podpory grantu GAČR P 403-10-0303 (Enterprise Architecture jako princip v řízení malých a středních organizací).

Literatura CARDWELL, G.: The Influence of Enterprise Architecture and Process Hierarchies on Company Success. Elektronický časopis Business Process Trends. Newton, Business Process Trends Associates, [online], 2007. http://www.bptrends.com JACOBS, D., KOTZÉ, P., VAN DER MERWE, A., GERBER, A.: Enterprise Architecture for Small and Medium Enterprise Growth. In. Sborník konference 13 th Enterprise Information Systems. Beijing, ICEIS, 2011. ISBN: 978-3-642-21058. HLADÍK, M.: Předpoklady úspěšné implementace podnikové architektury. Časopis Systémová integrace. Praha, ČSSI, 2011, č. 2. ISSN: 1214-6242. LANKHORST, M.: Enterprise Architecture at Work: Modelling, Communication and Analysis. Dordrecht, Springer, 2009. ISBN: 3642013090. PEREIRA, C., SOUSA, P.: A Method to Define an Enterprise Architecture using the Zachman Framework. In. Sborník konference ACM Symposium on Applied Computing. New York, Association for Computing Machinery, 2004. PRAGMATIC EA LTD - 1: Pragmatic Enterprise Architecture Framework: Overview. Verze 2.0. Essex, [online], 2010. http://www.pragmaticea.com/docs/peaf-overview2-pragmatic.pdf PRAGMATIC EA LTD - 2: Pragmatic Enterprise Architecture Framework: Framework Comparison. Verze 2.0.1. Essex, [online], 2010. http://www.pragmaticea.com/docs/peaf-overview1-framework-comparison.pdf SCHEKKERMAN, J.: How to survive in the jungle of enterprise architecture frameworks. Oxford, Trafford Publishing, 2003. ISBN: 141201607X. The Open Group: TOGAF Version 9. Reading, 2009. ISBN:978-90-8753-230-7. https://www2.opengroup.org/ogsys/jsp/publications/mainPage.jsp URBACZEWSKI, L., MRDALJ, S.: A comparison of enterprise architecture frameworks. Článek v periodiku Issues in Information Systems. Stillwater, International Association for Computer Information Systems, 2006. ISSN: 1529-7314. US FEDERAL GOVERNMENT OFFICE - 1: FEA Practice Guide „Value to the Mission“. Washington, [online], 2007. http://www.whitehouse.gov/sites/default/files/omb/assets/fea_docs/FEA_Practice_ Guidance_Nov_2007.pdf US FEDERAL GOVERNMENT OFFICE - 2: FEA Consolitated Reference Model Document, Version 2.3. Washington, [online], 2007. http://www.whitehouse.gov/sites/default/files/omb/assets/fea_docs/FEA_CRM_v23 _Final_Oct_2007_Revised.pdf VAN DEN BERG, M., VAN STEENBERGEN, M.: Building an enterprise architecture practice. Dordrecht, Springer, 2006. ISBN: 1402056052.


35

Martin Hladík

WINTER, R., FISCHER, R.: Essential Layers, Artifacts, and Dependencies of Enterprise Architecture. In. Sborník konference 10th IEEE International Enterprise Distributed Object Computing. Hong Kong, IEEE, 2006. ISBN: 0-7695-2743-4.

36


Zjednodušení procesu rozvoje podnikové architektury

Recommend Documents