Motto: V současné době je činnost organizací stále více závislá na IT podpoře, což způsobuje, že flexibilita organizace je přímo závislá na flexibilitě této IT podpory.

Proč modelovat podnikové IS?
S rostoucím rozsahem IT podpory pro různé oblasti činnosti organizace zároveň roste množství vazeb a závislostí mezi jednotlivými částmi IT systémů. Současně neustále rostou požadavky uživatelů podnikových systémů na rychlost implementace změn a nové funkcionality.

Pokud však rozvoj podnikových systémů není řízen, dochází k neustálému zvyšování nákladů na IT, neboť špatně řízené promítání změn do IT systémů je ve výsledku velmi nákladné. Prvotní promítnutí změny nebo přidání funkcionality se sice zpočátku při takovémto přístupu jako příliš nákladné nejeví, ale velmi záhy se bohužel ukáže potřeba provést ještě další změny, na které se původně zapomnělo, což ve výsledku znamená další úsilí a další náklady.

Abychom mohli mluvit o řízeném promítání změn, musíme mít jasno, jaké jsou dopady těchto změn. Pokud však máme podnikové systémy "namodelovány" pouze v podobě zdrojového kódu, je taková analýza dopadů velmi obtížná a nespolehlivá.

Obr. 1: Příklad modelu vybraného procesu - zpracování žádosti o registraci

Jak modelovat podnikové IS?
Pro modelování podnikových systémů je samozřejmě možné zvolit mnoho přístupů. V dalším textu bych chtěl čtenáře seznámit s pragmatickým přístupem, který umožňuje vytvořit potřebný model systémů a jejich vazeb v krátkém čase a s rozumnými náklady. Postup modelování vychází z metodiky Select Perspective určené pro vývoj a údržbu středních a rozsáhlých systémů. Z hlediska modelování využívá Select Perspective standard UML doplněný o modelování firemních procesů a modelování datových struktur.

Procesy
Pro celkový pohled na podnikový IS z hlediska dynamiky slouží procesní model. V tomto modelu je především zachycena vazba mezi firemními procesy a aplikacemi, které je podporují. Většina změn v systémech je totiž vyvolána změnami firemních procesů, takže model procesů je výchozím místem zkoumání při analýze dopadů změn.

Na základě tohoto modelu jsme schopni odvozovat, které systémy budou změnou ovlivněny a v jakém rozsahu.

Rozhraní a závislosti
Vzhledem k tomu, že většina podnikových systémů je složena z jednotlivých vzájemně provázaných aplikací od různých dodavatelů, jsou pro údržbu celého systému klíčovými informace o rozhraních aplikací (Interfaces). Základním modelem systému z hlediska jeho struktury je tedy model závislostí mezi jednotlivými aplikacemi (moduly, subsystémy) a jejich rozhraní. Příklad takovéhoto modelu je znázorněn na obrázku 2.

Model rozhraní umožňuje provádět analýzu dopadů toho, jak změna jednoho systému ovlivní další systémy.

Závislosti mezi aplikacemi podnikového IS jsou na tomto modelu zobecněním komunikace, která probíhá na úrovni rozhraní systémů. Detailnější model komunikace mezi aplikacemi se v Select Perspective vytváří pomocí diagramu interakcí rozhraní, pro který je použit diagram sekvencí zpráv s doplněnými komentáři. Tento detailnější model slouží pro přesnější pochopení a sledování dopadů změn rozhraní jednotlivých aplikací na ostatní aplikace. Na této úrovni jsou totiž detailně zachyceny služby a informační položky rozhraní aplikace a kontext jejich využití v návazných aplikacích.

Obr. 2: Model závislostí mezi jednotlivými aplikacemi (moduly, subsystémy) a jejich rozhraní

Detailní modely aplikací
Jednotlivé systémy je pak možné detailněji modelovat pomocí tradičních UML modelů, jako je model tříd nebo model interakcí. Vytvoření a údržba těchto detailních modelů je samozřejmě podstatně nákladnější a vyplatí se u systémů, které jsou buď intenzivně rozvíjeny nebo při novém vývoji.

V čem modelovat?
Jednotlivé modely lze vytvářet v různých prostředích od "kreslítek" typu MS PowerPoint až po robustní CASE nástroje. Při volbě nástroje je nutné zvážit především rozsah modelů a míru potřebné týmové spolupráce při tvorbě a úpravě modelů.

Klíčovou výhodou robustních nástrojů CASE jako je Select Component Architect, je schopnost zabezpečit vzájemnou konzistenci jednotlivých modelů mezi sebou. Informace vytvořené pomocí editorů diagramů jsou totiž ukládány v databázi informací (repository), a tak se nemůže stát, že na jednom diagramu je například rozhraní subsystému změněno, kdežto na jiném diagramu zůstane toto rozhraní beze změny. Robustním nástrojům jako Select Component Architect nečiní také potíže pracovat i s velmi rozsáhlými modely, které v průběhu modelování podnikových IS vznikají.

Poněkud vyšší pořizovací náklady standardního nástroje CASE oproti "kreslítkům" nebo prosté textové dokumentaci se rychle vrátí v úsporách práce informatiků, kteří se nemusí zabývat pracným sehráváním modelů a manuálním udržováním jejich konzistence.

Zpětné inženýrství
Detailní model jednotlivých aplikací je možné odvodit i pomocí nástrojů pro zpětné inženýrství kódu a datových struktur. Tento přístup je obvykle používán jako prvotní fáze dokumentace existujícího systému nebo v případech, kdy neexistuje dokumentace k některým částem podnikového IS.

V nástroji Select Component Architect lze kromě zpětného inženýrství (reverzace) kódu a datových struktur provádět i zpětné inženýrství binárních komponent, které jsou stále více používány při tvorbě soudobých aplikací.

Model jako komunikační nástroj
Celkový model podnikového IS je také velmi užitečným podkladem pro komunikaci s dodavateli jednotlivých aplikací při zadávání požadavků na funkcionalitu dodávaných aplikací. Například v prostředí Select Component Architect je možné velmi rychle vytvořit dílčí model rozhraní s příslušnou specifikací, kterou lze předat dodavateli jako zadání pro vytvářenou aplikaci. A naopak lze při dodávce aplikace provést zpětné inženýrství jejich rozhraní, pokud jsou realizována v nějaké standardní technologii, jako je Corba/IIOP, COM+ nebo webové služby (WSDL). To opět snižuje náklady na logické začlenění nové aplikace do celkového IS.

Výsledný přínos pro organizaci
Nasazení systematičtějšího přístupu nastíněného v tomto článku, který je navíc podpořen nástrojem CASE usnadňujícím vytváření a údržbu příslušných modelů, vede v krátkém horizontu cca 3-6 měsíců ke znatelným úsporám nákladů na rozvoj podnikového IT. Tyto úspory jsou však nejen finančního charakteru, který vyplývá z toho, že změny se daří úspěšně realizovat na první pokus, ale i charakteru psychologického, protože ve výsledku snižují stres pracovníků IT.

Autor článku, Jaromír Šveřepa, působí jako senior konzultant ve společnosti LBMS.