Architektura v podnikové informatice 1

Architektura v podnikové informatice1 Alena Buchalcevová, Libor Gála Katedra informačních technologií Vysoká škola ekonomická v Praze {buchalc|gala}@vse.cz Abstrakt: Pokud má IS/ICT plně podporovat podnikové procesy a realizovat jejich potenciál, je třeba při jeho budování respektovat řadu hledisek a vazeb. Architektura systému je právě tím prostředkem, který tyto vztahy umožňuje zachytit a jasně popsat pro různé role jak na straně IT, tak na straně byznysu. Při jejím budování je potřeba formulovat její obsah a také proces řízení a prosazovaní v organizaci. Příspěvek se v tomto smyslu zaměřuje na pojetí architektury, které se označuje pojmem Enterprise Architecture. Klíčová slova: architektura, Enterprise Architecture, IS/ICT Abstract If we want IS/ICT to fully support business processes in their highest potential, many views and relations must be respected. System architecture is the tool that enables us to describe these relations. When we build the architecture we must formulate the content, management and enforcement process in the organization. This paper focuses on the concept of Enterprise Architecture. Keywords: architecture, Enterprise Architecture, IS/ICT

1. Úvod V současném vysoce konkurenčním prostředí představuje IS/ICT rozhodující faktor, který ovlivňuje úspěšnost organizací. Pokud má IS/ICT plně podporovat podnikové procesy a realizovat jejich potenciál, je třeba při jeho budování respektovat řadu hledisek a vazeb. Architektura systému je právě tím prostředkem, který tyto vztahy umožňuje zachytit a jasně popsat pro různé role jak na straně IT, tak na straně byznysu. Odrazem současného zájmu o architekturu systému je vznik a používání jazyků pro popis architektury, architektonických metod, rámců, modelů, vzorů a technik pro analýzu a posouzení architektur. Příspěvek ukazuje, jak je princip architektur aplikován v podnikové informatice s tím, že se zaměřuje na pojetí označované jako Enterprise Architecture.

2. Architektura – standardizace O významu architektury v životním cyklu systému panuje v odborné komunitě shoda, ale dlouho neexistovala shoda na přesné definici pojmu architektura systému a na tom, jak by měla být architektura popsána. Proto byla v roce 2000 přijata organizací IEEE norma, která formuluje doporučené postupy pro popis

1

Příspěvek vznikl v rámci řešení grantu GAČR 201/08/0663 - „Inovace informačních systémů podporující konkurenceschopnost podniků“

SYSTÉMOVÁ INTEGRACE 3/2008

7

Alena Buchalcevová, Libor Gála 2

architektury systému IEEE-Std-1471-2000 . Tato norma byla převzata organizací 3 ISO a stala se základem normy ISO/IEC 42010:2007 . Cílem normy je standardizovat prvky a praktiky popisu architektury, a tak usnadnit vyjádření, komunikaci a prověření architektur a zvýšit jejich kvalitu. V následujícím textu jsou vysvětleny základní principy architektury a jejího popisu podle této normy. Obrázek 1 znázorňuje architekturu v kontextu systému, který je ovlivňován prostředím, naplňuje určité poslání formulované zainteresovanými. Systém je v normě definován jako soubor komponent účelově uspořádaných 4 k dosažení určitého cíle nebo skupiny cílů. Jedná se buď o obecný systém anebo 5 softwarově intenzivní systém . Prostředí představuje kontext, který určuje nastavení a okolnosti vývojových, provozních, politických, regulačních, sociálních a jiných kritických vlivů na systém. Prostředí ovlivňuje systém a systém působí na prostředí. V rámci prostředí existují zainteresovaní, tedy strany (jednotlivci, týmy nebo organizace), které mají zájem na systému nebo jsou ve vztahu k systému. Příkladem zainteresovaných jsou: zákazník, uživatel, vývojář, manažer firmy, poskytovatel služby, dodavatel a další. 6 Systém existuje, aby plnil poslání .

Obrázek 1 Konceptuální model architektury, dle [5]

2

IEEE-Std-1471-2000 Recommended Practice for Architectural Description of Software-Intensive Systems 3 ISO/IEC 42010:2007 Systems and software engineering — Recommended practice for architectural description of software-intensive systems 4 systém vytvořený a používaný lidmi, který poskytuje produkt nebo službu v definovaném prostředí pro uspokojení potřeb uživatelů a ostatních zainteresovaných, zahrnuje hardware, software, data, lidi, procesy a procedury, zařízení, materiál a přírodní zdroje [6] 5 systém, kde software hraje dominantní nebo převažující roli [7] 6 Takové použití či fungování systému, které vede k naplnění jeho cílů. 8


Architektura v podnikové informatice

Architektura je „fundamentální uspořádání systému, které tvoří komponenty a vztahy mezi nimi, včetně vztahu k prostředí, a principy, které řídí jeho návrh a rozvoj.“ [5] Architektura systému je dokumentována pomocí popisu architektury. Norma rozlišuje mezi architekturou systému (konceptem) a popisem architektury (konkrétní informační artefakty). Obrázek 2 zachycuje konceptuální model popisu architektury. Popis architektury je složen z částí, které se nazývají architektonické pohledy. Každý pohled (View) adresuje určité zájmy zainteresovaných na vlastnostech systému. Architektonický pohled představuje dílčí architekturu, která respektuje určité architektonické hledisko. Norma nepracuje s termíny jako je „byznys architektura“, „technologická architektura“, které se často v praxi používají, ale v tomto smyslu používá pojem „byznys pohled“, „technologický pohled“. Pohled je reprezentován modely (Model). To, které modely jsou součástí pohledu, je definováno pomocí hlediska (Viewpoint). Architektonické hledisko specifikuje konvence pro vytvoření a použití pohledu. Můžeme je chápat jako vzor nebo šablonu, na základě které vytvoříme pohled. Hledisko definuje účel pohledu, pro koho je pohled určen, techniky pro jeho vytvoření a analýzu. Hlediska mohou být předem definována a uložena v knihovně. Pro popis architektury formulujeme zdůvodnění (Rationale).

Obrázek 2 Konceptuální model popisu architektury, dle [5] Potřebujeme-li popsat architekturu, postupujeme následovně. Nejprve definujeme zainteresované a jejich zájmy. Tím jsou určeny pohledy. Pro každý pohled buď v knihovně vyhledáme hledisko anebo jej nadefinujeme. Vytvoříme modely, které tvoří pohled. Souhrn pohledů pak tvoří popis architektury, který opatříme SYSTÉMOVÁ INTEGRACE 3/2008

9

Alena Buchalcevová, Libor Gála

identifikací a formulujeme účel a zdůvodnění. Norma definuje následující strukturu popisu architektury: 1. Identifikace dokumentu – datum vytvoření, kdo vytvořil, historie změn, rozsah, slovník, reference. 2. Účel popisu architektury. 3. Identifikace zainteresovaných – dle kategorií: uživatelé, vlastnící, vývojáři, provozní pracovníci a další. 4. Identifikace zájmů - dle kategorií: poslání systému, vhodnost systému pro plnění poslání, proveditelnost, rizika vývoje systému, udržovatelnost a další. 5. výběr architektonických hledisek – u každého hlediska se uvádí: název hlediska, zainteresovaní, zájmy, jazyky, modelovací techniky, analytické metody, popis pravidel a omezení, zdroje, předdefinovaná hlediska. 6. Architektonické pohledy: modely, konzistence mezi pohledy, pravidla korespondence. 7. Zdůvodnění rozhodnutí: pravidla, heuristiky.

3. Architektura v podnikové informatice Obsah a účel architektury v podnikové informatice se postupně vyvíjel v důsledku rozšiřujících se požadavků na informatiku organizace a dopadů změn prostředí, ve kterém se organizace nachází. V důsledku změn pohledu na informatiku v organizaci lze identifikovat několik etap rozvoje architektury [1]. Z počátku byla středem zájmu technologická architektura, tj. uspořádání technologií do vhodného systému zpracování dat. To umožnilo identifikovat potenciální místa snižování nákladů na informatiku a zvyšovat výkonnost použitých technologií. V další etapě se architektura rozšiřuje o další ICT zdroje – aplikace a informace pro podporu byznysu. Používá se pojem IS/ICT architektura, který spojuje technologickou, aplikační a informační architekturu. Architektura je v této etapě prostředkem pro zkvalitnění informačního systému a jeho řízení. Aktuální etapa je charakteristická důrazem na sladění byznysu a IS/ICT (angl. Business – IT Alignment) [4] a požadavky, aby IS/ICT vytvářelo nové byznys příležitosti. To vede k tomu, že architektura IS/ICT je propojena s byznys 7 architekturou. V tomto významu se pak používá pojem Enterprise Architecture . Druhým faktorem, který posiluje úlohu architektury při řízení podnikové informatiky, jsou významné změny v prostředí, zejména: •

kvalitativní změny v ICT, které je třeba vhodně prezentovat byznysu: o

nástup distribuovaných systémů a distribuovaného zpracování dat (tehdy např. vzniká tzv. Zachmanův rámec, Joint Technical Architecture, ISO/IEC 10746-3:1996 anebo ISO/IEC 14252),

7

pojem Enterprise Architecture ponecháváme v angličtině, neboť není ustálen žádný vhodný český termín. Někteří používají pojem podniková architektura, ale dle našeho názoru tento pojem evokuje představu, že jde o architekturu podniku a ne jen z pohledu IS/ICT. 10



o o o •

nástup objektově-orientovaného paradigmatu (architektura 4+1 v metodice RUP8, Rozanski and Woods Viewpoint Groups, SA-IA9, nástup XML10 a konceptu služeb reprezentované SOA11 přijetí standardů IEEE-Std-1471-2000 a ISO/IEC 42010:2007;

turbulence a významné změny v ekonomice (např. globalizace, časté fúze a akvizice). V této situaci potřebujeme nástroj, který nám umožní pružně reagovat na tyto vlivy a za přijatelných podmínek změny promítat i do IS/ICT. Tak vznikají například rámce IAF12, E2AF13 a další;

•

nové legislativní požadavky, jako např. americké zákony Clinger-Cohen Act, Sarbanes-Oxley Act, ale také integrační procesy v rámci Evropské unie a e-Government plány států EU. Zde se jedná třeba o rámce FEAF14, TOGAF15, CIMOSA16, eGIF17 a další. S vývojem obsahu architektury v podnikové informatice se mění i definice tohoto pojmu. V současné době se můžeme setkat s řadou definic, například: •

architektura v podnikové informatice je formulována jako analogie především k oblasti stavitelství a je přirovnána k územnímu plánu a územnímu plánování [17],

•

architektura v podnikové informatice představuje informační aktiva, kterými je charakterizována mise organizace, nezbytné informace a informační technologie umožňující misi naplnit včetně postupů jak implementovat nové technologie v reakci na změnu mise [3],

•

architektura v podnikové informatice je holistickým vyjádřením klíčových strategií organizace (byznys, informační, aplikační a technologická strategie), které mají dopad na obchodní funkce a procesy. Orientuje se na takový pohled na byznys procesy a informatické zdroje, který umožňuje řídit realizaci byznys procesů (Meta Group v [9]),

•

architektura v podnikové informatice je prostředek porozumění prvkům, které tvoří podnik a vztahům mezi nimi [11],

•

architektura v podnikové informatice představuje takové logické uspořádání byznys procesů a ICT infrastruktury, které odráží potřeby organizace [12]. Výše uvedené definice vyjadřují jak obsah pojmu, tak také mechanismus, kterým lze tento obsah naplnit. V souvislosti s normou ISO/IEC 42010 formulujeme definici 18 architektury v podnikové informatice následovně:

8

Rational Unified Process Software architecture in industrial applications 10 eXtensible Markup Language 11 Servisně orientovaná architektura 12 Capgemini‘s Integrated Architecture Framework 13 Extended Enterprise Architecture Framework 14 Federal Enterprise Architecture Framework 15 The Open Group Architecture Framework 16 Computer Integrated Manufacturing Open System Architecture 17 e-Government Interoperability Framework 18 odpovídá anglickému termínu Enterprise Architecture 9


11


Architektura v podnikové informatice (Enterprise Architecture - EA) je 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.

4. Architektonické rámce Navrhnout, popsat a používat architekturu a zároveň podle ní řídit podnikovou informatiku je velmi obtížné bez vhodného nástroje. Takovým nástrojem jsou architektonické rámce. Architektonický rámec je množina zájmů, zainteresovaných, předefinovaných hledisek a pravidel definujících vazby hledisek, které byly definovány pro popis architektury ve specifické oblasti [5]. Architektonické rámce můžeme rozdělit na klasifikační, procesní a obsahové [18]. Klasifikační rámce poskytují návod, jak složitý systém správně rozdělit do jednotlivých pohledů, jaké aspekty (domény) v daném pohledu sledovat a jaké modely využít. Jsou typicky prezentovány ve formě matice, kde řádky reprezentují pohledy a sloupce domény neboli aspekte, které bychom v daném pohledu měli řešit. Prvek v matici je charakterizován vhodným modelem, který zachycuje z daného pohledu konkrétní aspekt řešení. Do této kategorie rámců patří třeba Zachmanův rámec, E2AF, IAF apod. Některé rámce jsou založeny na stromovém konceptu jako například Gartner EA Framework Model. Zatímco u maticových rámců je úroveň podrobnosti popisu ve všech pohledech stejná, stromové rámce jsou koncipovány tak, že byznys je reprezentován samostatnou byznys architekturou a rámec se primárně zaměřuje na vyjádření vztahu mezi touto byznys architekturou a IS/ICT. Tento vztah je reprezentován různými pohledy a aspekty podpory byznysu pomocí IS/ICT. Obrázek 3 schematicky zachycuje principy klasifikačních rámců.

Pohledy

Domény

Modely

Maticový koncept rámce (např. Zachman)

Stromový koncept rámce (např. Gartner EA Framework Model [9])

Obrázek 3 Principy klasifikačních rámců Procesní rámce definují postupy používané při řízení životního cyklu EA. Do této 19 kategorie můžeme zařadit například TOGAF a jeho referenční proces ADM , FEAF apod. Procesní rámce samozřejmě obsahují i definici klíčových pohledů, ale 19

Architecture Development Method

12



hlavní důraz je kladen na proces zvládnutí celého životního cyklu EA. Obrázek 4 ukazuje aktivity v procesu formulovaném v rámci TOGAF. Příprava Sestavení rámce a principů A. Vize architektury H. Řízení změn architektury

G. Zavedení governance

B. Byznys architektura

C. Architektura IS

Požadavky

D. Technologická architektura

F. Plánování migrace E. Příležitosti a řešení

Obrázek 4 Ukázka procesu (zdroj [15]) Obsahové rámce jsou spojeny s nějakým oborem či odvětvím a obsahově doplňují 20 rámce předchozích kategorií. Příkladem je rámec IAA , využívaný v pojišťovnictví, 21 NGOSS , orientovaný na telekomunikace a již třeba zmiňovaný eGIF, zaměřený na eGovernment a další. Architektonický rámec EA by měl mít následující vlastnosti [10]: •

odpovídá normě ISO/IEC 42010, tj. měl by zahrnovat množinu modelů a modelovacích technik, kterými vyjadřujeme jednotlivé pohledy,

•

mát definovaný metamodel,

•

zahrnuje procedurální model, který specifikuje, jak jsou jednotlivé modely vytvářeny a jak mají být udržovány vazby mezi modely, aby byla v rámci celého konceptu udržena konzistence,

•

obsahuje model rolí a specifikaci dokumentů.

Z výše uvedeného vyplývá, že správa a publikace rámců i řízení EA konkrétního systému není možné bez podpory softwarových nástrojů. Na trhu existuje celá řada takových nástrojů. K nejvýznamnějším patří nástroje společností IBM/Telelogic (System Architect Suite), IDS Scheer (ARIS), MEGA (Mega Modelling Suite), alfabet (planningIT), Troux Technologies (Troux's Strategic IT Planning solution) apod. Nástroje obvykle podporují celou řadu rámců a umožňují, aby v přípravné fázi mohl být sestaven takový architektonický rámec, který vyhovuje požadavkům organizace. Zároveň jsou tyto nástroje často integrovány do prostředků řízení IS/ICT např. jsou propojeny s nástroji pro návrh a implementaci IS/ICT a také prostředky hodnocení výkonnosti IS/ICT. 20 21

Insurance Application Architecture New Generation Operations Systems and Software


13


5. Role architekta Role architekta se do informatiky přenesla ze stavitelství, kde za architekta „je považována osoba, která je mistrem v ovládání všech funkčních, strukturálních a estetických metod výstavby a konstrukce a taktéž dozorující osobou ve stavitelském procesu.“ [13] Architekta lze charakterizovat jako experta, stratéga, politika a vůdce [1] Uvedené vlastnosti jsou naplňovány řadou dovedností a znalostí. Ke klíčovým pak řadíme: •

znalost byznysu organizace a jeho fungování, porozumění produktům a službám, které organizace nabízí, znalost slabých a silných stránek organizace, podnikové strategie včetně jejího odůvodnění. Znalost prostředí byznysu organizace, tj. strukturu odvětví, potřeb uživatelů, konkurence, dodavatelského řetězce apod. Znalost aktuálních i budoucích možností podnikového IS/ICT i trendů v IS/ICT a schopnost identifikovat jejich příležitosti i rizika;

•

schopnost v komponentách vždy vidět celek a na celek i jeho části nahlížet z různých hledisek, schopnost modelovat realitu a znalost modelovacích technik;

•

schopnost orientovat se v lidských vztazích v organizaci, umění identifikovat klíčové hráče v rozhodovacích procesech, schopnost objevovat „skryté podnikové agendy“, které mohou ovlivnit architekturu. Má znalost podnikové kultury a klíčových hodnot, na kterých je organizace založena;

•

schopnost sebepoznání a schopnost prosazení se, schopnost přesvědčit pracovníky, aby se identifikovali s vizí, misí, strategií i taktikou organizace. Je mu vlastní komunikační umění, ať již různou formou či k různému auditoriu. Zodpovědnost a úlohu architekta lze pak charakterizovat následovně: •

zodpovídá za formulaci architektonických principů, stylů a standardů, jejich naplňování a dodržování v rámci organizace. Je odpovědný za formulaci architektury, její odůvodnění a prosazení. Sleduje vývoj ICT prostředků, metod řízení (informatiky i byznysu) a formuluje jejich možnosti v inovacích systému a udržuje soulad mezi byznysem a informatikou;

•

podílí se na přípravě podnikové strategie a zodpovídá za identifikaci možných rizik a příležitostí související především se schopnostmi technologií, které by ji měly podpořit. Účastní se rozhodovacích procesů, které souvisí s investicemi a také rozhodováním o akvizicích a fúzích. Zodpovídá za identifikaci těch témat, které se prolínají skrze vícero strategických cílů a mohou přinést nový (synergický) efekt. Zajišťuje také, aby strategické cíle byly správně transformovány do cílů informatiky a aby jim technologicky orientovaná komunita dobře rozuměla;

•

vytváří vhodnou síť partnerství a spolupráce umožňující dosáhnout definovaných výsledků. Zodpovídá za to, aby došlo ke sladění zájmů různých skupin v organizaci a byly potlačeny partikulární a osobní zájmy jednotlivců. Zajišťuje, aby „politické“ změny v organizaci byly adoptovány obratně a hladce. Úroveň zodpovědnosti, dovedností i znalostí architekta závisí na tom, do jaké úrovně rozhodovacího procesu je zařazen. Jiné budou pro hlavního architekta 14



(podnikový architekt, Enterprise Architect), jiné pro architekta zodpovědného za konkrétní pohled (byznys architekt, informační architekt, architekt technologické infrastruktury, architekt řešení) a jiné pro architekta aplikace či aplikačního systému

6. Popis a řízení Enterprise Architecture Na základě analýzy rámců [14] a výkladu normy ISO/IEC 42010 můžeme definovat popis EA a proces jejího řízení. Popis EA zahrnuje architekturu aktuálního stavu systému, architekturu cílové stavu systému, která odpovídá formulované misi organizace, a plán transformace z aktuálního do cílového stavu. EA je v závislosti na použitém rámci dokumentována řadou pohledů. Mezi typické pohledy patří: •

byznys pohled vyjadřuje, jakým způsobem (jakými byznys procesy a službami) je/bude mise organizace naplněna;

•

aplikační pohled vyjadřuje, jakými aplikacemi, aplikačními systémy a službami disponujeme a musíme disponovat, a jak jsou a mají být uspořádány, abychom podpořili procesy, a tak naplnili definovanou misi. V řadě případů je tento pohled označován pojmem „řešení“, protože jím charakterizujeme nějaké konkrétní aplikační řešení. V současné době se v rámci tohoto pohledu dostávají do popředí služby a to v souvislosti s tím, jak se prosazuje architektura orientovaná na služby (SOA);

•

informační/datový pohled představuje uspořádání informačních aktiv, kterými musíme disponovat, abychom misi naplnili;

•

technologický pohled představuje uspořádání technologické infrastruktury, které vyhovuje potřebám informačního systému. Je třeba si uvědomit, že pohledy se zaměřují stále na tentýž systém – podnik a že pohledem si „pouze zvýrazňujeme“ vybranou část tohoto systému. Protože tato část je zpravidla subsystémem, tj. tvoří vlastní systém (např. systém byznys služeb a byznys procesů), pak se často místo pojmu pohled používá opět pojem architektura (např. byznys architektura). Mezi pohledy existuje celá řada vazeb, které jsou zachyceny v metamodelu. Jako příklad uveďme: •

byznys architektura ovlivňuje konkrétní aplikační řešení a naopak, aplikační architektura nabízí nové možnosti podpory byznys procesů;

•

byznys architektura formuluje požadavky na uspořádání a dostupnost dat, informací a znalostí, které jsou předmětem informační/datové architektury a naopak například schopnost zachytit historická data umožňuje byznysu lépe vyhodnocovat stav trhu;

•

informační architektura formuluje požadavky na technologie, například typ úložiště. Obsahová náplň systému, jehož architekturu formulujeme, je vymezena podnikovou strategií, byznys požadavky a prostředím. Totéž je i vstupem při modelování a popisu architektury. Prostředí ovlivňuje jak vlastní byznys, tak také použité ICT a to v pozitivním smyslu, protože vytváří nové příležitosti (např. webové služby umožní komunikaci heterogenních technologií, která by jinak nebyla možná), ale i v negativním slova smyslu, tj. vytváří bariéry (např. legislativa státu může omezit nabídku služeb po internetu). Obrázek 5 znázorňuje výše uvedené pohledy (architektury) v rámci EA. SYSTÉMOVÁ INTEGRACE 3/2008

15


Enterprise architecture Byznys architektura Aplikační architektura

Informační architektura

Technologická architektura

Obrázek 5 Typické pohledy v EA Proces řízení EA je zobecněním procesů uváděných v jednotlivých rámcích a obsahuje následující klíčové aktivity (viz Obrázek 6): •

získání podpory vedení,

•

definování rozsahu EA a volba rámce,

•

návrh a popis EA,

•

správa a prosazování EA a řízení změn.

Získání podpory vedení

Definování rozsahu EA a volba rámce

Návrh a popis EA

Správa a prosazování EA a řízení změn

Obrázek 6 Proces řízení podnikové architektury Má-li EA sloužit k efektivnímu řízení vztahu mezi byznysem a jeho informačním systémem, je nezbytné, aby manažer informatiky získal podporu vedení pro principy EA. Principy jsou formulovány podnikovým architektem (viz dále), vedoucím informatiky a klíčovými zainteresovanými a jsou doplněny o politiky a procedury, kterými principy v organizaci implementujeme. Principy obsahují minimálně pravidla definující pozici EA v systému řízení organizace a pravidla užití a nasazení ICT zdrojů. Ucelené množiny principů jsou typicky součástí dostupných rámců EA, např. TOGAF [16], FEAF [2]. Při objasňování významu EA a prosazování principů EA se lze opřít o následující příklady přínosů: •

16

lepší řízení kvality a vyšší výkonnost. Tím, že se snižuje rozmanitost komponent systému, je vyšší úroveň jejich standardizace, zvyšuje se datová úplnost, zlepšuje se kvalita procesů plánování rozvoje systému a minimalizují se rizika spojená s jednotlivými projekty;



•

efektivnější využívání finančních prostředků. Snižují se náklady na zajištění provozu a rozvoje systému a realizují se úspory při nákupu jednotlivých komponent systému;

•

systém je pružnější a agilnější, tj. je zajištěno, že nové požadavky byznysu včetně požadavků na změny budou zaváděny rychleji. V rámci definování rozsahu EA a volby rámce je nutné realizovat minimálně následující činností: •

ustavení týmu zodpovědného za EA,

•

identifikace zainteresovaných a jejich zájmů,

•

stanovení rozsahu EA,

• sestavení vhodného rámce a jeho podpory. Po prosazení konceptu EA u vedení je nutné ustavit vhodný pracovní architektonický tým, který bude zodpovědný za sestavování, udržování a prosazování EA. Činnost zahrnuje sestavení vlastního týmu, jeho začlenění do organizační a řídící struktury organizace a přiřazení vhodných kompetencí a pravomocí. Vedoucím architektonického týmu je podnikový architekt. Tým pak zahrnuje: •

architekty zodpovědné za naplnění formulovaných pohledů, tj. v týmu je zastoupen byznys architekt, informační architekt, aplikační architekt (architekt řešení) a architekt technologické infrastruktury. Často je tým doplněn o osobu, která zodpovídá za naplňování a respektování principů bezpečnosti (bezpečnostní architekt);

•

technika záznamů, který zodpovídá za to, aby všechny dokumenty a směrnice spojené s EA byly přehledné, použitelné a dostupné;

•

dozor kvality, který zajišťuje, aby formulované standardy byly prosazovány ve všech fázích životního cyklu EA. Pracovní tým je typicky podřízen manažerovi IS/ICT (CIO). Setkat se také můžeme se situací, kdy podnikový architekt a byznys architekti jsou podřízeni CEO a ostatní spadají do podřízenosti CIO. Tato druhá varianta pak zvyšuje požadavky na řízení pracovního týmu, může však vést k lepšímu prosazování EA, neboť podnikový architekt i byznys architekti jsou úžeji spojeni s byznysem. Tým musí být vybaven takovými pravomocemi, aby byl schopen prosazovat EA a aby byl schopen zajistit, že průběžné požadavky byznysu budou v souladu s navrženou EA. Další činnosti směřují k sestavení vhodného rámce. Pracovní tým na základě analýzy podnikové strategie identifikuje množinu zainteresovaných, jejich zájmy, klíčové standardy a omezení plynoucí z okolního prostředí. Množinu zainteresovaných tvoří uživatelé a řešitelé: •

mezi uživatele se řadí: o vrcholové vedení, které lze chápat jako pořizovatele systému, ale také vlastníci organizace a o koncoví uživatelé, mezi které vedle zaměstnanců organizace typicky zahrnujeme obchodní partnery, zákazníky a veřejnost.


17


•

skupinu řešitelů tvoří vlastníci byznys procesů, analytici, architekti, vývojáři, implementátoři, manažer IS/ICT, správci, konzultanti, dodavatelé komponent systému, poskytovatelé ICT služeb apod. V další etapě se stanoví rozsah (scope) EA. EA lze aplikovat buď na celou organizaci, nebo jen na hlavní procesy anebo na část organizace (např. divizi, obchodní jednotku apod.). Poslední činností je sestavení vhodného rámce a jeho informatické podpory. Na základě získaných informací z předchozích činností se kombinací dostupných rámců sestaví vhodný architektonický rámec. Zároveň je implementována vhodná informatická podpora, tj. je vybrán, zaveden a nastaven vhodný nástroj, který bude podporovat využití rámce a bude integrován i s dalšími nástroji, které se používají v řízení podnikové informatiky. Návrh a popis EA typicky zahrnuje následující činnosti: • dokumentaci aktuálního stavu systému (EA současného stavu), • návrh cílové EA a • stanovení plánů transformace. Pokud je EA použita poprvé, pak je nutné nejprve dokumentovat v souladu s principy architektonického rámce aktuální stav systému, tj. popsat sadou předepsaných modelů architekturu současného systému. V dalších cyklech procesu řízení EA se pak již využívá popis EA, který vznikl v předchozích cyklech. Na základě podnikové strategie, byznys požadavků, zájmů zainteresovaných stran a vlivů prostředí je stejnými prostředky, tj. s využitím stejného rámce navržena cílová EA popisující cílový stav systému. Na základě identifikace rozdílů mezi aktuálním stavem a cílovým stavem se sestavují plány transformace systému do cílového stavu. Při formulaci těchto plánů vedle věcných (obsahových) požadavků (priority řešení) hrají velkou roli i finanční možnosti organizace. Často dochází i k modifikaci cílové EA v důsledku nabídky vhodnějších aplikačních a technologických komponent systému. Poslední aktivitou, která však patří z hlediska řízení EA k nejvýznamnějším, je správa a prosazování EA a řízení jejích změn. Cílem je, aby jakékoliv požadavky na IS/ICT byly konfrontovány s navrženou EA, změny byly do EA promítnuty a IS/ICT byl konzistentní s formulovanými cíli byznysu. Obrázek 7schematicky zasazuje EA do procesu řízení. Strategie podniku Řízení podniku KP/IKP Řízení EA

Řízení informatiky

Řízení a koordinace projektů

Řízení provozu

22

Obrázek 7 Pozice EA v procesu řízení 22

KP/IKP – Kapitálové plánování a investiční kontrolní mechanismy

18



7. Závěr Architektura není v informačních systémech nic nového, avšak současná komplexita byznysu i ICT vede k tomu, že se hledají vhodné prostředky, které by vztahy v těchto oblastech efektivně propojily a řídily. Takovým konceptem může být Enterprise Architecture, jejíž obsah pozice a řízení byly v příspěvku charakterizovány. Z popisu procesu řízení EA je zřejmé, že se nejedná o jednoduchou záležitost, ale že její nasazení znamená změny v procesech řízení organizace, především v těch částech, které představují styčné body mezi řízením organizace a řízením IS/ICT. Při úspěšném nasazení EA pak architektura může být jedním z nástrojů řízení inovací informačního systému organizace a zároveň lze jejím prostřednictvím byznysu naznačovat nové příležitosti, které ICT může organizaci přinést. 23

Přehled rámců • CIMOSA (Computer Integrated Manufacturing Open System Architecture) Pohledy: Function, Information, Resource, Organisation Zdroj: Computer Integrated Manufacturing Open System Architecture, http://www.cimosa.de/ •

DoDAF (Department of Defense Architecture Framework) (C4ISR) Pohledy: Operational, Systems, Technical Standards Zdroj: Department of Defense Architecture Framework, http://jitc.fhu.disa.mil/jitc_dri/pdfs/dodaf_v1v2.pdf

•

e-GIF (e-Government Interoperability Framework) Pohledy: Interconnection, Data integration, E-services access, Content management metadata Zdroj: e-Government Interoperability Framework, http://www.govtalk.gov.uk/

•

E2AF (Extended Enterprise Architecture) Pohledy: Business, Information, Information-systems, Technology– infrastructure Zdroj: Schekkerman, J. 2004. Another View at Extended Enterprise Architecture Viewpoints, http://www.enterprise-architecture.info/

•

FEAF (Federal Enterprise Architecture Framework) Pohledy: Data, Application, Technology Zdroj: Federal Enterprise Architecture Framework, http://www.whitehouse.gov/omb/egov/a-1-fea.html

•

GERAM (Generalised Enterprise Reference Architecture and Methodology) Pohledy: Contents (function, information, resource, organisation), Purpose (customer service and product, management and control), Implementation (human implemented tasks, automated tasks (mission support technology,

23

V následující tabulce předkládáme soupis rámců s uvedením zdroje, kde lze o rámci získat další informace. Předem podotýkáme, že soupis není úplný a předmětná oblast bude v rámci projektu GAČR 201/08/0663 dále monitorována. SYSTÉMOVÁ INTEGRACE 3/2008

19


and management and control technology)), Physical Manifestation (software, hardware) Zdroj: Generalised Enterprise Reference Architecture and Methodology, http://www.cit.gu.edu.au/~bernus/taskforce/geram/versions/index.html

20

•

IAA (Insurance Application Architecture) Pohledy: IAA Foundation Model, IAA Information Model, IAA Process and Integration Model, IAA Product Model Zdroj: IBM Insurance Application Architecture, http://www03.ibm.com/industries/financialservices/doc/content/solution/278918103.ht ml

•

IAF (Integrated Architecture Framework) Pohledy: Business, Information, Information-systems, Technologyinfrastructure Zdroj: Capgemini‘s Integrated Architecture Framework, http://www.capgemini.com/services/soa/ent_architecture/iaf/

•

JTA (Joint Technical Architecture) Pohledy: Operational, Systems, Technical Zdroj: Joint Technical Architecture, http://www.acq.osd.mil/osjtf/pdf/jta-volI.pdf

•

MoDAF (Ministry of Defence Architectural Framework) Pohledy: Strategic, Operational, System, Technical Standards, Acquisition Zdroj: UK Ministry of Defence Architectural Framework, http://www.modaf.org.uk/

•

NGOSS (New Generation Operations Systems and Software) Pohledy: Common Communications Infrastructure, Shared Information/Data Model, eTOM Zdroj: New Generation Operations Systems and Software, http://www.tmforum.org/BestPracticesStandards/NGOSS/1911/Home.html

•

OASIS SOA-RA (SOA Reference Model) Pohledy (pouze návrh): Interface, Information, Interaction, Behavior Viewpoint (or Functional), Security, Management Viewpoint (Fault, Quality) Zdroj: Views and Viewpoints, http://wiki.oasis-open.org/soarm/TheArchitecture/ViewsAndViewpoints a OASIS SOA Reference Model TC, http://www.oasis-open.org/committees/tc_home.php?wg_abbrev=soarm

•

RM-ODP (Reference Model for Open Distributed Processing) Pohledy: Enterprise, Information, Computation, Engineering, Technology Zdroj: ITU-T Rec. X.903 | ISO/IEC 10746-3:1996(E) Reference Model for Open Distributed Processing

•

Rozanski and Woods Viewpoint Groups Pohledy: Functional, Information, Concurrency, Development, Deployment, Operational Zdroj: Rozanski, N. and Eoin Woods. Applying Viewpoints and Views to Software Architecture. [online] Dostupné z http://www.viewpoints-and-



perspectives.info/doc/VPandV_WhitePaper.pdf a http://www.viewpointsand-perspectives.info/ •

RUP 4+1 set Pohledy: Logical, Process, Development, Physical Zdroj: Kruchten, P. 1995. Architectural Blueprints—The 4+1 View Model of Software Architecture. IEEE Software, 12(6):42–50, November 1995.

•

SA-IA (Software architecture in industrial applications) Pohledy: Conceptual, Module, Execution, Code Zdroj: Soni, D., Nord, R., Hofmeister, C. 1995. Software architecture in industrial applications. Proceedings of the 17th international conference on Software engineering. Seattle, Washington, United States

•

TEAF (Treasury Enterprise Architecture Framework) Pohledy: Functional, Information, Organisational, Infrasctructure Zdroj: Treasury Enterprise Architecture Framework, http://www.eaframeworks.com/TEAF/teaf.doc

•

TOGAF (The Open Group Architecture Framework) Pohledy: Business Process, Application, Data, Technology Zdroj: The Open Group Architecture Framework, http://www.opengroup.org/togaf/

•

Zachman Framework Pohledy: Data, Function, Network, People, Time, Motivation Zdroj: Zachman, J.A. 1987. A framework for information systems architecture. IBM Systems Journal, VOl. 26, NO 3, 1987

Literatura [1] BREDEMEYER, D. MALAN, R. What It Takes to Be a Great Enterprise Architect. Cutter Consortium, 2004 [cit. 3. červenec 2004] Dostupné na [2] FEAF. Federal Enterprise Architecture Framework. The Chief Information Officers Council, 1999 [cit. 26. duben 2008] Dostupné na http://www.cio.gov/Documents/fedarch1.pdf [3] CHIEF INFORMATION OFFICER COUNCIL. Practical Guide to Federal Enterprise Architecture. General Accounting Office, 2001 [cit. 19. leden 2008] Dostupné na [4] CHAN, Y. E., REICH, B. H. IT alignment: what have we learned? Journal of Information Technology, 2007, Vol. 4, N. 4 [5] ISO/IEC 42010:2007 Systems and software engineering — Recommended practice for architectural description of software-intensive systems. ISO/IEC, 2007 [6] ISO/IEC 15288:2002 Systems engineering -- System life cycle processes. ISO/IEC, 2002 [7] ISO/IEC 12207:2008 Systems and software engineering -- Software life cycle processes. ISO/IEC, 2008 SYSTÉMOVÁ INTEGRACE 3/2008

21


[8] KACZMAREK, J. Clinger-Cohen Outline. Federal Chief Information Officers Council, 200? [cit. 28. srpen 2008] Dostupné na [9] KELTIKANGAS, E. Enterprise Architecture Documentation and Representation. Helsinki University of Technology, 2006 [cit. 18. březen 2008] Dostupné na [10] LEIST, S., ZELLNER, G. Evaluation of Current Architecture Frameworks. SAC '06: Proceedings of the 2006 ACM symposium on Applied computing, Dijon, France: ACM, 2006 [11] RADHAKRISHMAN, R. EA and ITIL - - Implications of ITIL-ITSM Framework & IT Processes for EA Development. Enterprise Architecture Practitioners' Conference. San Diego : Open Group, 2007 [12] ROSS, J, A., WEILL, P., ROBERTSON, D. C. Enterprise Architecture as Strategy: Creating a Foundation for Business Execution. Harvard Business School Press, 2006. ISBN 978-1591398394 [13] SCHEKKERMAN, J. The Enterprise Architect & the Architectural Engineer. Institute For Enterprise Architecture Developments, 200? [cit. 10. prosinec 2007] Dostupné na http://www.enterprisearchitecture.info/Images/Architects%20versus%20Architectural%20Engineers/Archit ects%20versus%20Architectural%20Engineers.htm [14] SCHEKKERMAN, J. How to survive in the jungle of Enterprise Architecture Frameworks. 2.vydání, Victoria, Canada : Trafford Publishing, 2004. ISBN 1-4120-1607-X [15] TOGAF 8.1.1 online. The Open Group Architecture Framenwork Version 8.1.1. The Open Group, 2007 [cit. 11. červen 2008] Dostupné na http://www.opengroup.org/architecture/togaf8/downloads.htm [16] TOGAF 8.1.1 online. Architecture Principles. The Open Group, 2007 [cit. 26. duben 2008] Dostupné na [17] VOŘÍŠEK, J. Architektura IS/ICT. VŠE Praha, 200? [cit. 12. červenec 2008] Dostupné na [18] ZUZÁK, F. Důležité aspekty podnikové architektury. Systems Integration 2008. Praha : VŠE Praha, 2008

22


Architektura v podnikové informatice 1

Recommend Documents