Jak na BPM a SOA prakticky

V konceptu BPM druhé generace jsou služby základním stavebním kamenem pro procesy podnikání. Služby mohou být používány opakovaně v jiném byznys kontextu a mohou být navzájem kombinovány. Přitom snadný vývoj a zjednodušené nasazování zejména webových služeb na bázi otevřených standardů umožňuje rychle doplnit chybějící funkcionality.

Servisně orientovaná architektura (SOA) tedy umožňuje sestavit z dostupných služeb optimální proces. Tím celému BPM poskytuje potřebnou infrastrukturu pro flexibilní design procesů při maximálním znovupoužití již existujících služeb.

Standardy
Základem otevřenosti servisně orientované architektury jsou standardy a těch začíná být nepočítaně:

Ty nejdůležitější z hlediska vztahu SOA a BPM jsou:

• BPMN - notace pro popis byznys procesů, která nemusí být až ta úplně nepostradatelná, jak probereme níže
• BPEL - jazyk orchestrace procesů, který je podepřen celou řadou standardů, např. WS-BPEL (automatizované workflow) či BPEL4People (interaktivní workflow)
• WSDL - standardní popis rozhraní služeb, které umožňuje, aby tuto službu využíval jakýkoliv klient, který je rozšířen o řadu praktických specifikací umožňujících využití služeb v reálné praxi, např. WS-ReliableMessaging, WS-Addressing, WS-Notification, WS-Security atd.

Postup při návrhu procesu

1. Byznys modelování
Vlastní modelování podnikového prostředí se prakticky neliší od běžného modelování podniku. Business model společnosti (BMS) by měl zachytit všechny podstatné aspekty podnikové architektury a jejich vztahy. Minimálně to je:

• organizační dimenze - organizační struktury, jejich kompetence ve vazbě na procesy a potřebné znalosti
• dimenze výkonnosti a řízení změn - strategie a její vazba na procesy a zdroje, výkony a jejich měření včetně ukazatelů výkonnosti
• dimenze zdrojů - z hlediska IT podniková architektura (EAI)
• procesní dimenze - celkový přehled procesů na potřebných úrovních podrobnosti až po tok přidané hodnoty v jednotlivých end-to-end procesech

Standardní notací pro modelování procesního toku je BPMN, která však má řadu omezení a nevýhod. Nic však nebrání využít pro záznam podrobného toku činností notaci EPC.

Na úrovni byznys modelů as-is je možno provádět analýzy včetně dynamických (simulace) a navrhovat optimalizace, které se zachytí do modelů to-be určených k implementaci.

2. Orchestrace
Byznys modely v notaci BPMN nebo EPC je nutné překlopit do jazyku BPEL. Většina modelovacích nástrojů umožňuje provést tuto konverzi automaticky a mít tyto modely umístěné v jednotné repository BMS. Jenže tím práce teprve začíná.

Do této repository je nutné nahrát standardní popis služeb ve formátu WSDL. Popis procesů v BPEL je nutné většinou dále zjemnit tak, aby bylo možné připojovat jednotlivé služby. A následně pro jednotlivé aktivity v BPEL příslušné služby připojit a nastavit jejich chování.

Uveďme ještě příklad tohoto postupu z hlediska možné kombinace použití nástrojů z různých rodin:

1. Byznys modelování provedeme například v některém z nástrojů rodiny ARIS. Podrobný popis procesů máme zachycen v notaci EPC.
2. EPC modely automaticky konvertujeme do notace BPEL a verifikujeme je zejména z hlediska jednoznačnosti. K tomu potřebujeme již specializovaný nástroj ARIS Business Architect. Výhodou je, že i BPEL notace má srozumitelnou vizualizaci.
3. Následně exportujeme tyto modely pomocí rozhraní ARIS2WebSphere a naimportujeme je do repository WebSphere.
4. K orchestraci služeb využijeme nástroj WebSphere Integration Developer. Do jeho repository naimportujeme popis služeb (WSDL) a objektů (XSD) a uspořádáme je.
5. Podle potřeby zpřesníme popis v BPEL, připojíme jednotlivé služby, nastavíme jejich parametry a napojíme rozhodování na příslušná pravidla. Vytvoříme obrazovky pro lidské aktivity.
6. Výsledný proces otestujeme a můžeme používat v prostředí WebSphere Process Server. Ten podporuje běh jak automatizovaných procesů, tak procesů s lidskou interakcí včetně interpretace pravidel.

3. Vývoj
Pokud ve fázi byznys modelování či nejpozději orchestrace zjistíme, že některá část procesu potřebuje jinou nebo novou službu, navrhneme její funkcionalitu (např. v nástroji ARIS UML Designer). K tomuto účelu se nejvíce využívá notace UML.

Následně je v příslušném vývojovém nástroji (např. Rational Software Architect) navržena a vyvinuta potřebná SW komponeta a následně je tato komponenta zpřístupněna jako služba (např. pomocí Rational Application Developer).

Podívejme se ještě jednou na celé schéma propojení BPM a SOA (zdroj ON-Demand Business):

4. Monitoring
Jedním z přínosů konceptů SOA pro BPM je dostupnost dat o chování procesů v reálném čase. Monitoring průběhu procesů většinou zajišťuje nějaký specializovaný nástroj nad respository procesního serveru (např. WebSphere Business Monitor) a ten umožňuje nejen sledovat průběhy procesů a jejich parametry (např. pomocí definovaných KPI's), ale i export těchto dat zpět do modelovacího nástroje k analýzám a simulaci.

O čem byla diskuse

Do diskuse byla položena pouze jediná otázka - Kdo řídí iniciativy SOA a zda jsou do nich nějak zapojeni lidé odpovědní ve firmách za BPM. Podle uvedených názorů běží v podnicích řada projektů charakteru SOA zaměřených na implementaci ESB jako prostředku pro zpřístupnění stávajících aplikací a systémovou integraci či vývojových projektů na bázi webových služeb.

Všechny tyto projekty řídí výhradně IT jako klasické informatické projekty. V diskusi nezazněla jediná zkušenost, která by naznačila jiný způsob zapojení byznys analytiků do těchto projektů resp. převedení těchto projektů do společného rámce BPM & SOA.

A tak se zdá, že tento plně technicky dostupný a účinný přístup ještě čeká na svou příležitost. Tu mu vytvoří jen jiná firemní kultura, která přestane separovat byznys a IT a vrátí se zpátky k jejich spolupráci.