Řízení projektu technologické integrace

Řízení projektu technologické integrace Libor Jirsák Katedra informačních technologií Vysoká škola ekonomická Nám. Winstona Churchilla 3, Praha 3 Email: [email protected]

Abstrakt Rostoucí složitost business požadavků znamená vyšší složitost IT projektů a systémové integrace. Možným účinným nástorojem řízení komplexního IT projektu je použití integračního týmu zodpovědného za koordinaci aktivit jednotlivých projektových týmů, subdodavatelů, IT oddělení a zadavatelů. Integrační tým pomáhá projektovému manažerovi řídit activity vyžadující hlubší znalosti metodiky, architektury a technologií. Využití principů architektury orientované na službách (SOA) při systémové integraci přinese vyšší přidanou hodnotu organizaci v podobě vyšší flexibility obchodních procesů podporovaných ICT. Abstract Increasing complexity of business requirements implies increasing complexity of IT projects and system integration. Comprehensive approach to system integration is managing large-scale IT project using integration team responsible for coordination of activities among individual project teams, IT departments and business submitting departments. Integration team helps project manager to handle activities demanding deep knowledge of architecture, methodology a technologies and thus keep project more under control. Using SOA practices together with system integration brings more flexible business processes supported by ICT. Klíčová slova: servisně orientovaná architektura, projektový management, systémová integrace, podniková architektura, model řízení Keywords: service oriented architecture, project management, system integration, enterprise architecture, management model

1. Úvod V dnešní době jsou obchodní procesy téměř každé firmy značně závislé na informačních technologiích. S rostoucí složitostí obchodních procesů roste složitost IT systémů, především jejich provázanost. Složitější požadavky jako třeba implementace nového produktu (úvěrového, bankovního, pojistného,..) či jeho inovace znamená často komplexní IT projekt zahrnující modifikace několika IT systémů a jejich integraci. Projekty tohoto typu většinou vyžadují náročnou technologickou i manažerskou integraci několika paralelních subprojektů. Možným řešením jak zvládnout efektivně řídit projekt technologické integrace je využití integračního týmu co by kvalifikovaného poradního orgánu projektového manažera. Cílem článku je ukázat integrační tým jako vhodný nástroj pro řízení rozsáhlého 140

SYSTÉMOVÁ INTEGRACE 1/2008

Řízení projektu technologické integrace

integračního projektu ale i jako součást strategie budování architektury orientované na službách. Mezi současnými publikacemi lze nalézt značné množství knih a článků zabývající se budováním podnikové architektury založené na SOA (Service Oriented Srchitecture) či EAI (Enterpise Application Integration). Článek IBM [4] se zabývá důvody a komplexností podnikové integrace aplikací a také poukazuje na průzkum, podle kterého jsou nerozšířenější metodou integrace aplikací proprietární řešení založená na FTP. Velké množství publikací se věnuje postupům a aspektům zavádění SOA v podniku [1],[2]. Další oblastí je projektové řízení reprezentující nejen plánování, řízení lidí a rizik, ale také důraz snižování nákladů pomocí maximálního znovupoužívání existujících IT služeb [5],[7]. Literatura [1],[2],[3],[4] je zároveň metodickým východiskem tohoto článku. Nutné je také zdůraznit že z dostupných článků a internetových diskusí je zřejmé, že problematika integrace aplikací je horkým tématem prakticky všech CIO, které trápí vysoké a neustále rostoucí náklady s integrací spojené. První část článku je věnována popisu metodiky řízení integračního projektu s využitím integračního týmu. Popis vychází ze zkušeností autora, který pracoval jako softwarový architekt v rámci integračního týmu na několika větších projektech v České pojišťovně a Siemens IT Solutions. Myšlenka integračního týmu byla na uvedených projektech prosazena týmem metodiků ze společnosti Unicorn [3], autor se podílel na její praktické realizaci na pozici softwarového architekta integračního týmu na velkých projektech zmíněných zákazníků. V druhé části článku autor rozšiřuje metodiku integračního týmu o prvky architektury orientované na služby (zejména centrální správa služeb a jejich využití na projektech). Cílem rozšíření metodiky je definovat aktivity integračního týmu tak, aby se organizace přibližovala vlastnostem organizace orientované na služby (SOE - Service Oriented Enterprise).

1.1 Východiska a omezení práce Předmětem uvažovaného integračního projektu je modifikace několika existujících a vytvoření nových aplikací včetně jejich technologické integrace v prostředí střední až větší organizace. Budeme vycházet z následujících předpokladů Cílovým zákazníkem je větší organizace provozující desítky IT systémů Implementace cílového řešení (např. nový produkt) vyžaduje modifikaci několika existujících systémů a implementaci nových modulů. Implementace je rozdělena do několika projektových týmů, které jsou realizovány různými dodavateli či vlastními odděleními IT vývoje. Zadání je vytvářeno různými odděleními zadavatele a je nezbytná jeho konsolidace Cílové řešení obsahuje business procesy, které vyžadují spolupráci více aplikací – nutná součinnost projektových týmů při integraci aplikací (návrh a implementace rozhraní, integrační testy apod.)


141

Libor Jirsák

1.2 Vlastnosti integračního projektu Projekty většího rozsahu vyžadující implementaci několika nových systémů či modifikaci několika existujících systémů představují vysokou složitost z hlediska řízení. Aby bylo možné složitost zvládnout a efektivně řídit, je nutné komplexní projekt rozdělit na menší lépe řiditelné celky. Jakým způsobem rozdělit velký projekt na menší samostatné projektové týmy ? V některých případech se kritéria členění nabízí samy, jinde je musíme hledat. Podrobněji popsaná kritéria dělené projektu do projektových týmů či subprojektů lze nalézt v literatuře [8]. Příklady kritérií: Charakteristika implementace – vývoj aplikace na zelené louce, nová verze aplikace, parametrizace balíkového řešení, konverze dat, grafický návrh tiskových výstupů, nasazení specifické technologie – např. digitalizace telefonních hovorů) Členění týmů dle aplikací či větších funkčních celků Členění dle použitých technologií Pro některé požadavky již existují paralelní projekty Ideální je projektové týmy definovat tak, aby byly na sobě co nejméně závislé. Není příliš vhodné takové členění, kdy jeden tým bez druhého není schopen spustit a otestovat žádnou část aplikace. Každý projektový tým má své autonomní řízení, úkoly a termíny, jejichž plnění je možné průběžně sledovat a vyhodnocovat. Může se jednat o menší projektový tým, ale může se jednat i o subprojekt většího rozsahu, který má vlastní struktury řízení, rozpočet a harmonogram a tvoří subdodávku integračnímu projektu (např. upgrade SAP FI, budování centrálního tiskového řešení, apod). Náročnost integračních projektů spočívá v nutnosti zkoordinovat několik paralelně běžících projektů, které mají sdílené zadání, funkčnosti, technologická i manažerská rizika a termíny. Dostatečné zajištění a zvládnutí těchto úkolů je základním předpokladem úspěšnosti integračního projektu. K úkolům integračního projektu patří: Definovat a garantovat konzistentní architekturu cílového řešení pro dané business požadavky Garantovat kvalitu komplexního řešení (včetně funkční integrace jednotlivých částí) Udržovat aktuální globální plán projektu včetně závislostí Koordinovat součinnost „business“ oddělení a IT oddělení mezi jednotlivými projektovými týmy, aby nedocházelo k neefektivnímu plývání lidskými zdroji Organizace integračních testů Příprava akceptačních kritérií a zajištění procesu akceptace konečného řešení Organizace nasazení a zahájení pilotního provozu Komplexnost IT řešení v prostředí větších zákazníků lze demonstrovat na procesu přijetí platby běžné pojistného životního pojištění v České pojišťovně, který představuje integraci cca 10 systémů. Zkratky uvedené v závorce představují různé IT systémy v České pojišťovně.

142



Obrázek 1: Příklad obchodního procesu vyžadujícího integraci

2. Strategie řízení integračního projektu Klíčovou myšlenkou řízení integračního projektu je definice úrovní řízení, jejich vzájemných vazeb a definice centrální řídící jednotky, tzv. integračního týmu. Navržená metodika je použitelná jak v případě, kdy roli systémového integrátora plní specializovaná externí firma, tak v případě, kdy firma zajišťuje systémovou integraci ve vlastní režii (vlastní zodpovědnost) pomocí vlastních či pronajatých specializovaných pracovníků.

2.1 Model řízení Integrační projekt se skládá z několika typů týmů – realizační, analytické, IT oddělení a další zainteresovaná oddělení (obchodní či zadavatelská). Jednotlivé týmy jsou autonomní jednotky, kde každá má svého vedoucího, své úkoly, termíny a rizika. Významnou roli v řízení celého projektu hraje integrační tým, který je součástí centrálního řízení projektu (jeho úloha bude detailněji popsána dále).


143

Libor Jirsák

Obrázek 2: Model řízení integračního projektu Uvedené schéma, které je součástí metodiky Unicornu [3] určené pro integrační projekty, popisuje vztahy mezi jednotlivými projektovými týmy. Za řízení integračního projektu je zodpovědný projektový manažer integračního týmu, který podléhá Výkonnému výboru projektu (Steering Committee). Kromě projektového manažera je součástí centrálního řízení projektu také Integrační tým, (Integration team), produktový manažer (product manager) a vedoucí zainteresovaných oddělení (IT a business oddělení), kteří projekt neřídí, ale nesou zodpovědnost za věcnou správnost řešení. Projektové týmy (Realisation teams) Jednotlivé projektové týmy integračního projektu mohou být tvořeny pracovníky externích dodavatelů nebo interními pracovníky IT oddělení dle toho, jakou formou je daná část projektu realizována. Každý projektový tým má svého vedoucího, který spravuje úkoly týmu, rizika, či problémy k eskalaci a pravidelně reportuje o stavu projektu integračnímu týmu a manažerovi projektu. V některých případech může projektový tým reprezentovat samostatný projekt, který je definován vlastním rozpočtem, termínem, kontraktem, a který má z hlediska integračního projektu formu subprojektu či subdodávky. Centrální jednotka řízení (Central project management) Centrální jednotka slouží jako hlavní řídící prvek, který zajišťuje koordinaci projektových týmů v různých rovinách (technická, věcná, manažerská). Součástí této jednotky je projektový manažer, Integrační tým, který tvoří poradní orgán projektového manažera, a produktový manažer, který má na starosti obchodní aspekty nového produktu. Analytické týmy (Analytical teams) Business zadání produktu (jeho modifikace) je nutné připravovat komplexně s ohledem na dopady do různých odborných oblastí, např. účetnictví, marketing, technické výpočty, klíčoví uživatelé. Vedoucí zodpovědných odborných oddělení ve spolupráci s projektovým manažerem delegují zodpovědné zástupce (klíčové uživatele) coby věcné garanty za určitou 144



oblast do analytických týmů. Hlavním úkolem analytických týmů je zpracovat vize produktu do podoby konzistentního business zadání. Pracovníci business oddělení však většinou mají malé znalosti IT či znalosti metodiky vývoje software (systémový přístup, modelování, objektový přístup, procesní modelování apod.). Analytické týmy jsou proto dále doplněny o IT analytiky (interní zaměstnance či externisty), kteří přináší systémový přístup do analýzy a zároveň snižuje riziko nekonzistencí a nepokrytých oblastí v business zadání. Výstupem práce analytických týmů je jedno konzistentní business zadání, které je vstupem procesu IT implementace. V průběhu implementace analytické týmy business zadání doplňují a upřesňují na základě otevřených otázek vznikajících při analýze a návrhu prováděným realizačními týmy. Obchodní příprava (Sales Activities) Obchodní příprava zahrnuje týmy, které se zabývají nonIT aktivitami související s novým produktem. Jedná se o zajištění distribučních kanálů produktu, vyškolení prodejců, zajištění propagace apod. Bližší popis těchto aktivit je však mimo rámec této práce. Za koordinaci obchodních aktivit je zodpovědný produktový manažer, který reportuje Programovému výbor spolu s projektovým manažerem (zodpovědným za IT implementaci). IT oddělení (IT Departments) Projekt musí úzce spolupracovat se zainteresovanými IT odděleními ohledně infrastruktury, bezpečnostních politik či požadavků na provoz aplikací. Klíčová je spolupráce s oddělením IT strategie, které schvaluje architekturu řešení a definuje implementační, architektonické a integrační standardy, je zodpovědné za rozvoj integrační platformy a optimální využívání IT aktiv (existující IT služby, IT infrastruktura, atd..) Klíčovou úlohu má tým IT architektury, které obvykle existuje v každé střední a větší společnosti a má na starost utváření a implementaci IT strategie. Součástí IT strategie je definice IT architektury vedoucí k efektivnímu využívání IT zdrojů a minimalizace Time To Market (doba nutná k uvedení nových či modifikovaných produktů na trh).

2.2 Úrovně řízení Následující schéma zachycuje hierarchické úrovně řízení integračního projektu. Povšimněte si zejména oddělení operativního řízení jednotlivých projektových týmů a centrálního řízení zodpovědného za koordinaci projektových týmů.


145

Libor Jirsák

Obrázek 3: Úrovně řízení integračního projektu Programový výbor (Steering Committee) Reprezentuje nejvyšší orgán projektu rozhodující o jeho zahájení či ukončení a schvalující klíčové termíny a rozpočet projektu. Jeho členy jsou obvykle členové vyššího vedení společnosti. Konsolidované reporty o stavu projektu získává programový výbor pravidelně od projektového manažera. V průběhu projektu programový výbor (ne)schvaluje změny termínů či rozpočtu pokud si to okolnosti vyžádají. Centrální řízení Centrální jednotka řízení zajišťuje koordinaci aktivit projektových týmů (analýza, implementace, integrační testy, atd..) především jejich vzájemné součinnosti, kontroluje plnění úkolů a termínů a vyhodnocuje rizika. Na úrovni centrálního řízení je sledováno plnění globálního projektového plánu (masterplan). Vůči projektovým týmům však Integrační tým není v pozici nadřízeného. Identifikované problémy a rizika eskaluje na projektového manažera integračního projektu, který je buď roli přímého nadřízeného nebo musí eskalovat řešení problému prostřednictvím nadřízených manažerů v organizaci (např. nutnost zrychlit služby centrálního helpdesku, změna bezpečnostní politiky, apod) a zajistit dohodu na úrovni managementu organizace.. Operativní řízení Operativní řízení představuje vedení jednotlivých projektových týmů, které je vůči centrálnímu řízení reprezentováno vedoucím týmu, který pravidelně poskytuje report (stav úkolů, rizika). Na úrovni operativního řízení je

146



sledováno plnění projektového plánu, který musí být ukotven k milníkům definovaným globálním plánem.

2.3 Fáze projektu

Obrázek 4: Fáze integračního projektu Schéma zachycuje klíčové aktivity v rámci integračního projektu (jedná se o aktivity relevantní pro IT implementaci). Uvedené schéma vychází z metodiky integračního projektu, bylo však účelově zjednodušeno pro potřeby vyjádření základních myšlenek metodiky. Žluté aktivity označují ty aktivity, které probíhají převážně v režii jednotlivých projektových týmů a integrační tým se na nich podílí především revizí a schvalováním výstupů, řešením sporných oblastí, zajištěním součinnosti a sledováním vývoje rizik a plnění harmonogramu. Modré aktivity naopak provádí především integrační tým ve spolupráci se zástupci zadavatele. Uvedené aktivity zároveň představují milníky projektu zakotvené v globálním plánu. Překročení milníků s velkou pravděpodobností znamená dopady do plánů jednotlivých projektových týmů, které mohou vyvolat celkový posun harmonogramu. Za správu globálního plánu projektu je zodpovědný Projektový manažer (snad každý projekt má manažera projektu, ne???). Změny v globálním plánu projektu schvaluje Výkonný výboru projektu.

3. Integrační tým Integrační tým je součástí centrálního řízení projektu a slouží jako poradní orgán projektového manažera integračního projektu, především v oblastech metodiky, infrastruktury a architektury a zároveň koordinuje intenzivní, ale zároveň řízenou výměnu informací mezi centrálním řízením a jednotlivými projektovými týmy. Integrační tým existuje po celou dobu projektu s tím, že v určitých fázích projektu může být tým dle potřeby posílen o další analytiky, SW architekty či testery, kteří pomohou překonat zvýšený nápor práce v určitých fázích (konsolidace zadání, integrace, akceptační testy).


147

Libor Jirsák

Obrázek 5: Integrační tým [3]

3.1 Složení integračního týmu Integrační tým hraje klíčovou úlohu nejen při integraci projektu, ale i při řízení projektu. Je proto nezbytné, aby členové integračního týmu byly osoby s dlouhodobějšími zkušenostmi, které díky svým zkušenostem dokážou řadu možných problémů předvídat dříve než nastanou a lépe se tak na ně připravit. Vedoucí integračního týmu (Integration team leader) Osoba se značnými manažerskými dovednosti (řízení rizik, udržování plánu, jednání s dodavateli). Manažer integračního týmu je v úzkém kontaktu s projektovým manažerem i s jednotlivými vedoucími projektových týmů, připravuje pravidelné souhrnné reporty, sleduje plnění globálního plánu a rizika případné posuny dílčích plánů projektových týmů. Velmi důležité je též vedení projektové dokumentace a distribuce schválených výstupů mezi projektové týmy. Business architekt Osoba vybavená dovednostmi z oblasti metodiky (modelování, proces vývoje SW), má všeobecný přehled o používaných technologiích a jejich možnostech (myšleno především z pohledu uživatele). Nejdůležitější je však širší znalost věcné problematiky, včetně dobré znalosti specifik konkrétního zadavatele. Softwarový architekt Osoba vybavená dobrou znalostí relevantních technologií, nejdůležitější jsou však zkušenosti s návrhem architektury velkých řešení, zkušenosti s integrací aplikací a znalost principů SOA. Tato osoba nemusí dokonale ovládat všechny technologie používané na projektu, nezbytná je však taková úroveň, aby softwarový architekt byl schopen s dotčenými týmy (pracovníci IT oddělení, subdodavatelé, atd) dohodnout potřebná rozhraní a projednat aspekty infrastruktury

148



Koordinátor nasazení Osoba vybavená zkušenostmi s nasazováním aplikací ve větších organizacích a znalostí obvyklých provozních postupů (instalace, zálohování, atd..). Důležitá je též základní znalost relevantních platforem a jejich specifik, aby byl dotyčný schopen předvídat potenciální komplikace při nasazení. V případě méně složitého nasazení může tato role být zastávána manažerem integračního týmu. Koordinátor nasazení je zodpovědný za přípravu plánu nasazení a jeho organizaci.

3.2 Úkoly integračního týmu Konsolidace Business zadání Integrační tým se podílí revizi a schválení business zadání z pohledu systémového a metodického a garantuje jeho použitelnost IT implementaci. První důležitou oblastí je zajistit konzistenci zadání, pokud je vytvářeno více analytickými týmy (finanční toky, právní aspekty, technické výpočty, atd..) Druhou důležitou oblastí jsou nefunkční požadavky, které by měly být součástí zadání – např. požadavky na dobu zpracování, provozní doba systému, počty uživatelů, počty transakcí, požadavky na archivaci, atd…

Koordinace aktivit mezi projektovými týmy, business útvary, IT útvary Jak je zřejmé z popisu výše, integračního projektu se účastní několik projektových týmů a dalších oddělení, které mezi sebou musí komunikovat ohledně upřesnění zadání, projednání infrastruktury, definice rozhraní, atd…. Integrační tým (jeho kompetentní zástupce) by se měl účastnit důležitých jednání mezi týmy (případně je přímo organizovat a moderovat), kde mají vzniknout rozhodnutí, která mají dopad na okolní týmy, termíny, rozpočet, atd..

Koordinace aktivit mezi projekty navzájem Největším problémem řízení integračního projektu je udržet aktuální plán projektu včetně důležitých návazností. V případě zpoždění některé aktivity je důležité znát dopady do aktivit ostatních projektů. Na úrovni centrálního řízení není nutné udržovat harmonogram obsahující úplně všechny aktivity všech projektových týmů, efektivnější je držet globální plán (též nazývaný master plán) projektu, který obsahuje milníky, ke kterým jsou ukotveny detailní plány jednotlivých projektových týmů. Posuny těchto milníků mohou mít kaskádový dopad do harmonogramů všech projektových týmů a s největší pravděpodobností vyvolají dopad i do globálního harmonogramu. Naopak posuny termínů v rámci projektových týmů, které nezpůsobí posun globálních milníků, nejsou kritické z hlediska centrálního řízení projektu. Pro centrální řízení jsou však i tyto posuny zajímavé, neboť zvyšují riziko.

Architektura řešení Rozdělení celkového řešení na samostatné projektové týmy v sobě skrývá velké riziko, že vznikne balík nesourodých aplikací, který bude sice funkční, ale z dlouhodobého hlediska přinese vysoké náklady na údržbu a rozvoj. Klíčovou rolí integračního týmu je prosazovat firemní standardy IT (technologické a architektonické standardy, efektivní využití existujících IT komponent (služeb)). Členové integračního týmu, v tomto případě především SW architekt, musí být dobře obeznámen s firemní IT strategií a reviduje detailní návrhy řešení jednotlivých SYSTÉMOVÁ INTEGRACE 1/2008

149

Libor Jirsák

týmů a ověřuje jejich konformnost s existující IT infrastrukturou a případně používanými monitorovacími nástroji. Odsouhlasení jednotlivých výstupů se samozřejmě účastní též zástupci zodpovědných IT oddělení. Souhrnně je možné definovat seznam úkolů takto Návrh celkového technického řešení, mapování funkčností na jednotlivé IT komponenty (aplikace, služby) a dodržování základních architektonických principů - Definice jednotlivých aplikací, komponent a jejich rozsahu - Výběr nejvýhodnějších technologií pro implementaci komponent Definice technických architektonických omezení vyplývajících z podnikové architektury, např. - Bezpečnost (autentikace, autorizace, audit, single sign-on) - Integrace s podnikovým portálem (omezení HTML, GUI standardy) - Middleware (technologie, podporované protokoly (SOAP, FTP, JMS, DCOM) - HW architektura (zapojení, geografická distribuce) - Síťová architektura (povolené protokoly, proxy servery, firewaly, DHCP, DNS, load balancing, atd..) Kompletace nefunkčních požadavků s dopadem na architekturu , např. - Požadované SLA - Přístupové technologické kanály (PC, PDA, WAP, atd …) - Integrace s externími partnery

Definice rozhraní Rozhraní tvoří styčné plochy mezi částmi systému a zároveň mezi jednotlivými projektovými týmy. Jelikož definice rozhraní má zásadní dopad na architekturu cílového řešení, nelze definici ponechat na jednotlivých realizačních týmech. Zodpovědnost za definici rozhraní je proto na Integračním týmu (především softwarovový architekt a business architekt). Definice typových integračních řešení (technologie, vzorová řešení) Logická definice rozhraní (vychází z informačních potřeb jednotlivých IT komponent) Technická specifikace rozhraní

Příprava testovací Strategie Kritickým faktorem úspěšnosti projektu je projednání a schválení kvalitní strategie testování a akceptace. Hlavním cílem testů je ověřit, zda výsledné dílo je v použitelné v souladu s business zadáním na uvažované IT infrastruktuře. Aby bylo možné testy provést, je nutné připravit strategii testů, testovací scénáře, testovací data a konečně testy provést a také vyhodnotit. Zejména je nutné vyjasnit zodpovědnost za jednotlivé kroky. Strategie testů obvykle zahrnuje celou řadu testů: Uživatelské akceptační testy Integrační testy

150



E2E testy (testování obchodního procesu napříč všemi dotčenými systémy) Zátěžové testy Penetrační testy Testy nasazení Strategii testování a akceptace je nutné připravovat zároveň s analýzou a návrhem řešení. Důlěžité je, aby každý požadavek měl svého vlastníka, který bude zároveň odpovědný za akceptaci. Příprava testovací strategie je v kompetenci integračního týmu (Test architekta), jednotlivé týmy se podílejí dílčími testovacími scénáři. Organizace testů zahrnuje tyto hlavní kroky: Příprava testovacích scénářů Příprava testovacích dat Provedení testů Vyhodnocení výsledků testů

Zajištění akceptace řešení Akceptaci řešení provádí vedoucí zainteresovaných IT i business oddělení na základě výsledků akceptačních testů a dalších podkladů připravených Integračním týmem a projektovými týmy. Podklady k akceptaci se samozřejmě mohou lišit projekt od projektu, proto uvádím typické příklady Výsledky uživatelských akceptačních testů Výsledky zátěžových testů pro ověření splnění SLA (Service Level Agreement) Výsledky E2E testů (sestavy z účetnictví, sestavy z datového skladu, výpisy z účtu, apod) Výsledky E2E jsou obzvláště kritické pro akceptaci integrovaného řešení, protože ukazují kvalitu řešení jako celku. Uvedené příklady jsou typické případy, na kde se nekonzistence projevují. Dokumentace řešení (uživatelská, provozní, instalační, atd..) Souhrnný výsledek akceptace je pak podkladem pro Go/NoGo jednání, kde se rozhoduje, zda je cílové řešení dostatečně kvalitní, aby ho bylo možné nasadit do pilotního provozu. „Go“ verdikt nemusí znamenat, že bylo akceptováno úplně vše, některé výsledky mohou být akceptovány s výhradou. Konečné Go nebo NoGo rozhodnutí je v kompetenci Výkonného výboru projektu na základě výsledků akceptačního řízení.

Strategie nasazení Pro úspěšné uvedení produktu do testovacího, pilotního či produkčního provozu je nezbytné připravit plán nasazení. Tento plán je vhodné začít připravovat s velkým předstihem, aby byly zmapovány závislosti, potenciální rizika nasazení a další související aktivity (navýšení HW, navýšení počtu licencí, možné termíny odstávky běžících systémů,migrace dat z existujících systémů, zajištění účasti pracovníků podílejících se na nasazení). Vzniklý harmonogram a odpovídající aktivity je nutné zakotvit jak to dílčích plánů projektových týmů, tak do globálního plánu projektu. Je třeba si uvědomit, že na strategii nasazení IT navazuje harmonogram obchodních aktivit (uvedení produktu na trh apod.


151

Libor Jirsák

4. Integrační projekt v SOA Doposud jsme se zabývali obecným přístupem k rozsáhlejšímu projektu systémové integrace. Dále se zaměříme na specifické aspekty řízení projektu, ve kterém chceme uplatňovat principy servisně orientované architektury (SOA). Podívejme se nyní, jak by bylo vhodné přizpůsobit strukturu řízení integračního projektu, aby organizace mohla těžit z přínosů SOA a směřovala k budování servisně orientované organizace, čímž rozumíme organizaci, které dokáže architekturu orientovanou na službách efektivně využívat v oblastí jejích obchodních cílů na konkurenčním trhu. Nejdříve uveďme klíčové vlastnosti SOA definovány dle [1].

4.1 Klíčové vlastnosti SOA Volně spřažené služby Ucelená business funkčnost je implementována jako zapouzdřené služby (komponenty) vystavené pomocí ESB (Enterprise Service Bus – podniková sběrnice). Volně spřažené služby je možné snadno znovupoužít při tvorbě kompozitních aplikací nebo služeb. Business logika není zakódovaná uvnitř služby, ale je implementována pomocí nástrojů pro správu business pravidel (BRMS), aby byla snadno modifikovatelné vybranými uživateli.

Infrastruktura orientovaná na zprávy Základem SOA musí být jednotná infrastruktura pro výměnu zpráv mezi jednotlivými komponentami (službami) založená na otevřených standardech umožňujících vysokou míru interoperability. Bez robustní a interoperabilní SOA infrastruktury lze těžko uvažovat o tvorbě kompozitních aplikací a služeb [6]. Nejběžnější technologií pro výměnu zpráv jsou webové služby nebo MOM (Message Oriented Middleware). Standardem pro orchestraci procesů je jazyk BPEL. Jádrem komunikace je podniková sběrnice neboli Enterprise Service Bus, která tvoří infrastrukturu pro výměnu zpráv mezi znovupoužitelnými volně spřaženými službami. Příklady nejvýznamnějších řešení pro SOA infrastrukturu jsou Oracle Fusion Middleware, BEA AquaLogic, IBM WebSphere ESB.

Znovupoužitelnost služeb V SOA jsou služby implementovány jako volně spřažené komponenty poskytující otevřená rozhraní založená na otevřených standardech. Předpokladem znovupoužitelnosti komponent je však vysoká konfigurovatelnost business logiky (pomocí pravidel), která musí vycházet z relevantních obchodních potřeb.

Úzká vazba mezi IT službou a business službou V organizaci orientované na služby jsou služby navrhovány tak, aby odrážely služby, které podnik poskytuje svým zákazníkům a které mu přináší zisk. Toto uspořádání podniku umožňuje alokovat investice do těch služeb, které mu poskytují největší přidanou hodnotu.

Sledování a vyhodnocování služeb (governance) Pro efektivní správu a řízení SOA infrastruktury je třeba mít prostředky pro monitorování vytížení, odezvy, používání IT služeb. Získané statistiky slouží vedení

152



jako podklady k vyhodnocování efektivity využívání IT zdrojů a následné plánování dalších investic.

4.2 Fáze SOA projektu V předchozích kapitolách jsme se zabývali obecnými fázemi integračního projektu, nyní se zaměříme na aktivity projektu klíčové z hlediska SOA přístupu. Podíváme se, jak začlenit proces definice a znovupoužití služeb do aktivit integračního projektu. Je třeba určit, které aktivity mají zůstat v kompetenci jednotlivých projektových týmů a které musí zůstat v kompetenci integračního týmu. Základní myšlenka je zachycena na Obrázek 6.Klíčové jsou kroky identifikace služby, její specifikace a návrh či rozhodnutí o znovupoužití již existující služby [1]. Při identifikaci a návrhu služeb je nutné vycházet z podnikové architektury a business modelu definující služby, které organizaci vytváření přidanou hodnotu. Je zřejmé, že tyto aktivity nemohou být v kompetenci jednotlivých realizačních týmů, ale musí být prováděny integračním týmem ve spolupráci s podnikovými architekty, kteří mají na starost správu business modelu. Implementace služeb a jejich základní otestování je plně v kompetenci projektových týmů. Specifickou aktivitou při vývoji SOA aplikací je kompozice aplikací a služeb. Ta spočívá ve skládání aplikací z implementovaných komponent a služeb. Předpokladem úspěšné kompozice je předchozí dojednání rozhraní a dodržení standardů definovaných infrastrukturou. Před zahájením akceptačních testů je nezbytné provést integrační testy, aby bylo ověřeno, že jednotlivé části aplikace či jednotlivé služby spolu správně komunikují. Tyto testy jsou prováděny na úrovni jednotlivých týmů dle integračních vazeb na základě předem dohodnutých testovacích scénářů. Úspěšné ukončení integračních testů je předpokladem zahájení akceptačních testů. Předmětem akceptačních testů je ověřování kvality jednotlivých služeb i celkového řešení vzhledem k akceptačním kritériím. Nedílnou a nutnou součástí akceptačních testů jsou E2E testy, které prokáží funkčnost systému jako celku na jednotlivých obchodních procesech. E2E jsou obzvláště významné v architektuře SOA, kde je mnoho aplikací a služeb implementováno jako kompozitních, to znamená že vyžadují součinnost různých systémů od různých dodavatelů např: CRM, datový sklad, účetní systém, platební systém, provize, atd. Správné naplánování a projednání E2E je základním předpokladem úspěšné akceptace řešení. Finální fází projektu je nasazení celkového řešení do pilotního provozu, které kromě samotné instalace musí zahrnovat registraci služeb v podnikovém katalogu a na podnikové sběrnici. Součástí nasazení SOA aplikací je též začlenění služeb do obchodního monitoringu, který slouží pro vyhodnocování plnění SLA, ale také poskytuje business vlastníkům statistiky o využívání služby.


153

Libor Jirsák

Obrázek 6: Fáze SOA projektu

4.3 Spolupráce integračního týmu na budování SOA Kritickým faktorem pro úspěšnost SOA přístupu je mít definovanou strategii řízení podnikové architektury a také zkušený tým architektů, kteří jsou schopni navrhnout optimálně veliké služby tak, aby byly znovupoužitelné a otevřené, aby je bylo možno využít v kompozitních aplikacích. V opačném případě hrozí, že SOA očekávaný přínos nepřinese a stane se pouze další technologií, implikující ještě složitější IT infrastrukturu a další ukrojený koláč z podnikového rozpočtu bez výrazného pozitivního efektu.. V rámci integračního týmu musí působit zkušený softwarový architekt se zkušeností SOA projektu a zároveň úzce spolupracovat s podnikovým architektem (Enterprise Architect), který dohlíží na efektivní tvorbu a využívání IT služeb v podniku v souladu s IT strategií. Níže uvedený obrázek rozšiřuje model řízení uvedený na Obrázek 2 o vztah mezi jednotlivými integračními projekty a týmem podnikových architektů, kteří udržují podnikový katalog služeb a podnikovou architekturu v souladu s IT strategií.

154



Obrázek 7: Integrační tým v SOA projektu

4.4 Servisně orientovaná organizace (SOE) Pod pojmem servisně orientovaná organizace (Service Oriented Enterprise – SOE) rozumíme takovou organizaci, která principy SOA přenáší do roviny obchodní a roviny řízení [9]. Podobně je jako vztah mezi IT službami definován pomocí rozhraní, je i vztahy mezi jednotlivými oddělením možné definovat jako rozhraní určující informační potřeby v rámci jednotlivých obchodních procesů. Znalost informačních toků mezi jednotlivými odděleními pak umožňuje efektivnější implementaci IT služeb. (např. příjem žádosti o kreditní kartu, vyhodnocení žádosti, atd…). Uspořádání, kdy obchodní služby lze namapovat na IT služby, usnadňuje komunikaci v rámci organizace a zároveň efektivnější řízení investic do IT podle významu jednotlivých obchodních procesů. Budování organizace orientované na služby je však dlouhodobý proces, který trvá několik let. Hlavní přínosy, kterých lze dosáhnout uplatňováním SOA, jsou uvedeny v následujících odstavcích.

Eefektivnější využívání IT zdrojů Správně navržené a implementované IT služby umožní v budoucnu jejich znovupoužití, čímž se investované peníze do jejich vývoje dále zhodnocují. Zprostředkovaně však šetří také náklady na další HW/SW a provozní personál. Na znovupoužitelné IT služby lze tak pohlížet jako na aktiva [5], která se znovupoužíváním zhodnocují.

Zkrácení doby uvedení na trh Servisně orientovaná organizace disponuje širokou paletou IT služeb, které může flexibilně využít ve své obchodní strategii (např. zvýšení konkurence schopnosti). Díky znovupoužitelným službách je organizace schopna uvést na trh nový produkt


155

Libor Jirsák

nebo zpřístupnit stávající produkty konkurence.

novým obchodním kanálům dříve než

„Zero integration“ V publikacích zabývajících se SOA se často setkáme s mottem „zero integration“ [1], uvažující technologickou integraci jako nepotřebnou v prostředí SOA. Autor se domnívá, že využití sdílené architektury i infrastruktury významně sníží rizika, čas a tudíž i náklady vynaložené na technologické prototypy integraci aplikací, zátěžové testy rozhraní atd….Nicméně, v realitě to však obvykle nikdy neznamená nulovou integraci a nepotřebné integrační testy. Ani otevřené standardy (např. webové služby) nejsou zcela jednotné a kompatibilní mezi všemi nástroji a SOA produkty.

Vyšší flexibilita business logiky Prakticky každý vrcholný management si dnes stěžuje na vysoké náklady na IS/IT. Složité a provázané informační systémy způsobují, že i jednoduché změny v parametrech business logiky často vyžadují nákladné zásahy dodavatele či dokonce změnu implementace. SOA vyvíjí tlak na vyjmutí obchodních pravidel mimo jednotlivé aplikace tak, aby mohly být změněny/konfigurovány zaškolenými uživateli. Ke správě business logiky slouží BRMS (Business Rules Management System) a BPMS (Business Process Management System).

5. Závěr Řízení projektů systémové integrace je v dnešní době velmi horké téma, neboť trh vyžaduje stále častější změny v informačních systémech při jejich stále větší provázanosti v rámci organizace i mimo ni. Situaci ještě více komplikuje heterogenní IT prostředí ve větších podnicích (banky, pojišťovny), které kvůli přežívajícím starším produktům musí udržovat dnes již zastaralé a nepodporované technologické platformy. Rozsáhlejší projekty obvykle vyžadují změny v několika IT systémech a vazbách mezi nimi, což v sobě skrývá nemalá technologická i manažerská rizika. Projekty tohoto rozsahu jsou chápány jako integrační projekty a vyžadují efektivní struktury řízení, které dokážou včas identifikovat rizika jak v manažerské, tak věcné a technické rovině. Pozdní identifikace problému může mít díky vzájemným závislostem kritický dopad do celkového harmonogramu projektu. Autor prezentoval v tomto příspěvku Integrační tým jako nástroj pro efektivní řízení rozsáhlejšího integračního projektu nejen v kontextu metodiky projektového řízení, ale také v kontextu budování architektury orientované na službách. Integrační tým soustředí kritické aktivity jako je konsolidace zadání, návrh globální architektury, definice rozhraní, integrační a akceptační testy do rukou týmu zkušených specialistů (softwarový architekt, business architekt, test architekt, koordinátor nasazení a manažer integračního týmu). Integrační tým je součástí centrálního řízení integračního projektu a tvoří poradní orgán projektovému manažerovi ve věcech odborného charakteru. Pomocí integračního týmu je tak možné docílit kvalitnějšího celkového řešení než kdyby byly jeho aktivity roztříštěny do jednotlivých projektových týmů. Kvalifikované obsazení integračního týmu přispěje nejen k úspěšnosti projektu jako takového, ale zároveň přispěje k dosažení dlouhodobých cílů IT definovaných strategii usilující o efektivní využívání IT zdrojů. Kvalifikovaný Integrační tým díky soustředění věcných i technických znalostí problematiky celkového řešení je schopen být zároveň vhodným nástrojem pro prosazování a uplatňování principů SOA na rozsáhlých projektech a přispívat 156



k budování organizace založené na službách (SOE). Uplatňování principů SOA má samozřejmě vliv na uspořádání aktivit a jejich kompetence v rámci integračního projektu. Klíčové dopady analyzuje kapitola 4.2. Závěrem lze říci, že ve střednědobém horizontu znamená SOA pro firmu výhodu oproti konkurenci, neboť umožní implementovat změny v IT rychleji a s menším rizikem. V dlouhodobém horizontu přechod na SOA znamená nutnost, jinak firma nedokáže udržet krok s konkurencí v inovaci produktů.

Literatura [1]

[2] [3] [4] [5] [6] [7] [8] [9]

E. A. Marks, M. Bell: Service Oriented Architecture: A planning and Implementation Guide for Business and Technology, John Wiley & Sons, 2006 D. Woods, T. Mattern: Enterprise SOA, Designing IT for Business Inovation, O’Reilly, 2006 Unicorn, Metodology for integration projects, 2006 IBM, Enterprise Integration Challenge, IBM White Paper, 2005 B. Carlson: Best Practices for Software Development Asset (SDA) Reuse, Logic Library, 2005 Oracle, Next-Generation SOA Infrastructure, Oracle Whitepaper, 2007 J. Jeng, A. Lianjun, IBM T.J. Watson Research Center: System Dynamics Modeling for SOA Project Management, IEEE, 2007 C. Dekkers, Quality Plus Technologies, Inc.: Increase ICT Project Success with Concrete Scope Management, IEEE, 2007 M. Vaic Služebně zorientováno, , Business World, 2006/05


157

Řízení projektu technologické integrace

Recommend Documents