Prověřování podnikové architektury

Prověřování podnikové architektury Libor Gála Katedra informačních technologií Vysoká škola ekonomická Praha [email protected]

Abstrakt: Podniková architektura (Enterprise Architecture, EA) získává jako prostředek udržení souladu byznysu a IT stále větší význam. Protože může významně ovlivnit jak podnik samotný, tak také úroveň podpory informačními technologiemi, je důležité, aby v oblasti governance byly zavedeny vhodné mechanismy jejího prověřování. Příspěvek hledá v oblasti EA možné objekty prověření, charakterizuje vhodná hodnotící kritéria, cíle a také přístupy uplatňované při prověřování. Klíčová slova: Enterprise architecture, EA, podniková architektura, governance, kontrola, audit, ujištění Abstract. From point of view of aligning business with IT, Enterprise Architecture (EA) is becoming increasingly important. EA is significantly influencing both the enterprise itself, as well as the level its support by information technology. Therefore is very important to put appropriate screening into IT governance mechanisms. Article looks at the objects in EA to be checked and brings goals, appropriate evaluation criteria and approaches for their screening. Key words: Enterprise Architecture, IT governance, audit. assurance.

1. Úvod V současném vysoce konkurenčním prostředí představují informační technologie (IT) významný faktor, který ovlivňuje úspěšnost organizací. Komplexita byznysu, informačního systému a IT i jejich vzájemných vztahů vyvolává potřebu zavedení vhodného prostředku, kterým by bylo možné tuto složitost zachytit, komunikovat a řídit a kterým bychom byli schopni podpořit dosažení souladu mezi byznysem a IT nyní i v budoucnosti. V oblasti IT se již řadu let používá architektura, kterou na různých úrovních formulujeme klíčové charakteristiky IT a informačních systémů tak, aby vyhovovaly potřebám byznysu. Nevyváženost jejího užití v prostředí podniku, ale také její přínosy v zajištění flexibility IT vedly k myšlence přenosu architektonických principů i do oblasti byznysu a posléze i do celého podniku (Malveau, 2004). Tím se těžiště architektury soustřeďuje do podpory sladění byznysu a IT. Architektura pak je architekturou podniku jakožto systému a pro její označení se používá pojem Enterprise Architecture (EA). Analýzy Langenbergové a Wegmana (2004) a také Schöenherra (2008) ukazují, že se koncept nejen na úrovni vládních institucí, ale také v akademické a podnikatelské sféře „ujal“ a realizované průzkumy poukazují na to, že „se na podnikové úrovni jedná o koncept již dostatečně zralý“ (Aziz, et al., 2007), že „se stále zvyšuje role konceptu v oblasti strategických rozhodnutí o transformaci podnikání včetně reakce na výzvy a změny podnikatelského prostředí“ (Obitz, et al., 2009) a také, že „jeho implementace může zlepšit i celkovou výkonnost organizace“ (Kamogawa, a další, 2009). Problematický, i když v zásadě již zřetelný progres v této oblasti je identifikován i v ČR (Sládek, 2010).

SYSTÉMOVÁ INTEGRACE 2/2010

53

Libor Gála

Z uvedeného vyplývá, že EA formuluje transformací strategických záměrů zásadní aspekty fungování byznysu i IT. Proto je důležité, aby její zavedení bylo doplněno i o vhodné prvky její kontroly, kterými lze objektivně (pr)ověřit (přezkoumat), zda EA je ve shodě se stavem skutečným (či žádoucím). Cílem příspěvku je identifikovat v oblasti EA možné objekty prověřování a charakterizovat u nich hodnotící kritéria, cíle a také přístupy uplatňované při prověřování.

2. Prověřování Prověřování lze realizovat jako kontrolu nebo audit. Kontrolou (Control) rozumíme takovou aktivitu, ve které prověřujeme, zda objekt dosahuje předem stanovené hodnoty. Auditem potom rozumíme „objektivní ověření stavu, jevu, záměru, skutečnosti se stavem nebo jevem žádoucím, tj. modelem, normou, standardem 1 apod.“ (Svatá, 2005), jinak řečeno jedná se o „způsob , kterým je jedna osoba ujištěna druhou o kvalitě, podmínkách nebo stavu předmětné věci2, kterou druhá osoba zkoumala. Potřeba takového auditu vzniká, protože první osoba má pochybnosti nebo si není jista kvalitou, podmínkami nebo stavem předmětné věci a 3 sama není schopna se těchto pochybností či nejistoty zbavit.“ Základem je finanční audit jakožto systematický proces objektivního získávání a vyhodnocování důkazů, týkajících se informací o ekonomických činnostech a událostech, s cílem zjistit míru souladu mezi těmito informacemi a stanovenými kritérii a oznámit výsledky zainteresovaným stranám.“ (Ricchiute, 1994). V současné době se koncept auditu přenesl i do dalších oblastí v podniku. Jedná se o prověřování souladu objektu se standardy, tzv. vyhovění (compliance) a o prověřování, zda objekt je schopen naplnit formulované cíle. Pak se lze setkat s pojmy jako audit souladu, operační nebo provozní audit (Svatá, 2010). Domnívám se, že audit souladu odpovídá svým charakterem finančnímu auditu s tím, že se orientuje na ověřování souladu s jinými standardy, než jsou standardy v oblasti finanční. U operačního a provozního auditu, který se zaměřuje na ověření, že objekt je schopen naplnit cíle je podle mého názoru vhodnější použití pojmu ujištění, záruka (Assurance). Ujištění pak zahrnuje samozřejmě audit finanční nebo souladu) s tím, že zahrnuje také ujištění, že objekt tak, jak je či se bude rozvíjet, je schopen naplnit formulované cíle. Vyplývá to z toho, že i kladný výsledek auditu souladu nemusí znamenat, že objekt splňuje nebo splní cíle zadavatele. U jednotlivých druhů prověření lze identifikovat společné atributy. Jedná se o cíle prověření, objekt prověření, hodnotící kritéria, metody prověření a typ realizace. Cíl prověření formuluje, zda se bude jednat o kontrolu, audit nebo ujištění. Objekt prověření může být ze své podstaty hmotným nebo nehmotným objektem. Hmotným objektem může být třeba nějaké zboží. Nehmotný objekt může mít 1

Tentýž pojem je používán i pro označení výsledku této aktivity, tj. „zpráva vydaná o auditu“ (Kraus, 2009) 2 V definicích se používá objekt nebo předmět auditu. V dalších částech práce bude vždy použit pojem objekt. 3 Definice T. A. Leea převzata z dokumentu Komory auditorů ČR (Komora auditorů ČR, 2007) 54


Prověřování podnikové architektury

charakter díla (např. software, metoda apod.) nebo aktivity (např. činnost, proces apod.), přičemž obojí může být buďto modelem nebo reálným objektem. Hodnotící kritérium představuje konkrétní aspekt, který vystupuje jako vztažný (referenční) objekt, vůči kterému bude objekt prověřován. Tvoří ho de-jure a de-facto standardy anebo předem definovaná hodnota či stav (např. podnikatelský cíl). Metoda prověřování představuje vhodnou posloupnost kroků (etap, fází) s definovanými aktivitami. Tabulka 1 sumarizuje postupy u různých typů auditu a ujištění. Přestože se u jednotlivých autorů postup liší v použitém názvosloví, pak z obecného procesního hlediska se postup v zásadě neliší od průběhu projektu, který typicky zahrnuje následující skupiny procesů – „zahájení, plánování, provedení, sledování a kontrola, ukončení“ (Chlapek, 2008). Fáze zahájení je inicializována prověřovaným, tj. jeho požadavkem, ať již vychází ze zákonných požadavků nebo ne. Fáze sledování a kontrola je zajišťována systémem kontroly kvality 4 Z hlediska svého řízení může mít prověřování charakter prověřování . samostatného projektu anebo může být součástí (fází, etapou) projektu jiného (např. součástí projektu ujištění). Obsah fází plánování (respektive aktivity spojené se stanovením programu prověřování) a provedení velmi úzce souvisí s objektem auditu, tj. jeho přesným vymezením. Tabulka 1 Přehled fází (etap) u různých typů auditu a ujištění Finanční audit (Boynton, a další, 2005)

Postup auditu dle KAČR a PHARE (Müllerová, 2007)

Audit operací (Dvořáček, 2005)

Interní audit (Dvořáček, a další, 2005)

IT ujištění (IT Governance Institute, 2007)

1 Perform risk assessment procedures 2 Assess the risk of material misstatement 3 Respond to assessed risk 4 Perform further audit procedures 5 Evaluate audit evidence 6 Communicate audit findings

1 Činnosti před uzavřením smlouvy 2 Předběžné plánovací procedury 3 Vytvoření plánu auditu 4 Provedení auditu 5 Závěr s vydání zpráv

1 Porozumění auditovanému objektu 2 Stanovení cíle auditu 3 Určení požadovaného důkazního materiálu 4 Shromáždění a analýza auditorských dokladů 5 Vytvoření zjištění a závěry auditu 6 Vypracování auditorské zprávy 7 Postaudit – ověřování

1 Plánování interního auditu 2 Provádění interního auditu 3 Předávání výsledků interního auditu 4 Monitorování 5 Hodnocení interního auditu

1 Plánování 2 Stanovení rozsahu 3 Provedení

Prověřování může být realizováno interně nebo externě, přičemž by vždy měl být dodržen princip nezávislosti mezi tím, kdo prověřování žádá a tím, kdo prověřování realizuje. 4

Např. u povinných auditů principy v této oblasti definuje §24 Zákona 93/2009


55

Libor Gála

Zatímco kontrola je běžnou aktivitou managementu, pak audit a ujištění patří do systému „správy a řízení“, tzv. Governance, jehož klíčové principy byly formulovány OECD v rámci konceptu Corporate Governance v roce 1999 (revize v roce 2004). Vedle pojmu Corporate Governance, kde „Corporate“ je ve významu korporace jako „formy organizace ekonomické aktivity“ (OECD, 2004), se lze setkat s řadou dalších orientací. V oblasti podniku (Enterprise) se jedná o tzv. Enterprise Governance5 reprezentující „the set of responsibilities and practices exercised by the board and executive management with the goal of providing strategic direction, ensuring that objectives are achieved, ascertaining that risks are managed appropriately and verifying that the organisation’s resources are used responsibly6.“ (IFAC, 2004). Vztah mezi Corporate Governance, Enterprise Governance, finančním auditem, auditem shody (conformance), operačním auditem - ujištěním (performance) a kontrolou znázorňuje následující obrázek (viz Obrázek 1).

Obrázek 1 Corporate Governance, Enterprise Governance a Audit (Hamaker, 2005) Zvětšující se role informačních technologií, kterými podporujeme stále větší část podnikového informačního systému (tj. i část neformálního a formálního IS (Gála, a další, 2009)), vyvolává potřebu se informačním technologiím věnovat i v rámci 5

oblast zaštiťuje IFAC (International Federation of Accountants), která definici pojmu přebírá od ISACF (Information Systems Audit and Control Foundation), jenž se v roce 2003 přejmenovala na ITGI (IT Governance Institute) (ISACA, 2003) 6 V češtině „množina odpovědností a postupů prováděných představenstvem a exekutivou s cílem realizovat strategické cíle, omezit rizika a zajistit, že podnikové zdroje se využívají efektivně“ (Svatá, 2005) 56



„správy a řízení“. Proto vzniká IT Governance, zpřesňující postupy podnikové správy a řízení s ohledem na specifika IT v pěti klíčových oblastech – strategický soulad, tvorba hodnoty, řízení rizik, řízení zdrojů a měření výkonnosti a pro jejíž budování a rozvoj se používá procesně orientovaný nástroj - COBIT (Novák, 2010). S novými iniciativami v oblasti IT, jako např. se zaváděním servisně-orientovaného přístupu, který je reprezentován SOA (Service-Oriented Architecture) je možné se setkat i s dalšími úrovněmi IT Governance. Třeba právě v souvislosti se SOA se jedná o SOA Governance, kterou lze chápat jako podmnožinu IT Governance. Každá taková úroveň správy a řízení je pak součástí úrovně vyšší, kterou v příslušné zájmové doméně zpřesňuje, tj. SOA Governance je součástí IT Governance a IT Governance je součástí Enterprise Governance.

3. Podniková architektura Enterprise7 Architecture má své základy v IT oblasti a je založena na principech definovaných Zachmanem (1987) a Spewakem (1993). Ty spolu dalšími principy, které formuloval Národní institut pro standardy a technologie (NIST) a Úřad pro řízení a rozpočet (OMB) se staly základem prvního rámce EA – FEAF (Federal Enterprise Architecture Framework). Posléze byla zákonem 104-106-FEB. 10, 19968 na CIO v americké administrativě přenesena povinnost ji v platné podobě udržovat. Pro její podporu vznikla i norma IEEE-std1471-2000 (Recomended Practice for Architectural Description of Software-Intensive Systems)9. Ve své podstatě se však stále jednalo o spíše IT architekturu než architekturu podniku. Postupem času došlo v posunu v pojetí (viz Obrázek 2) a EA nyní vytváří holistický pohled na podnik jakožto systém (Schekkerman, 2004).

7

Pojmem Enterprise vyjadřujeme „any collection of organisations that has a common set of goals/principles and/or single bottom line“ (Schekkerman, 2004); podobně také TOGAF 9 (The Open Group Architecture Forum, 2009). Do češtiny se pojem v tomto kontextu překládá slovem „podnik“, i když zde existuje možné úskalí v interpretaci, tzn. podnik, jakožto jeden z typů ekonomické/právní subjektivity versus podnik, jakožto jakýkoliv subjekt vyhovující definici (firma, ministerstvo, obec, virtuální společnost – dodavatelský řetězec apod.) 8 Jeho pátá část (sekce) – „Information Technology Management Reform Act of 1996“ je známa také pod označením Clinger-Cohen Act. 9 Norma byla později přijata ISO pod číslem ISO/IEC 42010:2007. Systems and software engineering -- Recommended practice for architectural description of software-intensive systems SYSTÉMOVÁ INTEGRACE 2/2010

57

Libor Gála

EA = Technology Architecture (TA)

EA = Enterprise‐Wide IT Architecture (EWITA)

EA = EWITA + Business Architecture (BA)

Reduce IT complexity and costs: • Increased convergence consolidates purchasing, lowers training costs, and increases employee mobility in the organization

Support collaboration among different parts of the enterprise: • Shared access to information across the business and, increasingly, from outside the business by customers, • partners, suppliers, even competitors • More effective portfolio management • Elimination of duplication in similar applications for different business functions or different business units • Address concerns that cut across business units such as integration, interoperability, and security

Increase enterprise agility and alignment with business strategy: • Enable changes in business strategy with quick‐response changes in enabling processes and technology solutions • Inform strategy more effectively because there is a strategic path for identifying and integrating technology‐enabled opportunities (and threats)

Obrázek 2 Rozvoj obsahu a hodnoty EA (Bredemeyer, a další, 2004) 10 V dalším budeme podnikovou architekturu chápat v jejím posledním evolučním stupni a v následujícím obsahu tj. jako „přístup, koncept, prostředek a nástroj, kterým vyjadřujeme fundamentální upořádání vztahu mezi byznysem a jeho informačním systémem, které vede k naplnění mise organizace, přičemž respektuje okolní prostředí a konzistentně dodržuje formulované principy návrhu a rozvoje systému“ (Buchalcevová, a další, 2008). Definice je založena na: 11  Standardu ISO/IEC 42010:2007 kde architekturou systému je rozuměno „The fundamental organization of a system embodied in its components, their relationships to each other, and to the environment, and the principles guiding its design and evolution.“.  Formulaci Rossové, Weilla a Robertsona, dle kterých „EA is the organizing logic for business processes and IT infrastructure, reflecting the integration and standardization requirements of the company’s operating model. The enterprise architecture provides a long-term view of company’s processes, systems, and technologies so that individual projects can build capabilities – not just fulfill immediate needs“ (Ross, a další, 2006).  Definici Lankhorsta, kde „EA: a coherent whole of principles, methods, and models that are used in the design and realisation of an enterprise’s 10

V českém prostředí je pojem podniková architektura překladem termínu Enterprirse Architecture. 11 Případně dle normy IEEE-std-1471-2000 58



organisational structure, business processes, information systems, and infrastructure.“ (Lankhorst, et al., 2005). Z definic lze vyvodit několik tvrzení, které jsou významné pro stanovení objektu auditu, kritérií a metod hodnocení. Systém (v tomto případě podnik) „je vždy v nějaké architektuře“ (ISO/IEC, 2007). Jestliže architektura objektivně existuje, pak jakožto objekt reality má formulovány „identitu, existenci a vlastnosti, přináležitost (objektovou a mentální) a také lokalizaci (v prostoru, čase, kvantitě, korelaci a procesech)“ (Grepl, a další, 1998). Popis architektury představuje homomorfní model, kterým jsme schopni realitu, v případě podnikové architektury podnik, řídit a ovlivňovat nebo také ne. Lankhorst (2005) v této souvislosti „upozorňuje, že její význam se projeví v plánování a řízení rozvoje IT v souladu s potřebami byznysu pouze, pokud je organizace měřeno zralostním modelem COBITu ve třetí úrovni, tj. je formalizovaná (Defined)“. Architektura je vyjádřena (popsána) stavem (současným a budoucím|cílovým) a zahrnuje také:  proces svého návrhu a rozvoje (včetně formulových principů) a  tzv. transformační plány. Ty stanovují způsob přechodu do cílového stavu s respektováním: - externích vlivů i interních faktorů (byznys strategie, IT strategie, organizační infrastruktura a procesy, IT infrastruktura a procesy), - zvolené metody konstituce vztahu mezi faktory (dvou a třícestné spojení (Henderson, a další, 1993) nebo smyčka (Kochan, et al., 1992)) a případně - zvoleného typu operačního modelu (Ross, a další, 2006), kterým formulujeme míru standardizace podnikových procesů a úroveň integrace procesů s IT. Lankhorst (2005) to vyjadřuje tak, že „architektura je produkt i proces“. Produkt představují modely a plány a procesem je myšleno, že architektura je cestou ke sladění byznysu a IT . Podniková architektura nepřináleží pouze disciplíně řízení IT, neboť vliv byznysu je zcela zásadní a byznys je součástí architektury a ne okolím. Klíčové pohledy vyjadřující zájmy zainteresovaných stran tvoří byznys pohled, informační pohled, 12 aplikační pohled a technologický pohled (Buchalcevová, a další, 2008) . Podnikovou architekturu lze také přirovnat k lepidlu, kterým spojujeme svět byznysu a IT na strategické i taktické úrovni s cílem podpořit jejich sladění (viz Obrázek 3).

12 Jedná se o klíčové pohledy, které však v různých metodikách (architektonických rámcích) mohou být seskupeny do různých celků. Například TOGAF 9 seskupuje informační a aplikační pohled do pohledu, který označuje jako informační systém (The Open Group Architecture Forum, 2009).


59

Libor Gála

Interní faktory Externí vlivy (taktika) (strategická úroveň)

Byznys

IT

Byznys strategie

IT strategie Podniková architektura

Organizační infrastruktura a procesy

Operační model

IT infrastruktura a procesy

Obrázek 3 EA jako lepidlo [modifikace Henderson (Henderson, a další, 1993), Ross (Ross, a další, 2006) a Vašíček (Vašíček, 2010)] Jaké informace (co), kdy a proč se jimi zabývat, kdo a kde je potřebuje a v jakém kontextu, vyžaduje, abychom disponovali vhodnou metodikou. Již od formulace „pouhé“ IT architektury se k tomuto účelu využívají architektonické rámce (EA rámec). Ty se postupně v oblasti podnikové architektury rozvinuly do v zásadě tří základních typů. Jedná se o klasifikační, procesní a obsahové rámce (Buchalcevová, a další, 2008), přičemž skutečně užitý EA rámec v konkrétním podniku je často kombinací několika rámců různých typů. Čili podnik si jejich kombinací vytváří vlastní EA rámec, případně jeden z rámců si kastomizuje pro své potřeby (Obitz, et al., 2009). Rámec zároveň formuluje postup – EA management a mechanismy správy a řízení – EA Governance. Adopce rámce nebo jejich kombinace vede k tomu, že je nutné již z důvodu rozsahu, který rámec pokrývá, nasadit vhodný EA IT nástroj. Ten by měl podle Leistové a Zelnera (2006) zajistit a podpořit:  množinu modelů a modelovacích technik, které jsou nezbytné pro zachycení architektury z různých pohledů,  konzistenci všech pohledů společným metamodelem včetně možnosti užít a shodně interpretovat modely různými zainteresovanými stranami (v souladu se standardem ISO/IEC 42010:2007),  vhodnou proceduru, která bude uplatňována při vývoji a rozvoji architektury.

4. Cíl a kritéria prověřování podnikové architektury V předchozí kapitole uvedená charakteristika EA vytváří prostor pro identifikaci klíčových objektů EA a podstatných objektů okolí EA, které ji ovlivňují anebo jsou EA ovlivňovány (viz Obrázek 4).

60



Governance

EA Governance EA Management

Management EA model Strategie EA rámec Podnik EA IT podpora

Obrázek 4 Klíčové objekty EA a podstatné objekty okolí Je zřejmé, že za objekt prověřování může být považován celek anebo jeho dílčí části. V případě celku bude EA chápána jako podnikový program. V rámci dílčích částí budou předmětem analýzy EA model, EA procedura a EA IT podpora. EA procedura je tvořena EA rámcem, EA Governance a EA Managementem. K prvkům okolí patří Governace, management, strategie a aktuální stav podniku. Governance i management zahrnují vždy dvě složky – podnikovou a IT. V rámci podnikového managementu je nutné uvažovat jako podstatné i strategii dosažení souladu byznysu a IT, respektive zvolené a uplatňované metody vedoucí k dosažení souladu a také zvolenou strategii operačního modelu. Pro jednotlivé objekty budou formulovány dva klíčové atributy a to cíl prověřování a hodnotící kritérium.

4.1 EA jako podnikový program Pokud uvažujeme EA jako podnikový program, pak je potřeba rozlišit, zda je program zákonem nařízen (např. již zmíněný Clinger-Cohen Act) nebo ne. V případě, že se na organizaci vztahuje zákon o povinnosti program provádět, pak v oblasti prověřování programu postupujeme podle metodických doporučení, které zákon doprovázejí. Cílem prověřování je stanovení úrovně vyhovění programu zákonným požadavkům a ujištění, zda program je ve shodě se stanovenými cíli. K významným rámcům a metodikám, o které se v tomto případě opíráme a které formulují i kritéria hodnocení a jejich možné hodnoty, patří:  U.S. Office of Management and Budget - Enterprise Architecture Assessment Framework (EA2F) – rámec umožňuje hodnotit podnikovou architekturu ve třech klíčových schopnostech – kompletnost, použití a výsledky a u každé schopnosti rámec formuluje klíčové indikátory výkonnosti a definuje stupnici zralosti založenou na CMMI (Office of Management and Budget, 2007).  National Associations of State Chief Information Officers Enterprise Architecture Maturity Model (EAMM). Metodikou (NASCIO, 2003) hodnotíme zralost EA programu ve stupnici zralosti dle CMM v osmi oblastech (správa, plánování, rámec, standardy, komunikace, vyhovění, integrace a spoluodpovědnost). SYSTÉMOVÁ INTEGRACE 2/2010

61

Libor Gála

U.S. Department of Commerce Architecture Capability Maturity Model Framework (ACMMF), v rámci kterého je formulováno šest úrovní zralosti a hodnoceno 9 architektonických elementů (architektonický proces, rozvoj architektury, provázanost s byznysem, spoluúčast vrcholového vedení, zapojení provozních jednotek, komunikace, IT bezpečnost, architektonická Governance a strategie IT investic a akvizicí).  U.S. Governance Accountability Office EA Management Maturity Framework (EAMMF) je součástí rámce „A Framework for Assessing and Improving Enterprise Architecture Management“ (GAO, 2002) a orientuje se na stanovení úrovně zralosti procesu managementu EA pomocí 31 klíčových elementů managementu přiřazených k jednomu ze čtyř atributů managementu, které jsou kritické pro dosažení úspěchu, a zároveň rozprostřených do 5 zralostních stupňů. Pro celkové hodnocení EA programu je ale dle mého názoru nutná kombinace rámce EA2F s některým se zbylých, protože pouze rámec EA2F se orientuje na EA jako na produkt a definuje jeho životní cyklus včetně toho jaký v té které fázi má produkt být, zatímco ostatní rámce se zaměřují na to, jaký by měl být EA Management. U podniků, kde EA nemá oporu v zákoně, aplikujeme standardní mechanismy dle přijatých zásad Governance, které má společnost implementovány pro audit podnikových programů, neboť EA program chápeme jako kterýkoliv jiný program, který bychom v podniku realizovali. Cílem prověření je: a) stanovení úrovně shody programu se stanovenými postupy managementu podniku, tj. jedná se o audit shody b) zjištění do jaké míry výsledky programu jsou schopny naplnit cíle organizace, tj. ujištění – assurance. Jako hodnotící kritéria lze využít kritéria rámců a metodik, které byly uvedeny výše, případně lze využít kritérií, která jsou určena pro prověření dílčích částí (viz dále). Vedle toho se objevují i metodiky vyvinuté speciálně pro hodnocení podnikové architektury. Do této skupiny dnes patří:  EA Audit Model (EA2M) z dílny Carnegie Mellon University. Model „je založen na nejlepších praktikách CMMI a GAO Enterprise Architecture Management Maturity Framework. EA2M vytváří základnu auditní procedury, kterou je podniková architektura hodnocena a která se zaměřuje na tři základní kategorie – úplnost, shoda a účinnost“ (Bernard, a další, 2009).  Extended Enterprise Architecture Maturity Model (E2AMM) od společnosti IFEAD13, který je založen na CMMI a pomocí kterého lze hodnotit celkovou úroveň programu v 11 oblastech (Schekkerman, 2006). Hodnotící rámec je však silně svázán s rámcem „The Extended Enterprise Architecture Framework (E2A)™“.  Architecture Maturity Matrix (DyA AMM) sestavený společností Sogeti jako součást Dynamic Architecture (DyA). EA program je hodnocen v 18 

13

Institute For Enterprise Architecture Developments

62



oblastech a každá z oblastí se může nacházet v jedné ze tří úrovní (van Steenbergen, 2005).

4.2 EA procedury Oblast EA procedur, zahrnující EA rámec, EA management a EA governance patří k významným aspektům podnikové architektury. Jako dominantní v této oblasti vidím postavení EA rámce, protože do organizace přináší vedle již zmíněného EA modelu i postupy EA managementu a její governance. Principy, metody i obsah EA managementu a EA Governance by měly být v souladu s principy, metodami a obsahem podnikového managementu a Governance jak v oblasti byznysu, tak také v oblasti IT. Jak již bylo zmíněno, na trhu je k dispozici celá řada EA rámců a je proto nutné věnovat jeho výběru významnou pozornost. Jeho metody by neměly být v rozporu s metodami managementu a Governance, ale měly by je v oblasti EA obohatit, zpřesnit a formalizovat. Například pokud za standard v Enterprise Governance a interního podnikového auditu považujeme COSO Internal Control—Integrated Framework a v oblasti IT Governance je jím COBIT, pak podle sice již starších studií „COBIT Mapping“ (ITGI, 2006) a „Mapping of TOGAF 8.1 with COBIT 4.0“ (ITGI, 2007), by takovým EA rámcem mohl být TOGAF, který vykazuje vysokou míru shody s COBITem (viz Obrázek 5).

Zdroj: (ITGI,2006)

Zdroj: (ITGI,2007)

Obrázek 5 Míra shody mezi rámci TOGAF, COSO IC a COBIT14 Při prověřování EA procedur, je vhodné, abychom respektovali časové hledisko a abychom rozlišovali etapu, ve které je EA do podnikového řízení „poprvé“ zaváděna, a etapu „rutinního“ užívání EA procedur. V etapě zavádění EA lze uvažovat o dvou objektech prověřování. Jedním je EA framework a druhým EA management a EA Governance. V případě, že objektem auditu je EA framework, pak cílem prověřování je stanovení míry shody uplatněného postupu výběru rámce a postupy managementu. Kritériem hodnocení je pak podnikem přijatý a chválený postup výběru nových metod. V případě, že EA rámec vznikl kombinací několika rámců, pak by mělo být zahrnuto i prověření shody vzniklého EA rámce se standardem. Jako kritérium hodnocení lze v této situaci použít již zmiňovanou metodu hodnocení architektonických rámců dle Leistové a Zelnera (2006) a standard ISO/IEC 42010:2007. 14 Mezi zmíněnými studiemi existuje v hodnocení procesní shody mezi COBITem a TOGAFem významné rozdíly. Protože studie z roku 2007 (ITGI, 2007) poskytuje velmi detailní informace o mapování procesů, jsou ve sloupci TOGAF použity hodnoty z této studie.


63

Libor Gála

Ve druhém případě jsou objektem ověřování EA management a EA governance, které jsou v souvislosti s přijatým EA rámcem v organizaci adoptovány. Za kritérium hodnocení jsou v tomto případě považovány v podniku adoptované metody managementu a Governance. Cílem prověřování pak je stanovení úrovně shody mezi navrženými metodami EA managementu a EA governance a formulovaným kritériem hodnocení, tj. jedná se o odhalení možných rozporů mezi v organizaci používanými metodami a nově zaváděnou metodou. Při volbě již zmíněného TOGAfu se jedná o soulad procesů EA Governance s procesy domény Plánování a organizace COBITu. V etapě „rutinního“ užívání EA procedur se objektem prověření stávají skutečně prováděné činnosti EA managementu a EA governance. Kritériem hodnocení jsou přijaté a odsouhlasené metody EA managementu a EA governance a cílem prověření je stanovení míry shody v zavedených metodách a jejich skutečným prováděním. Cílem ale může být také ujištění, že aplikované metody umožní dosažení stanovených cílů i s tím, že získáme představu o tom, jek je možné EA procedury zlepšit. Při stanovení kritérií využijeme buďto některého z již zmíněných komplexních rámců (viz kapitola 4.1) anebo některého z rámců, který je EA frameworkem přímo doporučován. Např. již zmíněný TOGAF doporučuje jakýkoliv na CMM nebo CMMI rámec, případně rámec ACMMF.

4.3 EA model V případě, že objektem ověření je EA model, tj. EA chápeme jako produkt, cílem ověření je úplnost, konzistence a pravdivost EA modelu. První dva cíle, tj. úplnost a konzistence, tvoří obsah auditu shody, zatímco pravdivost je cílem buďto audit shody (u stavu současného) anebo ujištění (u stavu budoucího a žádoucího). Objektem ověření je:  souhrn modelů, které popisují podnikovou architekturu (ve stavu současném a budoucím a dle formulovaných hledisek), a  transformační plán přechodu ze současného do budoucího stavu. Které modely, v jaké míře podrobnosti mají být popsány, a jak mají být modely vzájemně provázány, aby byla zajištěna jejich vnitřní konzistence, a také co a v jaké podrobnosti má být obsahem transformačního plánu, určuje zvolený EA rámec, který tak vytváří kritérium hodnocení v oblasti hodnocení úplnosti a konzistence EA modelu. Jako příklad uveďme rámec TOGAF, který zaujímá přední pozici v podnikovém prostředí ((Aziz, et al., 2007), (Obitz, et al., 2009)). Ten ve své čtvrté části přímo formuluje obsahový metamodel architektury zahrnující jednotlivé architektonické artefakty, objekty a atributy a vzájemné vztahy mezi nimi. TOGAF zároveň formuluje i obsah tzv. transformační architektury, což je vlastně transformační plán z výchozího stavu EA do stavu budoucího. Jiným příkladem může být rámec E2A, který disponuje i vlastní metodikou hodnocení EA modelu Enterprise Architecture Assessment Guide (EAAG). Ta je založena (Schekkerman, 2006) na 31 otázkách, které jsou rozděleny do šesti úrovní. Konzistence a úplnost modelů jsou zahrnuty v rámci kontextu, okolí, konceptu, logické a fyzické úrovni. Transformace se pak orientuje na charakter transformačního plánu. Vše hodnotíme ze čtyř pohledů, tj. byznysu, informace, informační systém a technologickou infrastrukturu. Vyhodnocením zaznamenaných údajů (Enterprise Architecture Score Card) získáme úroveň zralosti, kterou lze srovnáváme se zralostí definovanou Extended Enterprise Architecture Maturity Model (E2AMM). Zároveň 64



lze uvést, že zajištění úplnosti a konzistence EA modelu je úkolem EA managementu a jeho kontrolní mechanismy by měly možné rozpory odhalit a zajistit jejich nápravu. Oblast prověření míry pravdivosti modelu je poněkud složitější. Je to způsobeno tím, že kritérium hodnocení leží mimo podnikovou architekturu a objekt ověření vyjadřuje vedle stavu současného i stav budoucí (žádoucí). Uvažujme nejprve situaci, kdy objektem prověření je ta část EA modelu, která zachycuje současný stav. V tomto případě je cílem prověření pravdivost tohoto modelu. Kritériem hodnocení jsou skutečné objekty podniku (podnikové zdroje) a jako vhodné se při jejich identifikaci a rozdělení do segmentů jeví využití modelu strategického souladu. Skutečné objekty i EA model by měly vyjadřovat v minulosti přijatou a do objektů podniku implementovanou podnikovou strategii. V situaci, kdy objektem prověření je ta část EA modelu, která vyjadřuje budoucí stav, pak spíše než o pravdivosti hovoříme o konformitě, neboť kritériem hodnocení je námi formulovaný model reprezentovaný přijatou strategií. Protože však další model nevzniká, neboť je sám součástí EA modelu, pak místo auditu shody v této situaci uplatníme ujištění, že námi formulovaný EA model je konformní ke strategii, respektuje zvolenou strategii dosažení strategického souladu, případně zvolenou strategií operačního modelu a že naplňuje strategické cíle. Pro úplnost je nutné zmínit ověření transformačního plánu. Na prověření lze nahlížet jako na realizaci auditu shody anebo ujištění. Cílem auditu shody v této části je zjistit, zda metoda a postup transformačního plánu je ve shodě s metodami managementu byznysu i IT, které zároveň hrají roli kritéria hodnocení. Jedná se o důležitý aspekt, neboť dle tohoto plánu bude organizace postupovat v jednotlivých doménách řešení, tj. v byznys i IT programech a metody zde navržené by měly být v souladu s metodami v podniku užívanými. V případě, že v této oblasti, tj. u transformačního plánu chceme získat ujištění, pak lze uvažovat o dvou cílech. Prvním je prověření reálnosti plánu, tj. zda jsme při daných podmínkách v organizaci schopni plán realizovat a druhým je prověření, zda plánem se skutečně dostaneme k cíli, tj. zda zvolené kroky plánu nás dovedou do stavu, který je formulován EA modelem, a ne do stavu jiného. Vždy by pak mělo být prověření realizováno pro oba cíle. Jako příklad prověření EA modelu lze uvést situaci, kdy využijeme třeba již zmiňovaného rámce TOGAF. Pravdivost pak stanovíme jako úroveň vyhovění mezi tím co architektura specifikuje a tím jaká je skutečnost neboli co bylo implementováno. TOGAF pro hodnocení zavádí 6 úrovní (The IT Governance Institute, 2007) – nerelevantní, konzistentní, vyhovující, částečná shoda, plná shoda, neshoda. Nebo pokud využijeme třeba AMM, pak nás zajímají při stanovení kritérií hodnocení následující oblasti rámce - sladění s byznysem, sladění s provozem, vztah architektury k aktuálnímu stavu podniku a údržba architektonického produktu. Mimo to lze v této souvislosti využít i specializovaný rámec, který hodnotí úroveň dosaženého souladu mezi byznysem a IT. Jedná se použití Strategic Alignment Maturity Model (SAMM), v rámci kterého Luftman (2003) zařadil do jedné ze šesti sledovaných oblastí i architekturu (Scope and Architecture). Architektura pak hodnocena z hlediska integrace, transparence a flexibility a je integrální součástí hodnocení strategického souladu. SYSTÉMOVÁ INTEGRACE 2/2010

65

Libor Gála

EA model jako výsledek EA programu na druhé straně sám může být kritériem hodnocení. Jedná se o situace, kdy předmětem je prověření, zda chování podniku i IT je v souladu s plánem, který je reprezentován EA modelem.

4.4 EA IT podpora Oblast EA IT podpory představuje množinu vhodných IT nástrojů včetně repository pro podporu modelování a udržení konzistence mezi modely podnikové architektury. Při jejich výběru je vhodné se zabývat i integrací a slučitelností s ostatními informačními technologiemi v podniku včetně prostředků, které jsou používány v jednotlivých informatických projektech. Za kritéria hodnocení je nutné v prvé řadě považovat formulované EA procedury. Protože na oblast EA IT podpory lze nahlížet také jako na jakýkoliv IT projekt, pak ke kritériím hodnocení patří i soulad s přijatými pravidly v této oblasti, tj. je možné užít jednak COBIT, ale také ITIL (IT Infracture Library).

5. Závěr Oblast prověřování podnikové architektury představuje řešení komplexního problému, které lze realizovat různými úrovněmi (kontrola, audit a ujištění) a v různých oblastech EA. Ukazuje se, že již existuje dostatek vhodných prostředků, které lze při prověřování využít. Za klíčové je dle mého názoru považovat volbu vhodného EA rámce, neboť ten s sebou přináší jak metody EA managementu tak také upřesňuje a formalizuje metody EA Governance, které rozšiřují formalizaci postupů Enterprise Governance a IT Governance. Poděkování Tento příspěvek představuje dílčí výsledky výzkumu, který je realizovaný jako část výzkumného programu financovaného Grantovou agenturou ČR. Prezentovaný výzkum je podporován Grantovou agenturou ČR – grant číslo: P403-10-0303 Enterprise Architecture jako princip v řízení malých a středních organizacích.

6. Použité zdroje Aziz, Sohel and Obitz, Thomas. 2007. Enterprise Architecture is Maturing : Infosys Enterprise Architecture Survey 2007. [Dokument] s.l. : Infosys Technologies, 2007. Bernard, Scott a Grasso, John. 2009. Enterprise Architecture Formalization and Auditing. [autor knihy] Gary Doucet, a další. Coherency Management: Architecting the Enterprise for Alignment, Agility and Assurance. Bloomington : International Enterprise Architecture Institute, 2009. Boynton, William C. a Johnson, Raymond N. 2005. Modern Auditing. Assurance Services and the Integrity of Financial Reporting. 8. Edition. místo neznámé : John Wiley & Sons, 2005. str. 1036 p. ISBN-13: 978-0-471-23011-3. Bredemeyer, Dana a Malan, Ruth. 2004. What It Takes to Be a Great Enterprise Architect. Cutter Consortium. [Online] 2004. [Citace: 3. Červenec 2008.] http://www.cutter.com/promotions/ear0408/ear0408.pdf. 66



Buchalcevová, Alena a Gála, Libor. 2008. Architektura v podnikové informatice. Systémová integrace. 2008, ročník 15, číslo 3. Dvořáček, Jiří a Kafka, Tomáš. 2005. Interní audit v praxi. Brno : Computer Press, 2005. ISBN 80-251-0836-8 . Dvořáček, Jiří. 2005. Audit podniku a jeho operací. Praha : C. H. BECK, 2005. str. 180 s. ISBN 80-7179-809-6. Evaluation of Current Architecture Frameworks. Leist, Susanne a Zellner, Gregor. 2006. Dijon, France : ACM, 2006. SAC '06: Proceedings of the 2006 ACM symposium on Applied computing. stránky 1546-1553. Gála, Libor, Pour, Jan a Šedivá, Zuzana. 2009. Enterprise Informatics (in Czech). Prague : Grada Publishing, 2009. ISBN - DOPLNIT. GAO. 2002. INFORMATION TECHNOLOGY. A Framework for Assessing and Improving Enterprise Architecture Management (Version 1.1). místo neznámé : GAO, 2002. GAO-03-584G Enterprise Architecture Management. Grepl, Miroslav a Karlík, Petr. 1998. Skladba češtiny. místo neznámé : Votobia, 1998. ISBN 80-7198-281-4. Hamaker, Stacey. 2005. Enterprise Governance and Role of IT. ISACA. [Online] 2005. [Citace: 10. 3 2010.] http://itgi.org/Template.cfm?Section=Home&Template=/ContentManagement/ ContentDisplay.cfm&ContentID=27796. Henderson, John C. a Venkatraman, N. 1993. Strategic alignment: Leveraging information technology for transforming organizations. IBM Systems Journal. 1993, Sv. Vol. 32, No. 1. Chlapek, Dušan. 2008. Návrh metodického rámce řízení a koordinace projektů IS/ICT. Praha : VŠE-FIS, 2008. disertační práce. IFAC. 2004. Enterprise Governance : Getting the Balance Right. [online] New York : International Federation of Accountants, 2004. ISBN: 1-931949-24-7. ISACA. 2003. ISACF Renamed IT Governance Institute. ISACA. [Online] 20. October 2003. [Citace: 10. 03 2010.] http://www.isaca.org/Template.cfm?Section=Home&CONTENTID=9738&TE MPLATE=/ContentManagement/ContentDisplay.cfm. ISO/IEC. 2007. ISO/IEC 42010:2007. Systems and software engineering -- Recommended practice for architectural description of software-intensive systems. místo neznámé : ISO, 2007. IT Governance Institute. 2007. IT Assurance Guide: Using COBIT. b.m. : IT Governance Institute, 2007. ISBN 1-933284-74-9. ITGI. 2006. COBIT Mapping Overview of International IT Guidance 2nd Edition. místo neznámé : IT Governance Institute, 2006. ISBN 1-933284-31-5. —. 2007. TOGAF™ and COBIT®: Mapping of TOGAF 8.1 with COBIT 4.0. místo neznámé : The Open Group, 2007. ISBN 978-1-933284-82-X.. Kamogawa, Takaaki a Okada, Hitoshi. 2009. Enterprise Architecture Create Business Value. Proceedings of the 2009 Ninth Annual International Symposium on Applications and the Internet, 2009, stránky 205-208. Kochan, Thomas A and Useem, Michael. 1992. Transforming organizations. Oxford : Oxford University Press, 1992. ISBN 0-19-506504-2. SYSTÉMOVÁ INTEGRACE 2/2010

67

Libor Gála

Komora auditorů ČR. 2007. Poslání a smysl auditu. Komora auditorů ČR. [Online] 2007. [Citace: 28. 03 2008.] http://www.kacr.cz/Article.asp?nDepartmentID=18&nArticleID=6&nLanguageI D=1. Kraus, Jiří. 2009. Nový akademický slovník cizích slov. Vydání první, dotisk 2009. Praha : Nakladatelství Academia, 2009. ISBN 978-80-200-1351-4. Langenberg, Kerstin and Wegmann, Alain. 2004. Enterprise Architecture: What Aspects is Current Research Targeting? [Dokument] Lausanne : Ecole Polytechnique Fédérale de Lausanne, 2004. EPFL Technical Report IC/2004/77. Lankhorst, Marc and al., at. 2005. Enterprise Architecture at Work: Modelling, Communication, and Analysis. Berlin : Springer, 2005. ISBN: 978-3-54024371. Malveau, Raphael. 2004. Bridging the Gap: Business and Software Architecture, Part 2. The Cutter Edge. [Online] 3 February 2004. [Cited: 13 březen 2006.] http://www.cutter.com/research/2004/edge040203.html. Measure your business-IT alignment. Luftman, Jerry N. 2003. Manhasset : Optimize, 2003. ISSN 15372308. Müllerová, Libuše. 2007. Auditing pro manažery aneb proč a jak se ověřuje účetní závěrka. b.b. : ASPI a.s., 2007. ISBN 978-80-7357-308-9 . NASCIO. 2003. NASCIO Enterprise Architecture Maturity Model. National Association of State Chief Information Officers. [Online] December 2003. [Citace: 13. 04 2010.] http://www.nascio.org/publications/documents/NASCIO-EAMM.pdf. Novák, Luděk. 2010. Modely řízení přidané hodnoty a řízení rizik informačních technologií v podniku. [autor knihy] Petr Doucek. Informační management. Praha : Professional Publishing, 2010. Obitz, Thomas and Babu, Mohan K. 2009. Enterprise Architecture Expands its Role in Strategic Business Transformation : Infosys Enterprise Architecture Survey 2008/2009. [Dokument] s.l. : Infosys Technologies, 2009. OECD. 2004. OECD Principles of Corporate Governance. [online] Paříž : OECD Publications Service, 2004. http://www.oecd.org/dataoecd/32/18/31557724.pdf. Office of Management and Budget. 2007. Improving Agency Performance Using Information and Information Technology (Enterprise Architecture Assessment Framework v3.1). [Online] June 2007. [Citace: 23. 04 2010.] http://www.whitehouse.gov/omb/assets/fea_docs/OMB_EA_Assessment_Fra mework_v3_1_June_2009.pdf. Ricchiute, David N. 1994. Audit. [překl.] Milan Třaskalík Z amer. orig. přel. Lidmila Janečková. Praha : Victoria Publishing, 1994. str. 792 s. ISBN 80-85605-86-4. Ross, Jeanne W., Weill, Peter a Robertson, David C. 2006. Enterprise architecture as strategy : creating a foundation for business execution. Boston : Harvard Business School Publishing, 2006. ISBN 1-59139-839-8.

68



Schekkerman, Jaap. 2006. Enterprise Architecture Assessment Guide, Version 2.2. Institute for Enterprise Architecture Development. [Online] 2006. [Citace: 23. 11 2008.] http://www.enterprise-architecture.info/Images/ Architecture%20Score%20Card/Enterprise%20Architecture%20Assessment%20Guide %20v2.2.pdf. —. 2006. Extended Enterprise Architecture Maturity Model Support Guide, Version 2.0. [Online] IFEAD, 2006. [Citace: 14. 04 2010.] http://www.enterprisearchitecture.info/Images/E2AF/E2AMMv2.PDF. —. 2004. How to survive in the jungle of Enterprise Architecture Frameworks. Second Edition. Victoria, Canada : Trafford Publishing, 2004. ISBN 1-4120-1607-X. Sládek, Pavel. 2010. Enterprise Architecture v systému řízení. Praha : Vysoká škola ekonomická, 2010. Kvalifikační práce. Spewak, Steven H. 1993. Enterprise Architecture Planning: Developing a Blueprint for Data, Applications, and Technology. New York : John Wiley and Sons, 1993. ISBN-13: 978-0471599852. Svatá, Vlasta. 2005. Audit informačního systému. Praha : Oeconomica, 2005. ISBN 80-245-0975-X. —. 2010. Vývoj, druhy a obsah auditu IS. [aplikace ISIS] Praha : autor neznámý, 2010. Interní dokument. The IT Governance Institute. 2007. TOGAF™ and COBIT® : Mapping of TOGAF 8.1 with COBIT 4.0. San Francisco : The Open Group, 2007. ISBN 978-1933284-82-X. The Open Group Architecture Forum. 2009. TOGAF Version 9 : The Open Group Architecture Framework (TOGAF). [Dokument] místo neznámé : The Open Group, 2009. ISBN 978-90-8753-230-7. Towards a Common Terminology in the Discipline of Enterprise Architecture. Schöenherr, Marten. 2008. Berlin : Springer-Verlag, 2008. Service-Oriented Computing --- ICSOC 2008 Workshops. van Steenbergen, Marlies E. 2005. Architecture Maturity Matrix. DYA. [Online] May 2005. [Citace: 14. 04 2010.] http://eng.dya.info/Images/Description%20Architecture%20maturity%20matri x_tcm14-23256.pdf. Vašíček, Václav. 2010. Vztah Enterprise Architecture a strategického managementu. Praha : autor neznámý, 2010. Diplomová práce (Ing.) Vysoká škola ekonomická v Praze. Fakulta Informatiky a statistiky. . Zachman, John A. 1987. A Framework for Information Systems Architecture. IBM Systems Journal. Vol. 26, No. 3 1987.


69

Prověřování podnikové architektury

Recommend Documents