Role architekta a její vliv na výslednou hodnotu služeb IT

Role architekta a její vliv na výslednou hodnotu služeb IT Jan Tolar Hewlett-Packard Vyskočilova 1/1410, 140 00 Praha 4 [email protected] Abstrakt: Článek se zamýšlí nad vlastním určením role Enterprise architekta (a architektonických týmů) v kontextu návrhu, tvorby a správy informačních systémů a významem této role pro realizaci hodnoty z investic do služeb IT a informačních technologií obecně. Vedle vlastního popisu mechanismů, jimiž dochází ze strany architektů a architektonických týmů k přímému či nepřímému ovlivňování výsledné hodnoty (tj. schopnosti produktu/výstupu uspokojit potřeby zadavatelského subjektu) informačních systémů a služeb IT, se článek zabývá i předpoklady, jež by měla role architekta (ale i architektonického týmu jako celku) splňovat, má-li být výsledná hodnota aplikovaných řešení (systémů, služeb apod.) skutečně pozitivní a relevantní vloženým finančním prostředkům a úsilí. Na několika příkladech je současně demonstrován zásadní rozdíl mezi zastřešující rolí Enterprise architekt, v pravém smyslu tohoto označení, vůči dílčím architektonickým rolím, se kterými se v běžné IT praxi potkáváme (systémový architekt, aplikační architekt, síťový architekt, procesní architekt atd.). Abstrakt:The article examines the role of Enterprise Architect (as well as architectural teams) in wider context of design, building and management of information systems, and importance of this role for realization of value from investments into IT services and information technology. Beside the description of mechanisms through which architects (and architectural teams) influence (directly or indirectly) the final value of applied information systems and services, the article also discusses assumptions which the role of Enterprise Architect (but also architectural teams) should meet in order to final value of implemented solutions is really positive and adequate to invested money and effort. In addition there is highlighted the difference between overarching role of Enterprise Architect and other architectural roles (e.g. system architect, network architect, process architect etc.) which is demonstrated on several examples. Klíčová slova: architekt, enterprise architekt, architektonický team, hodnota služeb, předpoklady efektivní architektury, transformace Keywords: architect, enterprise architect, architectural team, service value, assumptions of efficient architecture, transformation Motto: Většina firem má v současné době naprosto srovnatelné vybavení a technologie, takže klíčovou konkurenční výhodou, kterou mohou získat, jsou co nejlepší lidé. Nejlepšími lidmi se rozumí ti, kteří se nejlépe hodí na konkrétní procesy. (autor neznámý)

1. Úvod V 1938 Konrád Zuse dokončil stavbu prototypu mechanického počítače Z1. Roku 1939 Američané William Hewlett and David Packard zakládají ve městě Palo Alto společnost Hewlett-Packard. V roce 1947 Howard Aiken uvádí do provozu reléový počítač SSCC (Selective Sequence Controlled Computer). O téměř deset let později (1956) osazuje SYSTÉMOVÁ INTEGRACE 2 - PŘÍLOHA/2011

137

Jan Tolar

společnost IBM svůj počítač IBM 305 RAMAC, jako první na světě, komponentou podobnou dnešním pevným diskům o neuvěřitelné kapacitě 5 MB. V roce 1968 zakládají Robert Noyce a Gordon Moore společnost Intel. V roce 1970 je ve světě instalováno 111600 počítačů a hned v následujícím roce dochází v síti ARPANet k odeslání první emailové zprávy. Bill Gates a Paul Allen zakládají roku 1975 společnost Mikro-Soft (pozdější Microsoft), síť ARPANet propojuje zhruba 50 počítačů. V roce 1982 spatřuje v počítačích IBM světlo světa MS-DOS 1.0, následovaný v roce 1985 operačním systémem Windows 1.0. V průběhu roku 1990 vytváří Tim Berners-Lee první verzi HTML (HyperText Markup Language) a zavádí pojem WWW (world wide web). Začíná, zatím spíše tušená než reálně zakoušená, počítačová revoluce. Během devadesátých let dochází k masivnímu rozšiřování počítačů a prostředků výpočetní techniky do podnikové i privátní sféry, spojeného s očekáváním výrazného ekonomického růstu, a zejména v podnikatelských kruzích, se získáním signifikantní konkurenční výhody, jež vyúsťuje v letech 1995 – 2000 v tzv. „dot-com bubble“, první internetovou bublinu provázenou výrazným propadem hodnoty akcií většiny technologických firem, z nichž valná část tento propad nepřežila. V návaznosti na události spojené s „dot-com bubble“ a přemrštěná očekávání vkládaná do informačních technologií publikuje v roce 2003 profesor Nicholas G. Carr v Harvard Business Review provokativní článek „IT Doesn’t Matter“ (volně přeloženo „Na IT nezáleží“), v němž poukazuje na nesmyslnost očekávání dosažení konkurenční výhody z vlastnictví prostředků informačních technologií a varuje před neuváženým pořizováním informačních technologií, které – dle jeho soudu – nemohou poskytnout takovou výhodu, jež by byla adekvátním vloženým prostředkům. Přes četné negativní reakce, jež jeho článek v odborné i laické veřejnosti vyvolal se ukazuje, že mnohá tvrzení prof. Carra byla opodstatněná, zejména pokud jde výhodu získanou z vlastnictví informačních technologií. Nicméně – a to je potřeba zdůraznit – informační technologie mohou být zdrojem konkurenční výhody či hodnoty pro společnost. Avšak zdrojem této výhody či hodnoty není (a z podstaty věci ani být nemůže) pouhé vlastnění či provozování informačních technologií (ačkoliv se to tak v počátcích počítačové revoluce zdálo), ale jejich kreativní uplatnění s ohledem na uživatelský subjekt, účel a kontext jejich užití. Jinými slovy: i tak obyčejná komodita jakou je dnes osobní počítač, může být zdrojem signifikantní hodnoty či výhody, je-li využita tvůrčím způsobem ve prospěch cíle uživatelského subjektu a v odpovídajícím kontextu. Pro lepší představu – vlastnictví a běžné využívání počítače samo o sobě nepřináší autorovi tohoto článku žádnou zvláštní výhodu či hodnotu, avšak jeho využití např. při psaní tohoto článku, nebo při přípravě odborné publikace, jež se může stát zdrojem příjmu jejího tvůrce, již potencuje dosažení určité hodnoty, jejíž míra může dále růst v návaznosti na četnost a zejména účelnost využití tohoto zařízení. Na tomto místě by bylo možné si položit otázku, jaká je souvislost tohoto exkurzu do historie informačních technologií s vlastním tématem článku? Odpověď je nasnadě: akceptujeme-li výše uvedené stanovisko, totiž, že informační technologie mohou být – jsou-li účelně a efektivně využívány – zdrojem výrazné hodnoty či výhody pro podnik, pak jsou to právě architekti a architektonické týmy a jejich schopnost navrhnout a aplikovat 1 2 koncepčně vyvážený a dlouhodobě efektivní informační systém či služby IT , jež se 1

Informační systém (Information System, IS) podniku je systém informačních a komunikačních technologií, dat a lidí, jehož cílem je efektivní podpora informačních, rozhodovacích a řídících procesů na všech úrovních řízení podniku (Voříšek, 2008). 2 Služba IT je taková činnost/aktivita útvaru IT, jež prostřednictvím řízeného využívání zdrojů IT (vlastní informační technologie, personál IT, znalosti atd.) uspokojuje potřeby 138

SYSTÉMOVÁ INTEGRACE 2 - PŘÍLOHA/2011

Role architekta a její vliv na výslednou hodnotu služeb IT

nemalou měrou podílejí na dosahování této hodnoty z využívání informačních technologií a investic do nich realizovaných. A je-li hodnota většiny stávajících informačních systémů pro byznys firem přinejmenším sporná (a není tím myšlena pořizovací hodnota jednotlivých komponent informačního systému, ale jeho celková užitečnost pro organizaci, jeho schopnost uspokojit její potřeby), pak je to jen logický důsledek zásadního podcenění této role, jejího vlivu, a možná i nepochopení úlohy Enterprise Architektury v podnikovém prostředí.

2. Role architekta a její vliv na výslednou hodnotu služeb IT Abychom se vyhnuli případnému budoucímu nepochopení, vymezme si - dříve než přistoupíme k vlastnímu zkoumání vlivu architektů a architektonických týmů na hodnotu 3 služeb IT – pojmy/role „architekt“ a „architektonický tým“ . Etymologicky vychází termín „architekt“ z řeckého arkhitekton (arkhi – vedoucí, řídící; tekton – stavitel) a vztahuje se na osobu, která „je vzdělaná, vyškolená a zkušená v oblasti plánování, návrhu a dohledu nad výstavbou; odborně školený stavitel, navrhovatel staveb“. Jinými slovy bychom mohli roli „architekt“ také popsat jako osobu, jež je schopná tvůrčím způsobem zpracovat/přetvořit požadavek zadavatele do funkčního návrhu výsledného produktu, specifikovat kroky k vedoucí k jeho faktické realizaci a odborně dohlédnout, že realizace/praktická tvorba produktu je prováděna efektivně a účinně tak, aby bylo vyhověno zadání resp. potřebě zadavatele. V návaznosti na takovouto obecnou definici pak můžeme Enterprise architekta (o němž budeme nadále hovořit) chápat jako osobu zodpovědnou (nebo přinejmenším spolu-zodpovědnou) za pochopení potřeb a požadavků zadavatele (byznys), jejich přetvoření/transformaci do návrhu konkrétních služeb a systémů IT, za specifikaci realizačního plánu a dohled nad vlastní implementací služeb či systémů nutných pro jejich dodávku. 4 Poznámka 1: Enterprise architekti jsou jako urbanisté , definující plány a pravidla pro rozvoj města a poskytování služeb občanům. V této analogii by pak bylo možné dále rozlišovat roli systémových architektů, zodpovědných zpravidla za výstavbu jedné či několika budov, softwarové architekty, zodpovídající za vytápění, větrání, klimatizaci; síťové architekty, do jejichž kompetence spadají vnitřní rozvody (voda, kanalizace atd.) v rámci budovy a současně i mezi dalšími budovami, nebo částmi města, a celou řadu dalších rolí. Enterprise architekt je však ten, jen vytváří celkový koncepční plán města, a který definuje a uvádí v soulad kroky nutné pro jeho realizaci. (volně dle Rosen, 2008) (zejména pak informačně-technologické) jejího odběratele/zákazníka (podniková jednotka, obchodní proces apod.) (Tolar, 2011) 3 Je až s podivem, v kolika případech se lze v praxi potkat se základní neznalostí významu těchto pojmů, nebo s jejich zásadním nepochopením či zmatením, což následně projevuje ve výsledné (často velice nízké) hodnotě jíž dané role produkují. 4 Dle tzv. Nové aténské charty (1998) Evropské rady urbanistů (European Council of Spatial Planners), je urbanista ten kdo umožňuje a usměrňuje rozvoj měst. Při definování tohoto rozvoje by urbanisté měli udržovat dialog s partnery na místní, národní a evropské úrovni a integrovat získané poznatky a zkušenosti tak, aby uspořádání měst vyhovovalo potřebám společnosti. Možná v jiných kulisách, ale de-facto totéž požadují podniky/společnosti od Enterprise architektů, totiž – aby umožňovali a usměrňovali rozvoj technologického zázemí podniku a v dialogu s partnery a s využitím poznatků a zkušeností vytvářet takové systémy a služby IT, které budou vyhovovat potřebám společnosti. SYSTÉMOVÁ INTEGRACE 2 - PŘÍLOHA/2011

139

Jan Tolar

2.1 Enterprise architektura a její vliv na hodnotu služeb IT Jak již bylo naznačeno výše – služby a systémy IT mají potenciál vytvářet jeden z klíčových prostředků konkurenční výhody podniku, a Enterprise architektura, je-li správně uchopena a realizována, pak tento potenciál přímo ovlivňuje, a prostřednictvím návrhu služeb a systémů IT umocňuje strategii společnosti. Co si však představit pod pojmy jako je “správně uchopená a realizovaná Enterprise architektura”? Je to excelentní 5 6 7 8 znalost některého z dostupných EA rámců (Zachman , TOGAF , FEAF , DoDAF apod.) a design vlastní IT architektury dle těchto rámců? Do jisté míry ano. Je to relativně široké povědomí o možnostech informačních technologií a jejich budoucím vývoji? Opět – do jisté míry ano. A co znalost dalších, komplementárních rámců a metodologií? Bezesporu. Nicméně stále je to jen část z pomyslného celku „správně uchopené a realizované Enterprise architektury“. Jaké jsou tedy další části? Zcela jistě to bude respekt vůči potřebám a požadavkům společnosti, zejména pak vůči jejím strategickým cílům a aktivitám, jež by měly být službami IT (a systémy pro jejich dodávku) podporovány, a jejich správné pochopení . Pozor: fakt, že architektonický tým pracuje podle některého z výše uvedených EA rámců ani v nejmenším neimplikuje závěr, že výsledná Enterprise architektura pro IT bude respektovat a zohledňovat cíle a strategické zájmy podniku (a v konečném důsledku potencovat vytváření hodnoty či 9 konkurenční výhody podniku) . Neboť EA rámce (nebo rámce k nim komplementární) zpravidla definují – v hrubých konturách – jak postupovat při tvorbě Enterprise architektury, jaké vstupy je nutné při její tvorbě zohlednit, a k jakým výstupům je třeba se dobrat, avšak ani v nejmenším nenabízejí mechanismy či prostředky jež zajistí, že např. strategické cíle podniku, jeho požadavky, zájmy, potřeby, byly ze strany architektonického týmu správně pochopeny (ale také řízeny – viz následující poznámka 2) a adekvátně transformovány do návrhu služeb IT a architektury informačního systému podniku. Poznámka 2: Přepis z reálné diskuse mezi zástupci byznysu a Enterprise architektem (zkráceno): Zástupce byznysu: Chceme nasadit nový systém pro řízení marketingových kampaní. Enterprise architekt: Můžete specifikovat proč? Co je účelem? Zástupce byznysu: Protože potřebujeme nasadit nový systém pro řízení marketingových kampaní. Enterprise architekt: Ale proč? Co určuje tuto potřebu? Zástupce byznysu: Jak to myslíte?

5

Více také např. na http://www.zifa.com/ TOGAF - The Open Group Architecture Framework, více také např. na http://www.opengroup.org/architecture/togaf8-doc/arch/ 7 FEAF – Federal Enterprise Architecture Framework, více také např. na http://www.feacinstitute.org/ 8 DoDAF – Department of Defense Architecture Framework, více také např. na http://www.architectureframework.com/dodaf/ 9 Což je velice častým omylem rádoby architektů, kteří se domnívají, že pouhé zvládnutí teoretického základu daných rámců a jejich otrocké následování je cestou k vysoce efektivním službám a systémům IT. 6

140



Enterprise architekt: Chtěl bych vědět, proč je nutné nasadit nový systém pro řízení kampaní? Proč jste se k tomu rozhodli? A proč není možné využít – s dílčí úpravou – systém stávající? Zástupce byznysu: Můžete to blíže specifikovat? Enterprise architekt: Budu to demonstrovat na příkladu: Vy mi říkáte – potřebujeme novou lopatu. Já se vás ptám – proč? A k čemu hodláte tuto novou lopatu využívat a proč nelze využít již jednou pořízenou lopatu? Potřebujete lopatu na odhazování sněhu? Nebo potřebujete lopatku na dětské pískoviště? Nebo ještě zcela jinou? Stávající lopata je dostatečně vhodná pro odklízení sněhu již nyní. Ale není vhodná pro hru na dětském pískovišti. Podobné je to s naším marketingovým systémem, který již umožňuje řízení kampaní. Proč tedy potřebujeme nový? Je to proto, že naše společnost hodlá využívat zcela nový/odlišný mechanismus řízení kampaní, který nelze ani po úpravách stávajícího systému aplikovat (např. upouštíme od telemarketingu, ale chceme jít cestou využívání sociálních médií a neuromarketingu) – tj. chcete lopatku na pískoviště? Nebo pouze potřebujete přizpůsobit řízení kampaní (zejména pokud jde o jejich plánování, schvalování a vyhodnocování), což stávající systém plně umožňuje – tj. chcete pouze jinak pracovat se stávající lopatou? Zástupce byznysu: To je zajímavé. Takto nás nenapadlo o tom uvažovat. Enterprise architekt: Ale to je klíčové. Protože v jednom případu jsme schopni plně využít již stávající systém (a dále jej zhodnocovat). Naopak v druhém budeme nejspíše nuceni skutečně nasadit nový systém. Pak to však bude znamenat nesoustředit se jen na řízení marketingových kampaní, ale koncipovat nový systém v širších souvislostech... Výsledkem této diskuse, a několika dalších navazujících, bylo zjištění, že zástupci byznysu/marketingu v dané společnosti mají poměrně omezené znalosti o stávajícím marketingovém systému, a že nové požadavky společnosti na řízení marketingových kampaní (současná realizace kampaně prostřednictvím různých médií a agregované vyhodnocování výtěžnosti kampaně za všechna aplikovaná média), lze aplikovat již ve stávajícím systému (s relativně omezenými náklady), bez nutnosti jeho náhrady systémem novým. Další částí bude pochopení celkového kontextu, v němž jsou/budou navrhované služby a systémy provozovány. Tj. cílový architektonický návrh, stejně jako jednotlivé realizační kroky, aplikované technologie a řídící mechanismy musí důsledně zohledňovat: prostředí (společnost, předmět podnikání, struktura společnosti, specifika společnosti, řídící struktury, konkurence, postavení společnosti na trhu, ale např. i geopolitické faktory apod.) v němž budou dané služby a systémy IT operovány; organizačně-sociální vlivy (kulturně-sociální zvyklosti v podniku, schopnost společnosti absorbovat změny, fluktuace zaměstnanců, úroveň technologické gramotnosti uživatelů, úroveň manažerských dovedností ve firmě apod.), které mohou kriticky ovlivnit aplikovatelnost a využitelnost uvažovaných služeb či 10 systémů ;

10

Jedná se v praxi o jeden z nejvíce opomíjených faktorů, jehož podcenění ze strany Enterprise architekta a architektonického týmu může být pro implementované služby a systémy, byť věcně a funkčně správně navržené a nasazené, smrtící. Jednoduchý příklad: je-li technologická gramotnost uživatelů v podniku nízká (a do toho počítejme jak počítavou gramotnost, tak třeba i znalost základních procesních návyků apod.), pak celá Enterprise architektura IT (zejména pak pokud jde o uživatelem konzumované služby a SYSTÉMOVÁ INTEGRACE 2 - PŘÍLOHA/2011

141

Jan Tolar

technologické možnosti a omezení (vlastnosti a možnosti uvažovaných technologií a technologických komponent, jejich aktuální funkcionalita a využitelnost i plánovaný budoucí vývoj, dostupnost a využitelnost technologií v dlouhodobé perspektivě, škálovatelnost a přizpůsobitelnost technologií v závislosti na změně služeb resp. na měnících se požadavcích podniku, geopolitické či legislativní vlivy limitující využití určitého typu technologií apod.); časové návaznosti a konsekvence (kdy je možné kterou službu, nebo část informačního systému implementovat, aby bylo možné průběžně dosahovat definovaných hodnot, nebo nedocházelo ke zbytečným a finančně nákladným zpožděním; jak bude navržená architektura enterprise systému nasazována do organizmu společnosti v kontextu uvažovaných změn na úrovni podniku, aniž by v průběhu času docházelo k rozporům mezi architektonickým návrhem, aplikovanými řešeními a měnící se/rozvíjející se strategií podniku apod.) A v neposlední řadě to bude role (ale i osobnost) Enterprise architekta, architektonického týmu, jejich erudice, kreativita, praktická zkušenost, ale i zodpovědnost (!) za vlastní realizaci (včetně dodávky) služeb a systémů IT, a ochota nést za výsledek 11 odpovědnost . Což v kombinaci s výše uvedeným teprve determinuje „správně uchopenou a realizovanou Enterprise architekturu“, skýtající reálný hodnotový potenciál a konkurenční výhodu pro podnik. Ve světle zde definovaných základních předpokladů efektivní a účinné (rozuměj – hodnotu přinášející/podmiňující) Enterprise architektury je zřejmé, proč většina stávajících služeb a systémů IT připomíná amorfní slepenec všemožně posbíraných technologií víc, než koherentní celek vystavěný z pečlivě vybraných komponent a podřízený jedinému účelu - totiž dlouhodobě uspokojovat potřeby a požadavky zadavatele/uživatele/investora. Stejně tak je zřejmé, že by se výše uváděné předpoklady měly kumulovat a demonstrovat právě v roli Enterprise architekta, potažmo architektonického týmu, jenž by měl fungovat 12 jako činitel stmelující výše uvedené vlivy do smysluplného a homogenního celku . Vzpomeňme si na výše předložené srovnání Enterprise architekta se stavitelem, urbanistou – pokud by tato role nebyla schopná postihnout klíčové faktory určující výstavbu a budoucí rozvoj města (přičemž časová perspektiva v níž urbanista pracuje daleko převyšuje časový rámec, se kterým pracuje Enterprise architekt), pak bychom se velice záhy dočkali situace, kdy by naše města byla přeplněna posledními technologiemi, vystavěna podle posledních pravidel estetiky, ergonomie a dalších normativů, ale žít by se v nich nedalo. systémy/aplikace) musí být navržena s ohledem na míru této gramotnosti, která se sice může v čase měnit, avšak nikoliv zásadním způsobem. 11 Další z poměrně závažných praktických selhání nemalého množství Enterprise architektů a architektonických týmů, pro něž jejich odpovědnost končí předáním architektonických návrhů, schémat, taxonomií a definic, aniž by se dále zajímali o jejich praktické uplatnění, natož výslednou využitelnost a reálně dosahovanou hodnotu. A svým způsobem i selhání managementu společnosti, jenž jim takový postoj umožňuje a toleruje. 12 Problém je, že drtivá většina současných Enterprise architektů je sice mistry v odborné terminologii, taxonomii, ergonomii, technologii atd., ale jen mizivé procento jich je skutečně tvůrčími osobnostmi transformující zadání do smysluplného, využitelného a hodnotného výstupu. 142



Výše uvedený rozbor nás tedy vede k prvním závěrům: 1. Efektivita, účinnost a hodnototvorný potenciál Enterprise architektury není determinován pouze osvojením si určitého typu EA rámce (ten je možné chápat spíše jako jakýsi základ, na kterém lze dále stavět, podobně jako v případě architektů/stavařů je to znalost fyzikálních zákonů či matematiky) , ale zejména zohledněním všech kritických faktorů přímo ovlivňujících výsledný produkt (služby a systémy IT) a jeho hodnotu: požadavky a potřeby zadavatele o o o o

kontext, ve kterém bude daný produkt realizován a využíván prostředí a specifikace organizace organizačně-sociální vlivy technologické možnosti a vývoj v IT časové mantinely

osobnost a role Enterprise architekta resp. architektonického týmu 2. Osobnost a role Enterprise architekta (a architektonického týmu) je pro výslednou efektivitu Enterprise architektury a v konečném důsledku i aplikovaných řešení naprosto zásadní. Neboť tato role (v případě EA týmů pak kombinace rolí) a její schopnost důsledně zohlednit výše uvedené faktory přímo ovlivňuje hodnotu budoucího produktu (vhodnější by možná bylo říci: hodnotový potenciál budoucích řešení a zachování hodnoty řešení stávajících). S ohledem na zde naznačenou mimořádnou důležitost Enterprise architekta (a architektonického týmu) se této roli, jejím hlavním odpovědnostem, stejně jako předpokladům, ale i praktickým problémům s touto rolí spojených, budeme v další části tohoto článku věnovat podrobněji.

2.2 Role Enterprise architekta – odpovědnosti, předpoklady a vliv Již jsme si řekli, že Enterprise architekt je role odpovědná (!) za správné pochopení požadavků a potřeb zadavatele (společnosti/vedení společnosti) na podporu podnikových činností informatickými službami a informačními systémy, za transformaci těchto potřeb/požadavků do architektonického návrhu výsledného produktu (služeb IT a informačního systému podniku), specifikaci realizačních kroků a podmínek pro jejich 13 vykonání, až po dohled nad vlastní realizací a její případné usměrňování . Mezi hlavní odpovědnosti Enterprise architekta lze, vedle výše uvedených, zahrnout: zajištění souladu mezi strategiemi, cíli a plány podniku a IT (návrh, výběr, vytvoření a nasazení opakovaně využitelných komponent, vysoce škálovatelných a dynamicky přizpůsobitelných řešení, schopných kontinuální podpory podnikových funkcí, při současném zachování odpovídající kvality služeb, je nadmíru nákladná záležitost. Pouze architektura služeb a systémů důsledně vycházející ze strategie a cílů podniku má reálný potenciál návratnosti vložených prostředků. To jest – aby architektura služeb a systémů IT poskytovala maximální návratnost investic (ve formě poskytování výrazné hodnoty či výhody pro podnik a jeho činnosti), pak strategie společnosti, její cíle, 13

Pokud někdo ze čtenářů absolvoval výstavbu rodinného domu, pak si dovede působnost a odpovědnosti architekta – byť zde v jiném odvětví – velice dobře představit. SYSTÉMOVÁ INTEGRACE 2 - PŘÍLOHA/2011

143

Jan Tolar

stejně jako obchodní model organizace a vlastní struktura informačního systému musí být řešeny jako jeden celek. Přičemž jednotlivé části tohoto celku se zákonitě podmiňují a ovlivňují - více také např. Tomsky, 2009); optimalizaci a usměrňování mechanismů správy informací v návaznosti na měnící se informační potřeby podniku či vyvíjející se technologické možnosti; strategickou odpovědnost za informatické služby a informační systém/y podniku; zajištění max. využitelnosti a upotřebitelnosti technologické infrastruktury (prostřednictvím sdílení prostředků a výkonu výpočetní techniky, dynamické alokace zdrojů, stejně jako návrhu procesů a mechanismů umožňujících flexibilní přizpůsobování informačního systému dynamicky se měnícím 14 potřebám podniku ) a kontinuální optimalizace informačních toků v organizaci; zajištění, že realizované či plánované projekty se vztahem k IT jsou v souladu s architekturou služeb IT, informačního systému, jejich rozvojovým plánem, a že do informačního systému nejsou zanášeny duplicitní řešení, funkce; vedení architektonického týmu (EA týmu) podniku a úzká spolupráce s jeho stálými členy (architekti za jednotlivé technologické domény, byznys analytici atd.), stejně jako s dalšími subjekty (externí partneři, dodavatelé, auditoři apod.) 15 při návrhu cílových řešení služeb, systémů, procesů či informačních toků ; řízení a správa rizik spojených se zpracováváním informací, informačními technologiemi, procesy atd. a definování (byť třeba jen ve formě návrhu) odpovídajících standardů a pravidel; přímá či nepřímá účast na definici pravidel, směrnic a standardů pro výběr, pořizování, vývoj, zavádění a využívání informačních technologií v podniku; dohled nad výstavbou a využíváním informačního systému a jeho služeb. Nachází-li se podnik resp. jeho IT v onom ideálním stadiu “zelené louky”, kdy je možné jednotlivé podnikové činnosti, procesy, informační systémy, služby IT atd. budovat a tvořit od počátku, bez zátěže minulých chyb, špatných rozhodnutí a bez soustavného rizika, že komplex, který se eufemisticky nazývá informačním systémem může každou chvíli 14

Permanentní pořizování nových a nových technologií do informačního systému, který neumožňuje realokaci využívaných prostředků, nebo jejich pružné přeuspořádání v případě nutnosti zavedení nové informatické služby, aplikace apod. (což je ve většině IT organizací spíše pravidlem, než výjimkou) rozhodně nesvědčí o dobré práci Enterprise architekta a architektonického týmu. 15 V odborné literatuře se často doporučuje, že výsledný návrh služeb či systému IT by měl představovat konsenzus všech zapojených stran, stejně jako by měl představovat kompromis mezi různými požadavky, potřebami či technologickými možnostmi. Osobně se domnívám, že v případě Enterprise architektury přílišná demokracie škodí, a že časté přistupování na kompromisy vede ve výsledku k patvaru, jenž má s fungujícím enterprise systémem pramálo společného. Pozor – ani nejmenším netvrdím, že by se Enterprise architekt neměl zajímat o vstupy a názory členů i nečlenů architektonického týmu, nebo že by je neměl zohledňovat ve výsledné architektonickém návrhu. Naopak! Avšak tvrdím, že Enterprise architekt (a nemyslím tím teď jenom abstraktní roli, ale každou jednotlivou osobu tuto roli zastávající) by měl mít poslední rozhodující slovo (právo veta), neboť je to on, kdo ve finále za výsledný produkt odpovídá. Kolektivní odpovědnost či spíše nezodpovědnost, je to nejhorší, co může Enterprise architekt, resp. vedení podniku, pro své služby, procesy či systémy udělat. 144



zkolabovat; pak je velice jednoduché (a troufnu si tvrdit téměř radostné) ztotožnit se s výše jmenovanými odpovědnostmi. Problém je, že nežijeme v ideálním světě, a že pro mnoho architektů je návrh, budování a provoz systémů a služeb takto od nuly pouze vzdáleným snem, namísto kterého v běžné praxi řeší: jak dostat pod kontrolu (a někdy v budoucnu snad i do souladu s potřebami společnosti) stávající systémy a dílčí architektury, aniž by se tyto při prvním koncepčnějším zásahu zhroutily? jak zajistit prosazení potřebných změn a korekcí již provozovaných systémů a služeb (zejména pak v situaci, kdy náklady na IT dosáhli hranice tolerovatelnosti a náklady na potřebné změny nebudou nejmenší)? jak zajistit, že nutné a mnohdy i poměrně drastické zásahy do architektury systému negativně neovlivní kvalitu poskytovaných služeb, nebo neohrozí samotnou podnikatelskou činnost podniku? kdy je vhodný okamžik takové zásahy provést? kdy (a jak) je vhodné před vedením podniku odhalit reálný stav věcí? jak skloubit a navíc ještě tvůrčím způsobem zpracovat (v krajním případě do podoby hmatatelného produktu) často protichůdné a vzájemně se vyvracející požadavky různých „politických uskupení“ a klik působících v organizaci? atd. Uvážíme-li rozsah povinností a odpovědnosti Enterprise architekta, logicky nás musí napadnout poněkud uštěpačná poznámka/otázka – existují-li vůbec ve skutečném světě takové osoby, které by mohli tuto roli vážně a bez újmy na duševním zdraví zastávat. Osobně se přikláním k názoru že ano (a k tomuto tvrzení mě vede osobní zkušenost s několika takovými jedinci), nicméně dodávám, že jich není mnoho a jsou téměř vyvažováni zlatem. V roce 2005 na mezinárodním symposiu v Cannes pro tyto osoby společnost Gartner použila označení „versatilitisté“, což jsou – dle definice spol. Gartner jedinci, s hlubokými technickými a procesními znalostmi, dále s poměrně rozsáhlou znalostí průmyslového odvětví, ve kterém jejich mateřská společnost působí, s širokým rozhledem, analytickým myšlením, vůdcovskými schopnostmi a výrazným 16 hodnototvorným potenciálem pro podnik . Společnost Gartner dokonce v této souvislosti (a v návaznosti na rostoucí tlak na realizaci hodnoty z investic do IT) predikuje pro rok 2010 a dále výrazný nárůst poptávky právě po takovýchto osobnostech, který se začíná projevovat již i v českém prostředí. V návaznosti na předchozí řádky je možné vyvodit následující závěry a doporučení: 1. s ohledem na rozsah povinností, odpovědností a míru vlivu role Enterprise architekt, by měly společnosti pozicování a obsazení této role věnovat maximální pozornost; nevhodné začlenění role Enterprise architekt v organizační struktuře, stejně jako obsazení této role nesprávnou osobou může mít pro podnik, realizaci jeho obchodní strategie a návratnost investic do IT nedozírné a někdy i fatální následky (zejména pak v dlouhodobé 17 perspektivě) 16

Více na http://www.gartner.com/press_releases/asset_139314_11.html Vzhledem ke značně rozsáhlému časovému rámci, ve kterém Enterprise architektura operuje, se negativní dopady nesprávného pochopení požadavků společnosti na informatické služby a systémy IT, nesprávného architektonického návrhu či výběru 17


145

Jan Tolar

2.

vedle odborných znalostí, jež tvoří nutný předpoklad pro zastávání role Enterprise architekta, by měly společnosti při obsazování této role věnovat zvýšenou pozornost následujícím schopnostem či osobnostním charakteristikám potenciálních kandidátů: analytickým schopnostem schopnosti koncepčního uvažování schopnosti abstraktního myšlení a praktického uvažování komunikačním dovednostem (a to nejen ve smyslu negociačním, ale také ve smyslu prezentačním, tj. Enterprise architekt by měl být schopen nejen vést jednání, ale měl by umět v ne-technické terminologii vysvětlit/popsat technické skutečnosti a naopak) sociální a emoční inteligenci (sebevědomí, empatie, pokora apod.) osobností integritě (očekávat, že vnitřně nestabilní jedinec bude schopen 18 vytvářet stabilní a koherentní produkt či hodnotu je přinejmenším naivní)

řídícím schopnostem (a to nikoliv pouze ve smyslu řízení projektů či týmů, ale také sebe sama) Poznámka 3: V praktickém životě bývá velice obtížné skloubit v jediné osobnosti výše uvedené vlastnosti a schopnosti (jak prohlásil jeden z editorů tohoto článku – Stevů 19 Jobsů je ve světě jako šafránu). Nicméně to neznamená, že by se společnosti neměli pokoušet takové jedince hledat. Navíc – z praktického hlediska je možné, aby např. řízením EA týmu byla pověřena jiná role než EA architekt, zatímco tato se bude soustředit zejména na analyticko-tvůrčí práci apod. Nicméně – i při takovémto rozdělení schopností a odpovědností v EA týmu by mělo být zachováno a respektováno pravidlo, že hlavní slovo při návrhu cílové architektury systémů a služeb IT má architekt, jenž za něj nese i hlavní odpovědnost. 3. v neposlední řadě by společnosti resp. útvary zodpovědné za najímání pracovníků a obsazování konkrétních rolí měly důsledně využívat možnosti referencí, tj. vybírá-li společnost pracovníka na pozici Enterprise architekta, měla by velice pečlivě zkoumat jeho předchozí působení, realizované výstupy a z nich získanou výhodu či hodnotu.20 4. vezme-li v potaz míru odpovědnosti, jež je svázána s rolí Enterprise architekt, pak je nutné, aby tato role – nemá-li to být role pouze formální – byla nevhodných technologií mohou projevit s výrazným časovým zpožděním. Míra takového dopadu pak bývá zpravidla úměrná době, po které se nesprávná rozhodnutí, nepochopení atd. projeví. 18 Více o dané problematice např. (Babiak, Neumann, & Hare, 2010) 19 Zakladatel a CEO společnosti Apple 20 Přidržíme-li se již několikrát zmíněné paralely s architektem – stavařem, pak se podceněním přínosu referencí vystavujeme riziku, že plánovaná budova bude mít sice precizně zpracovaný architektonický návrh, avšak prakticky bude neobyvatelná, neboť daný architekt vybral nevhodné materiály, není schopen dohlížet nad vlastní výstavbou a fatálně podcenil rozpočet, který dovolil pouze postavit pouze stavební buňku, namísto očekávaného patrového rodinného domu. Je smutným faktem, že ačkoliv jsou referenční údaje v profesním CV téměř povinnou položkou, jen velice málo společností s nimi reálně pracuje. 146



vybavena odpovídajícími rozhodovacími a řídícími pravomocemi (viz také poznámka pod čarou 16 v tomto dokumentu) K výše uvedenému je však třeba dodat, že tvorba Enterprise architektury není v drtivé většině případů představením jednoho herce, ale kolektivním dílem v rámci architektonického týmu, který je spolutvůrcem architektury podnikových služeb a systémů IT. Jestliže jsem již zmínil architektonický tým - podívejme se společně, jaké role by měly být v rámci EA týmu zastoupeny, jaké by mělo být jejich zapojení v průběhu návrhu, výstavby, nasazení a provozování služeb a systémů IT, a jaké praktické problémy mohou být spojeny s fungováním či obsazováním konkrétních rolí.

2.3 Architektonický tým – složení, odpovědnosti a zapojení v životním cyklu služeb IT Vyjdeme-li z obecného schéma oblastí/vrstev zahrnutých v rámci Enterprise architektury (viz Obrázek 1 – Hlavní domény Enterprise architektury),

Obrázek 1 – Hlavní domény Enterprise architektury pak je možné uvažovat architektonický tým zhruba v následujícím složení: Enterprise architekt (vedoucí týmu) Byznys analytik Zástupci hlavních útvarů podniku Aplikační architekt Security Manager


Systémový architekt Zástupce projektové kanceláře / Projektový vedoucí Change Manager Technologičtí architekti či správci technologií CIO

147

Jan Tolar

přičemž v případě potřeby mohou být zapojeny další role, jako např. datový analytik, programátor či vedoucí vývojového týmu, interní (nebo i externí) auditor apod. Nicméně aby mohl architektonický tým fungovat efektivně, mělo by se jeho obsazení udržet v rozumných mezích, aby velikost týmu negativně neovlivňovala jeho vlastní činnost a výkonnost. To znamená – je vhodné určit povinné role, které budou tvořit jádro architektonického týmu a role, které budou do činnosti týmu zapojovány dle aktuální potřeby. Pro lepší představu je na níže uvedeném obrázku nastíněno možné zapojení 21 jednotlivých rolí v životním/tvůrčím cyklu Enterprise architektury :

Obrázek 2 – Příkladové zapojení rolí architektonického týmu v rámci životního cyklu EA

21

Pozor: předkládané schéma je pouze příkladové, nikoliv mandatorní. Zapojení jednotlivých rolí se může v praxi značně lišit v závislosti na obsazenosti/dostupnosti jednotlivých rolí v organizaci, komplexnosti či velikosti organizace, předmětu činnosti organizace, komplexnosti informačního systému a celé řadě dalších faktorů. 148



Rozebíráme-li v tomto dokumentu vliv role Enterprise architekt a architektonického týmu na výslednou hodnotu služeb IT, jejichž dodávka je zpravidla řízena dle knihovny ® nejlepších praktik ITIL , měly bychom se zde také zamyslet nad případným zapojením ® typických ITSM/ITIL rolí (např. Service Level Manager, Change Manager atd.) v rámci architektonického týmu. Respektive – měli bychom si položit otázku, zda-li je vůbec takové zapojení možné a přínosné, a to s ohledem na faktickou nekonzistenci mezi ® přístupy Enterprise architektury a ITSM/ITIL k problematice správy služeb IT (i vůči sobě navzájem)? A je vůbec takové zapojení žádoucí? Vezme-li za základ níže uvedené schéma (Obrázek 3 – Možné vazby mezi životními cykly služeb IT a Enterprise architektury), jež popisuje v hrubých rysech možný vztah životního cyklu služeb IT k životnímu cyklu Enterprise architektury, pak můžeme uvažovat ® v rámci architektonického týmu angažmá min. následujících ITSM/ITIL rolí: role odpovědná za řízení úrovně poskytovaných Service Level Manager služeb, negociaci SLA/OLA, ale také za přípravu a správu katalogu služeb IT atd. Configuration Manager

role odpovědná za správu konfigurací, poskytování informací o konfiguraci stávajících služeb, aplikací, systémů atd. v reálném prostředí

Change Manager

role odpovědná za řízení změn, jejich validaci a schvalování, stejně jako za řízení vlastního procesu správy změn

Release Manager

role odpovědná za uvolňování vydání jednotlivých služeb do produkčního provozu, za plánování jednotlivých vydání, jejich testování před nasazením do produkce atd.

Obrázek 3 – Možné vazby mezi životními cykly služeb IT a Enterprise architektury


149

Jan Tolar 22

Přínosy zde navržených rolí pro architektonický tým mohou být následující: Service Level Manager zastoupení této role v rámci architektonického týmu může spíše technokraticky zaměřené Enterprise architektuře poskytnout potřebný praktický vhled na kontinuální zajišťování služeb IT jejich odběratelům, zejména pokud jsou tyto dodávky vázány dohodami o úrovni poskytovaných služeb (úroveň očekávané dostupnosti služeb, úroveň a mechanismy podpory, stejně jako mechanismy objednávání služeb apod.) Configuration Manager

24

architektonickému týmu zprostředkovává cenné informace o faktické (v praxi aplikované) struktuře informačního systému, vzájemných vazbách a vlivech mezi zapojenými komponentami, a zejména v případě plánování změn a zásahů do informačního systému pomáhá identifikovat jejich 23 potenciální dopad

Change Manager

do architektonického týmu poskytuje jak informace o aktuálním plánu změn, tak informace o průběžné evoluci služeb a systémů IT vlivem aplikovaných změn; dalším zdrojem cenných informací jsou pak přehledy chybovosti jednotlivých implementovaných změn či doporučení v oblasti plánování a testování změn

Release Manager

jestliže služby, systémy a řešení vzešlé z procesu Enterprise architektury mají poskytovat praktickou hodnotu, je nutné – vedle kvality jejich výsledného zpracování – také zajistit správné načasování a souslednost jejich nasazování/uvádění do provozu, což je právě doména role Release Manager; v rámci architektonického týmu může tato role sdílet kalendář vydání (release calendar) jednotlivých služeb, aplikací a systémů, a v kooperaci s ostatními členy týmu zajistit, že vytvořené služby a systémy jsou nasazovány v posloupnosti definované architektonickým návrhem a plánem nasazení,

22

Jistě bychom mohli doplnit další ITSM/ITIL role (např. Product manager, Business Relationship Manager, Catalog manager, Capacity Manager, Availability Manager apod.), avšak jejich zahrnutí by vyžadovalo poměrně detailní vysvětlení účelu a přínosu jejich zapojení, jež je bohužel nad rámec tohoto článku. 23 CMDB, stejně jako EA systémy by měly být součástí širšího systémového celku (CMS – Configuration Management System, příp. SKSM – Service Knowledge Management System) poskytujícího potřebné informace napříč celý životním cyklem služeb IT a informačních systémů organizace, tj. od prvotní identifikace potřeb, cílů či požadavků na služby, přes vlastní návrh a tvorbu služeb, až po jejich reálné nasazení, provoz, hodnocení a plánování jejich dalšího vývoje. 24 Relativně kolizní role, jejíž zapojení může být poměrně problematické, což je dáno poměrně častou nejednoznačností v chápání termínů změna, požadavek, poptávka v konkrétních organizacích a s tím spojenou nevyhraněností této role, kdy se neví, za jaké změny je či není tato odpovědná (důsledkem čehož je poměrně častá kolize mezi PMO a rolí Change Manager resp. procesem Change Management, demonstrující se zejména v míře odpovědnosti resp. nezodpovědnosti za konkrétní typy změn) 150



ale i s ohledem praktická omezení vyplývající s charakteru nasazovaných komponent (např. není vhodné nasazovat aplikační systém, není-li pro něj vybudována odpovídající nosná infrastruktura apod.) Ačkoliv se nám může jevit angažmá zde uváděných rolí v architektonickém týmu jako logické a s ohledem na výsledek (tj. efektivitu a hodnotu služeb IT) nadmíru přínosné, je v praxi poměrně ojedinělé. Možnou příčinu lze spatřovat v již naznačené inkonzistenci ® disciplín ITSM (potažmo jejího metodického rámce ITIL ) a Enterprise architecture (resp. jednotlivých EA rámců), jež pramení z místy odlišného přístupu k dodávce služeb IT, ale ® do jisté míry i z vyhrazování se jedné disciplíny vůči druhé. ITSM/ITIL vnímá v některých aspektech Enterprise architekturu jako svou podmnožinu, v jiných pak jako disciplínu komplementární; podobně je tomu naopak, v hlavních rámcích EA poměrně důsledně dodržujících hierarchický postup od obecného ke konkrétnímu – byť v různých formách – nezbývá pro služby IT mnoho prostoru, a když, tak zpravidla pouze v podobě zapojených procesů či návrhu technologických systémů. Ve výčtu možný důvodů pro nízké zastoupení typických ITSM rolí v architektonických týmech nelze zapomenout na osobní preference či majoritní orientaci v rámci organizace (zcela jistě jste někdy zaslechli, že „firma XY jede podle ITILu, zatímco firma ABC staví na CoBITu a ve firmě W4C ujíždějí na TOGAFu“). Osobně se domnívám, že s ohledem na výslednou hodnotu služeb jsou k sobě obě disciplíny (tj. ITSM a Enterprise architektura) komplementární, a že v kontextu dodávky služeb IT, jakožto výsledného „produktu“ činnosti IT, mají své nezastupitelné místo. ITSM vnáší do dodávky služeb potřebnou praktickou (a chcete-li i sociální) perspektivu. Naproti tomu Enterprise architektura vytváří strukturovaný základ pro návrh, tvorbu a dlouhodobou poskytovatelnost služeb (zejména díky poměrně širokému záběru jdoucímu od byznys procesů, jejich informačních potřeb, přes aplikační logiku tyto informace zprostředkovávající, až po vlastní výběr nosných technologií; a díky komplexnímu podchycení vazeb mezi jednotlivými zapojenými částmi, napříč celou organizací), jehož se mnohdy ITSM nedostává. V této souvislosti je tedy nadmíru vhodné, aby architektonický tým obsahoval i klasické ITSM role, a ve výsledku umožňoval návrh, tvorbu a dodávku služeb IT respektujících jak strategické záměry a cíle organizace, tak technologické podmínky a další vlivy, a potencoval tak dosahování signifikantní hodnoty z investic do IT (ať za tuto hodnotu budeme považovat spokojenost zákazníků/klientů organizace, finanční návratnost, poskytování konkurenční výhody či jen prostou stabilitu a spolehlivost služeb a systémů IT). Důležitým součinitelem je zde opět role Enterprise architekta, který by měl při obsazování architektonického týmu výše uvedené skutečnosti zohledňovat a měl by umět s nimi efektivně pracovat. Zde uvedený stručný rozbor skladby, působnosti a vlivů architektonického týmu nás pak vede k následujícím závěrům: 1. správa a dodávka služeb IT, stejně jako dosahování hodnoty z jejich poskytování/zajišťování, představuje relativně komplexní problematiku, jíž nelze vtěsnat do jediného metodického rámce či disciplíny, ale která by naopak měla stavět na vytváření synergického efektu z využití různých metodických či technologických postupů (v korelaci na reálné prostředí organizace, ve kterém jsou/mají být služby a systémy provozovány, a při zohlednění většiny zásadních vlivů, jež toto provozování determinují)


151

Jan Tolar

2.

3.

4.

®

IT Service Management a jeho metodický rámec ITIL , Enterprise architektura a její rámce, stejně jako další obecně či konkrétně zaměřené disciplíny a metodiky, jsou součástí širšího celku zaměřeného na celkově efektivní využívání informačních technologií, jímž je IT Governance mají-li být v rámci podniku informační technologie efektivně využívány, a má-li být zúročen jejich hodnotový potenciál, pak je nutné, aby skladba architektonického týmu zohledňovala rozmanitost vlivů a disciplín primárně determinujících výslednou kvalitu a hodnotu služeb (ať již se jedná o byznys cíle podniku, jejich správné pochopení a transformace do portfolia služeb, vlastní technologické zázemí pro jejich uskutečňování či o organizačně-sociální vlivy a další faktory), přičemž je možné si dovolit jistou míru flexibility, kdy vybrané role tvoří nosné jádro týmu, a 25 další role jsou využívány nepravidelně dle potřeby Enterprise architekt, jakožto zastřešují a řídící role architektonického týmu, je odpovědný za výběr a angažmá členů architektonického týmu tak, aby tento byl schopen postihnout a odpovídajícím pracovat s výše uváděnými skutečnostmi a faktory.

3. Závěr Dobře navržená a spravovaná architektura služeb a systémů IT výrazným způsobem potencuje a umocňuje dosahování strategických cílů organizace. Někdy je v tomto kontextu Enterprise architektura označována jako tzv. „strategic enabler“, tj. faktor, umožňující realizaci podnikové strategie. Aby však Enterprise architektura mohla být takovýmto klíčovým faktorem, musí zajistit, že využívané/poskytované služby a systémy IT: 1. maximálně odpovídají strategickým záměrům společnosti 2. efektivně a účinně podporují ekonomicky výkonné činnosti podniku, popř. legislativní a regulativní rámce 3. jsou navrženy tak, aby je bylo možné opakovaně využívat a měnit v souladu s měnící se strategií organizace 4. využívají takové technologie, které jsou dlouhodobě využitelné a přizpůsobitelné potřebám organizace 5. jsou podporovány účinnými procesy pro jejich dodávku a správu 6. jsou provozovány s opodstatněnými náklady a s akceptovatelnou mírou rizika 7. jsou navrhovány, vyvíjeny/sestavovány, provozovány, spravovány a řízeny vhodnými jedinci majícími odpovídající znalosti a dovednosti. Klíčovým faktorem ovlivňujícím splnění výše uvedených mandatorních předpokladů jsou role Enterprise architekta a architektonického týmu. Jejich znalost, kreativita/tvůrčí potenciál, praktická zkušenost a zodpovědnost za výsledný produkt, jež se nemohou demonstrovat pouze v technických oblastech EA, ale ve všech doménách Enterprise architekturou dotčených. Jinými slovy: Enterprise architekt či architektonický tým není zodpovědný pouze za vlastní technický návrh služeb a systémů, ale také za věcně správnou transformaci podnikových cílů do cílů IT, za procesní zázemí dodávky služeb a

25

Nicméně i tyto role by měly být trvale informovány o činnosti architektonického týmu, plánovaných aktivitách, změnách atd. 152



provozu systémů či za specifikaci vhodných obslužných rolí (včetně jejich znalostních a – vyžaduje-li to situaci – i osobnostních předpokladů). V této souvislosti, jak již bylo popsáno výše, by ze strany společností měla být obsazení role Enterprise architekta (stejně jako umístění této role v org. struktuře) a skladbě architektonického týmu věnována maximální pozornost. A to jak po stránce technických kompetencí, tak po stránce osobnostní. Současně by společnosti měly akceptovat fakt, že Enterprise architektura (nikoliv jako disciplína, ale jako strukturovaný návrh popisující vzájemné fungování IT a byznysu) ovlivní využívání informačních technologií v podniku na mnoho let dopředu, stejně jako cenu, jíž za to zaplatí a hodnotu, kterou v poměru k této ceně získá. A že podcenění vlivu Enterprise architekta, stejně jako architektonického týmu, může být v této spojitosti fatální. Na závěr mi dovolte zopakovat motto uvedené v úvodu tohoto článku, jež ve zhuštěné podobě postihuje důležitost a vliv Enterprise architekta (a potažmo architektonického týmu) pro dosažení hodnoty ze služeb a systémů IT: Většina firem má v současné době naprosto srovnatelné vybavení a technologie, takže klíčovou konkurenční výhodou, kterou mohou získat, jsou co nejlepší lidé. Nejlepšími lidmi se rozumí ti, kteří se nejlépe hodí na konkrétní procesy.

4. Literatura: VOŘÍŠEK, JIŘÍ a kolektiv: Principy a modely řízení podnikové informatiky. Praha: Oeconomica, 2008. Europian Council of Spatial Planners. Nová aténská charta (1998 - původní verze, CZ). 1998. http://www.urbanismus.cz/asociace-pro-urbanismus-a-uzemniplanovani/auup.php?lg=cz&sel=content&cntID=46&menuID=30. KOVÁŘ, PETR: Historie výpočetní techniky v Československu. 2011. http://www.historiepocitacu.cz/. CARR, NICHOLAS G.: „IT Doesn't Matter.“ Harvard Business Review, 2003: 5-12. BABIAK, PAUL, CRAIG S. NEUMANN, ROBERT D. HARE: „Corporate Psychopathy: Talking the Walk.“ Behavioral Sciences and the Law 28 (2010): 174-193. Office of Government Commerce: ITILv3 - Service strategy. London: The Stationery Office, 2007. ROSEN, MICHAEL: Ten Key Skills Architects Must Have to Deliver Value. 2008. http://www.technologytransfer.eu/article/78/2009/9/Ten_Things_an_Architect_Does_t o_Add_Value.html. TOLAR, JAN: „IT Service Management a ITIL.“ Nástroje IT manažera. Praha: Forum, 2011. TOMSKY, ANDREW: „Firemní architektura a metodika TOGAF.“ IT SYSTEMS, 11 2009.


153

Role architekta a její vliv na výslednou hodnotu služeb IT

Recommend Documents