Požadavky se mění

Při návrhu informačního systému je téměř vždy požadováno perfektní přizpůsobení funkcí požadavkům businessu, nízké investiční i provozní náklady a dlouhodobá životnost řešení. Čistá výbušná směs pro designéry a architekty. Úspěšná jsou však jen ta řešení, která i po implementaci dokážou pružně reagovat na další změny, neboť uživatelé mají při reálném používání stále nové potřeby.

Z technologického pohledu se zde často prosazují řešení business procesů podpořených servisně orientovanou architekturou (SOA). Otázkou však zůstává, jak připravit „tu správnou“ SOA referenční architekturu, která bude dlouhodobě respektovat potřeby konkrétního podniku, pružně reagovat na změny jeho procesů a vhodně doplní již existující architekturu.

Osvědčený model

V praxi domácích i mezinárodních projektů se osvědčuje následující sled kroků při nastavení úspěšné architektury: business cíle a strategie, kontext řešení, business procesy, informační model, katalog služeb a definice služeb, implementace procesů s využitím služeb.

Klíčem k úspěchu uvedeného postupu je vzájemné pochopení mezi zástupci businessu a IT prostřednictvím sdíleného pohledu na procesy. Z pohledu businessu musí být procesy přizpůsobené reálnému kontextu okolí a naplňovat business strategii a cíle. Z pohledu IT musí být procesy naplněné konkrétními službami s přesně definovanou kompozicí, rozhraními a implementací.

Jak začít z business strany

Z praktického pohledu jsou na business straně tři klíčové vstupní body: business strategie a cíle zákazníka, kontextový model informačního systému v rámci podniku a business procesy. Pochopení business cílů a strategie je klíčem k identifikaci prioritních činností a procesů. Pro jejich zachycení se například osvědčuje Porterův hodnototvorný řetězec a Business Motivation Model (OMG BMM).

Kontextový model pomáhá identifikovat vztahy mezi klíčovými entitami v podniku a jeho okolím. Tyto entity jsou pak ideálním východiskem při identifikaci jednotlivých organizací a rolí vystupujících v business procesech. Zprávy vyměňované mezi entitami kontextového diagramu jsou zase typickou předlohou pro dokumenty, které si vyměňují jednotlivé činnosti v procesním modelu.

Pro zachycení kontextového modelu se v praxi osvědčuje běžný kontextový diagram v UML. Míra složitosti však musí být úměrná schopnosti lidí z businessu takový diagram pochopit a potvrdit jeho využitelnost. Kontextový diagram je jen nástrojem, skutečným cílem je sdílené porozumění vazbám podniku.

Jak zachytit kontext

Správně popsané business procesy jsou klíčem k úspěchu budoucí implementace. Musí tedy zachytit klíčové činnosti podniku, jejich vlastníky a informační toky, které mezi nimi probíhají. Informační toky je výhodné popsat pomocí dokumentů, které předurčí obsah, rozsah a strukturu předávaných informací. Ačkoliv se tento postup zdá banální, má dalekosáhlé důsledky a měl by co nejvěrněji zachytit realitu business procesů a jejich očekávaný rozvoj. Jednotlivé procesní činnosti bude totiž nutné dále namapovat na business služby.

Typicky jedna business služba obslouží několik procesních činností nebo i subprocesů. Zmíněné dokumenty a jejich struktura předurčí nadále strukturu rozhraní těchto služeb, a má proto zásadní dopad na implementaci. Pro popis business procesů je vhodné využít BPMN diagram s identifikovanými dokumenty na vazbách mezi jednotlivými činnostmi. Je graficky názorný a mnohé nástroje umožňují procesy dále analyzovat například prostřednictvím simulací průběhu různých variant.

Jak začít z technické strany

Z technického pohledu existují dva pilíře významné pro praktickou využitelnost sdíleného pohledu na business procesy: katalog technických služeb a informační model. Katalog technických služeb umožňuje klasifikovat služby ve dvou základních směrech. Horizontálně je vhodné služby rozdělit do předmětných domén, jako jsou například účetnictví, personalistika či plánování výroby. Vertikálně je vhodné služby dělit podle míry detailu, ve kterém pracují, a to od procesů nejblíže umístěných business služeb přes věcně zaměřené doménové služby až po atomické služby nejnižší úrovně.

Klíčové při sestavování katalogu služeb je nejen navrhovat nové služby, ale zároveň provést důkladnou analýzu služeb existujících a maximalizovat jejich opakované zapojení. Pro zpracování katalogu služeb se osvědčuje UML komponentový diagram doplněný textovým či tabulkovým popisem s klasifikací služeb. Typický popis služby obsahuje minimálně název služby, její technický kód, umístění, určení odpovědností, podmínky a pravidla pro užití a definici operací na rozhraní služby včetně vstupních a výstupních datových struktur. Ideální z pohledu použitelnosti je udržet celkový počet služeb v katalogu v počtu desítek a maximálně stovek.

Informační model zachycuje společný jazyk businessu a IT. Má dvě vrstvy, přičemž první z nich obsahuje dokumenty přímo namapované na spojnice mezi jednotlivými činnostmi v business procesech, v druhé jsou evidovány jednotlivé objektové třídy, které musí mít jednoznačnou vazbu na dokumenty z první vrstvy. Pro zachycení informačního modelu a provázání jeho dvou základních vrstev je možné použít UML diagram tříd.

Jak zkoordinovat celkový postup

Ačkoliv výše uvedené nástroje lákají k okamžitému hromadnému použití, v praxi se osvědčuje koordinovaný postup. Prvním krokem je pochopení a namodelování business procesů. Typickým rizikem v této etapě je nezájem zástupců businessu o sdílení informací. Pro odstranění nezájmu a nastavení společných komunikačních vazeb je přínosné právě zpracování kontextového modelu. Teprve po jeho odsouhlasení se vyplatí dále rozpracovat model business procesů a dokumenty pro informační model.

Navazující etapou je servisně orientovaná analýza, jejímž výstupem je katalog služeb spolu s rozpracováním druhé úrovně informačního modelu se seznamem požadavků kladených na řešený systém. Prvním rizikem je zde různé chápání pojmů, jako je zákazník, objednávka nebo zaměstnanec. Toto riziko lze minimalizovat právě včasnou identifikací dokumentů již při modelování procesů a rozpracováním druhé úrovně informačního modelu. Druhým typickým rizikem v této etapě je nepochopení služeb a často nekonečné diskuse o ideální granularitě při popisu služeb. Toto riziko lze minimalizovat zavedením víceúrovňového katalogu služeb s rozdílnou mírou detailnosti služeb v jednotlivých vrstvách.

Na servisně orientovanou analýzu navazuje návrh služeb a tyto dvě etapy často vzájemně iterují. Návrh služeb umožňuje kombinovat nové a znovupoužít existující služby a je hlavním akcelerátorem úspěšného využití SOA přístupu. Výstupem této etapy jsou kompozitní služby, jejich popisy a definice rozhraní. Klíčovým rizikem v této etapě je, že si služby „nebudou rozumět“. Technické porozumění lze snadno zajistit využitím standardních komunikačních protokolů a formátů zpráv. Věcné porozumění mezi službami pak zajišťuje kvalitně provedený a v návrhu respektovaný informační model.

Vlastní implementace služeb je samostatnou oblastí, kde kromě dodržení standardů projektového řízení je také nutné zamezit nadměrné tvorbě služeb pro všechny potenciálně možné účely použití.

Kvalitní architekturu lze rozvíjet

Vytvořený informační model sjednocuje nejen jazyk komunikace služeb, ale i lidí zastupujících business a IT. Skutečnou kvalitu navržené architektury pak podle pořekadla „nic není dobré navždy“ prověří až její použití v čase, kdy kvalitní architekturu lze i po několika letech stále rozvíjet, a nikoliv přepracovat.