Sociálně (komunitně) orientovaná architektura

Sociálně (komunitně) orientovaná architektura SOA 2.0: nové směry v zavádění a využívání servisně orientované architektury

Obsah

Současná řešení SOA

3

Povaha a skladba řešení SOA

3

Podmínky úspěšné implementace SOA

3

Nemalé investice se vyplatí

4

Architektura je zásadní prvek

4

Software as a Service

5

Otázky potenciálního zákazníka

7

Sociálně (komunitně) orientovaná architektura

8

Komunity vlastníků služeb

8

Technické příležitosti, komunitní výzvy

8

Faktory úspěchu SOA

9

Vše pod jednou střechou

10

Baterie přibaleny

11

Hodný džin z láhve

11

Just-in-time

12

Cílem je bohatší zkušenost zákazníka

12

Kontinuální služba

12

Hodnototvorný řetězec

13

Federované interakce

14

Výsledný požadavek na řízení

16

SOA dnes a zítra

17

Shrnutí: začněte se změnami

18

Slovníček pojmů

19

Informační zdroje

21

Kontakt

22

Reference

22


Povaha a skladba řešení SOA Trh s řešeními SOA se dnes všeobecně zaměřuje na vývoj, provoz, správu a optimalizaci softwaru utvářejícího síť volně provázaných podnikových služeb. V této síti mohou být odlišné služby spojeny do širších, kompozitních aplikací tak, že každá služba může být opakovaně použita v rámci dalších kompozitních aplikací. Taková řešení se často nabízejí jako jediná sada – pokud jsou však důsledně dodržovány oborové standardy, lze většinu funkcí zakoupit a provozovat od různých dodavatelů na různých platformách. Kromě úložiště metadat a nástrojů pro BPM (business process management) a BAM (business activity monitoring) obsahuje typické SOA řešení prostředí pro tvorbu a provoz služeb, dále různé typy middlewarů (aplikační servery, podnikové sběrnice služeb), které tyto služby podporují při provozu, portál nebo jiné rozhraní pro integraci na úrovni uživatelského rozhraní a řadu dalších nástrojů pro správu, řízení, sledování, vizualizaci a reporting celé infrastruktury SOA1.

Podmínky úspěšné implementace SOA Kromě základních stavebních kamenů, mezi které od počátku patřily princip volného provázání služeb (loosely coupling), distribuovatelnost a hrubozrnnost služeb, využívání oborových i technologických standardů a využití centralizovaného úložiště metadat, je pro úspěšnou SOA implementaci nutné splnit i další podmínky jako: • zabezpečení trvalé konektivity (nedostupná síť = žádná komunikace služeb), • dynamická flexibilita ICT (právě nyní potřebuji větší výkon CPU, více paměti, více diskového prostoru apod.), • pokrytí celého životního cyklu služby (návrh, vývoj, testování, simulace, implementace, monitorování, žurnálování, řízení, verzování), • schopnost prosadit u služeb definované politiky, a to v různých režimech (více služeb = společná politika, jedna služba = více politik), • vizualizace služeb z technologického i obchodního pohledu (kde která služba a v jakém stavu běží, kde je právě teď úzké místo zpracování, jaká obchodní data službou proudí apod.). Architekturu SOA nelze koupit, je možné ji pouze vybudovat2. Její vybudování nespočívá v trojím kliknutí myší, což by si mohli myslet ti, kteří se SOA zatím nic praktického nezkusili. SOA představuje postupy, které (pokud jsou správně vykonávány) přinesou deklarované přínosy. Příklad za všechny: často až nesmyslně vyzdvihovaná znuvupoužitelnost služeb by neměla být cílem, ale žádoucím vedlejším efektem správně nastavených postupů, které mají své kořeny především ve fázi dobrého návrhu a vývoje služeb. Za architektonicky životaschopný koncept jsou dnes považovány produkty opírající se o sběrnicovou topologii, obecně označované jako podnikové sběrnice 3


služeb - ESB (Enterprise Service Bus 3). ESB nepředstavuje bohužel žádný oborový standard, takže jsou za ESB často označovány i produkty, které s touto topologií nemají nic společného.

Nemalé investice se vyplatí Zákazníkům bývá (a nelze tvrdit, že záměrně) skrývána skutečnost, že složitost jejich ICT prostředí se bude nasazením SOA zvyšovat exponenciálně. Nejde přitom ani tak o samotný počet služeb, jako o počty vazeb a vzájemných závislostí mezi službami, které se mohou nacházet jak uvnitř, tak vně organizace. Je tedy nutné disponovat nástroji, které dané vazby a závislosti dokáží dynamicky mapovat a analyzovat či simulovat možné budoucí situace (například co se stane, když stávající počet konzumentů služeb rozšíříme o dalšího jednoho, dalších deset apod.) Zákazníkům také bývá (a rovněž nelze tvrdit, že záměrně) skrývána i skutečnost, že budování SOA je z krátkodobého (cca dvouletého) pohledu asi tím nejdražším možným přístupem. Investovat je nutné do softwaru a hardwaru, často i do síťově infrastruktury (redundantní okruhy), do vývoje a nasazení služeb i do vyškolení lidí. Kromě toho je třeba investovat i do propagace/evangelizace samotné architektury – nejenom směrem k vedení společnosti, ale zejména směrem k budoucím koncovým uživatelům. Na druhou stranu SOA s přehledem poráží všechny ostatní technologie v post-implementačních fázích – při údržbě, dalším rozvoji a při realizaci neustále přicházejících změn.

Architektura je zásadní prvek Softwaroví dodavatelé nezřídka pomíjejí to zásadní v SOA a tím je „A“ – tedy architektura. (Vývoj architektur podnikových informačních systémů přibližuje 4

Akcescchopnost podniku


Událostně řízená SOA Objednávky

ERP

CRM

Dodávky

ERP

Fakturace

WMS

FIN

ESB

Tradiční SOA Hub & Spoke A

Point-to-point A

G

1980

S

C

1990

D

G F

D F

C

B

H

Dávky

B

H

S

S

S

S

S

S S S CRM

S S ERP

S

S

S

S

S

S

S

S

S

S S S WMS

S

S

S

S

S

S

S

S

FINS

S

S

S

S

E

E

2000

2010

Čas

Obrázek 1: Vývoj architektur od dávkového zpracování k událostně řízené SOA

obr. 1.) Zatímco funkční vlastnosti jejich technologií se mohou přibližovat, architektura, o kterou se tyto technologie opírají, se může zásadně lišit. Fatální hrozbou pro zákazníky pak je, když tato odlišnost vyjde najevo až po nasazení dané technologie a cesta zpět je kvůli již vynaloženým investicím zpravidla nereálná. Podobnou hrozbou může být, pokud se softwarový dodavatel vůbec nemůže o žádnou architekturu opřít. To by však mělo být zjistitelné daleko dříve. Architektura bývá na pořadu dne, pokud se diskutují jak základní stavební kameny SOA, tak další praktické aspekty zmiňované v úvodu. Stejnou flexibilitu, kterou SOA poskytuje softwarovým aplikacím, musí poskytnout i všechny „spodní vrstvy“ SOA, resp. celá výpočetní infrastruktura. Dynamická virtualizace zdrojů se ukazuje jako technicky životaschopné řešení, působí však potíže SOA dodavatelům, kteří mají své licenční modely staticky vázány například na příslušný počet CPU, resp. jader CPU. Pokud se tento počet v čase dynamicky mění, vznikají potíže s legálností statické softwarové licence.

Software as a Service Odpovědí některých dodavatelů je zásadní změna licencování využitím modelu SaaS (Software as a Service). Tento model zcela abstrahuje od technických detailů. Od softwarového dodavatele však vyžaduje alespoň elementární porozumění byznysu zákazníka. Předmět licencování pak může být nastaven u každého zákazníka jinak podle specifického klíčového obchodního nebo výkonnostního ukazatele (Key Business/Performance Indicator). 5


Směřuje-li tento obchodní model spíše do hardwarové infrastruktury či outsourcingu/outhostingu, uplatňuje se zde model označován jako XaaS (anything as a service). Ukazuje se, že portálová řešení (ať již implementace balíkového řešení nebo vývoj na míru) představují jedny z optimálních „spouštěčů SOA“1. Zejména z pohledu servisně orientované integrace se implementace principů SOA přímo nabízí. Portál sám o sobě data vytváří jen z velmi malého procenta; zbylé je nutné získat jak pomocí asynchronních dávkových replikačních procesů, tak synchronními 6


dotazy uživatelů směřujícími jak na lokální, tak geograficky vzdálené datové zdroje/aplikace. Tyto integrační procesy, resp. služby mohou být podle potřeby instalovány jak lokálně (většina), tak geograficky vzdáleně – a to podle povahy daného datového zdroje.

Otázky potenciálního zákazníka Pokud existují postupy a technologie umožňující častěji inovovat, lépe vyhovět různým regulačním pravidlům či zákonům, přiblížit obchodní procesy reálnému času, šetřit náklady na vývoj/integraci aplikací, rychle a relativně snadno otevřít zděděné aplikace a zprůhlednit a zjednodušit správu a řízení ICT, je to pro potenciálního zákazníka velmi zajímavé. Podle jakých kritérií si ale má vybrat příslušného „dodavatele SOA“, když všichni deklarují, že jejich přístup z principů SOA vychází? Zákazník by měl především zjistit, zda potenciální dodavatel rozumí jeho byznysu a zda si je vědom všech rizik, vyjádřených nejstručněji bonmotem, že „k likvidaci podnikání postačuje pouze jedna služba“4. Na co by se tedy měl potenciální SOA zákazník ptát svého potenciálního dodavatele SOA: • Jak mi zaručíte, že deklarované přínosy skutečně nastanou i v mém případě? • Pomůže mi SOA spíše ušetřit nebo více vydělat či obojí? • Zvládnu SOA se stávajícími znalostmi a dovednostmi? • V čem vidíte největší rizika implementace a jak je chcete eliminovat? • Jak dlouho bude trvat základní implementace a jaký je plán dalšího rozvoje? • V čem se váš přístup liší od konkurence a kdo konkurence vlastně je? • Jaký dopad bude mít SOA na naši stávající ICT infrastrukturu? • Jakmile začneme místně či vzdáleně distribuovat služby, jaký dopad to bude mít na jejich softwarové licence? • Jaký dopad bude mít SOA na moje obchodní partnery?

7

Sociálně (komunitně) orientovaná architektura5

Komunity vlastníků služeb Zatímco dřívější technologie, jako jsou mainframy, klient/server i webové aplikace, interagují (vzájemně působí) jen s jedním subjektem, architektura SOA vytváří mnohostranné interakce. Vznikají komunity více či méně nezávislých vlastníků služeb, kteří v příslušném kontextu dynamicky spolupracují, společně nabízejí své služby a zprostředkovávají bohatší zákaznický prožitek při jejich využívání. Dnešní a zejména budoucí úspěšnost každého podniku je stále více výsledkem jeho schopnosti participovat v těchto nových, dynamičtějších, sjednocených komunitách. Tato orientace na společenství vytváří potřebu nových technologií SOA a změny v jejich řízení z hlediska toho, jak jsou tyto technologie poskytovány a spravovány (governovány) – a to způsobem, který nemusí být zcela triviální.

Technické příležitosti, komunitní výzvy Uživatelé se obecně zaměřují na přínosy SOA: bezproblémovou integraci, podnikovou akceschopnost a opakované použití služeb. Při realizaci těchto přínosů se však mohou vyskytnout problémy. • Pokud kvůli bezproblémové integraci rozbijete aplikační sila a otevřete hranice systémů, vytváříte bezpečnostní rizika. Kdo se dostane dovnitř? Kdo bude mít přistup k jakým informacím? • Podniková akceschopnost vám umožní využít tržní příležitosti. Ale jak budete řídit změny a kdo to bude kontrolovat? Potřebujete governanci. • Rozhodování o tom, co opakovaně používat (nebo nepoužívat) – a kdy, jak a kým – přináší otázky týkající se vlastnictví, svrchovanosti a řízení. Zatímco příležitosti SOA se týkají technologií, výzvy SOA se týkají lidí (viz obr. 2).

Příležitosti

Integrace

Integrace

Bezpečnost

Akceschopnost

Governance

Opakované použití

Vlastnictví

Servisně orientovaná architektura

Sociálně orientovaná architektura

Obrázek 2: Vazby mezi servisně orientovanou a sociálně (komunitně) orientovanou architekturou

8


Proto potřebujeme sociálně (tj. komunitně) orientovanou architekturu jako způsob, jímž umožníme lidem spolupracovat a využít příležitosti, které servisně orientovaná architektura nabízí.

Faktory úspěchu SOA Pokud technologie správně sestavíte a vhodně je řídíte, budou lidé schopni navzájem spolupracovat. Technologie důležité pro podporu komunitních interakcí a interakcí služeb jsou stejné: • Volné propojení interakcí. Nejlepší vztahy jsou založeny na svobodné, snadné interakci. Základem úspěšné servisně orientované architektury je bezproblémová interoperabilita. 9


• Aktivní sjednávání pravidel. Silné a důvěryhodné osobní a pracovní vazby jsou

založeny na neformálních, resp. formálních kontraktech s nepsanými zásadami nebo politikami týkajícími se respektování bezpečnosti a svrchovanosti a na určitých způsobech interakce. Pokud se objeví rozdíly ohledně výkladu pravidel, pak ve skutečně dobrém vztahu může kterákoli strana otevřít určitý problém a přímo vyjednat jeho řešení. • Přesná kontrola sémantiky. Ať už spolu svobodně komunikují lidé nebo systémy, potřebují mít jistotu, že si navzájem jasně rozumějí a chápou se. Výsledkem spojení těchto tří podmínek je jak konzistentní a aktivně reagující technická infrastruktura, tak chráněná a řízená komunita.

Vše pod jednou střechou Na webové stránce „Mé portfolio“ jedné velké americké banky se už nějaký čas zákazníkům zobrazuje volba „Přidej účty“. Kliknutím na volbu se zobrazí seznam více než dvou stovek odkazů na nezávislé společnosti nabízející kreditní karty, hypotéky, pojištění, ba i letenky. Zákazníci banky, kteří mají účty u těchto společ-

10


ností, si mohou přetáhnout informace z těchto účtů (včetně například nalétaných kilometrů) na stránku základních bankovních informací o svém osobním portfoliu. Vše pod jednou střechou. A co více – stejnou funkcionalitu najdou i na webových stránkách společností uvedených v seznamu. Taková federace jinak nezávislých společností nyní zákazníkovi umožní bezproblémově integrovat všechny informace o jeho účtech a zobrazovat je v mnoha různých kontextech. Takto federované společnosti zjednodušují a obohacují využívání služeb zákazníkem a díky tomu se výrazněji odlišují od konkurence.

Baterie přibaleny Jak často se vám stává, že koupíte dětem hračku nebo nějaký přístroj, začnete jej zprovozňovat – a zjistíte, že abyste práci dokončili, musíte jít ven a dokoupit baterie? Zaměstnanci pracující s ERP systémem, aplikací pro vyřizování půjček apod. musí obvykle podobným způsobem přerušit svou práce pokaždé, když pro dokončení svého úkolu potřebují například informaci o podnikatelském úvěru. Musí svou aplikaci opustit, jít na web poskytovatele informací o úvěrech a zjištěnou informaci o úvěru znovu zadat do své aplikace. Naštěstí vedoucí americká společnost poskytující informace o úvěrech si uvědomila, že může poskytovat správné informace na správném místě – a získá další příležitost k růstu svého byznysu. Proto vytvořila sadu rozhraní pro své webové služby a dodavatelům aplikací, které vyžadují informace o podnikatelských úvěrech, prodává licence na tato rozhraní. Softwaroví dodavatelé mohou rozhraní vestavět do svých aplikací, čímž svým zákazníkům umožní získat informace o úvěrech kdykoli a kdekoli je potřebují – v rámci aplikace, v níž právě pracují.

Hodný džin z láhve Online agregátoři služeb leteckých společností obvykle nabízejí letenky prakticky všech aerolinek plus rezervace služeb mnoha hotelů, pronajímatelů aut apod. Ale jeden přední agregátor rozšiřuje své podnikání i tím, že spolu s přidruženými weby buduje na svých stránkách novou SOA komunitu. Například participující golfový web může obsahovat odkazy na dovolenou v golfovém středisku na Bermudách, jazzový web odkazuje na zájezdy na festival v Newportu a na webu o vínech lze nalézt odkazy na výlety do vinohradů v údolích Sonopa a Napa. Pro návštěvníky těchto webů je SOA komunita oním hodným džinem z láhve, který umožní splnit mnohá jejich přání. Odkazy na participujících webech 11


povedou na stránky zmíněného agregátora, odkud si mohou rezervovat všechny potřebné služby prostřednictvím dalších odkazů na weby aerolinií, hotelů, půjčoven aut apod.

Just-in-time SOA může být tvořena i vnitřními vlastníky služeb: pobočkami podniku, divizemi poboček, odděleními divizí, dokonce kancelářemi distribuovaných oddělení apod. Významný výrobce letadel s revolučním designem využil ideu SOA komunity na nové inovativní úrovni a zásadně přepracoval své výrobní postupy. Společnost vytvořila dodavatelský řetězec SOA, jehož součástí jsou kromě externích partnerů i všechny interní pracovní útvary fungující jako nezávislí, federovaní vlastníci služeb. Cílem je schopnost insourcovat nebo outsourcovat jakoukoli úroveň služeb během pracovního procesu. Společnost přenesla výrobu just-in-time na novou úroveň, která umožňuje dostatečné přizpůsobení měnícím se okolnostem a v jednotlivých útvarech eliminuje určité úrovně byrokracie.

Cílem je bohatší zkušenost zákazníka Co mají tyto příklady společné? Koncovým uživatelům přinášejí méně problematické a bohatší možnosti v souladu s kontextem, v němž se tito uživatelé právě nacházejí. Jinými slovy, v architektuře SOA jde o vztahy, nikoli o technologii. Koncoví uživatelé si nelámou hlavu s mechanismem poskytování služeb, ale zajímají se o to, co se děje online. Jakmile získali se SOA zkušenosti, očekávají (a věří), že příslušné online služby budou spolehlivě k dispozici a průběžně se budou přizpůsobovat jejich požadavkům tak, aby jim poskytovaly širší možnosti a bohatší prožitek při jejich užívání. Výsledkem je, že potřebujeme změnit způsob, jakým se IT vyvíjí a spravuje.

Kontinuální služba Úspěch SOA se dostaví v okamžiku, kdy IT oddělení dokáží poskytovat přizpůsobitelné a stále se rozšiřující možnosti SOA uživatelům tak, aby uspokojili jejich očekávání. To znamená, že IT oddělení by měla přestat přemýšlet o vydávání nových softwarových verzí podle termínů v kalendáři, ale začít poskytovat dynamický kontextuální uživatelský prožitek jako kontinuální službu. Získávat zákazníky potřebují společnosti každý den. Představte si špičkového dodavatele nástrojů pro automatizaci prodeje, který je jedním z pionýrů obchod12


ního modelu software jako služba SaaS (Software as a Service). Společnost přestává periodicky vydávat jednotlivé softwarové verze, ale přizpůsobuje své služby specifickým potřebám uživatelů v daném okamžiku – a software vylepšuje průběžně.

Hodnototvorný řetězec Co dalšího mají všechny výše uvedené příklady společného? SOA komunity vytvářejí hodnototvorný řetězec na různé úrovni, přičemž každý člen nebo služba inkrementálně přidává další hodnotu a rozšiřuje nebo obohacuje možnosti a prožitek koncového uživatele. V prvním příkladě se vytváří SOA komunita společností poskytujících finanční 13


služby, v níž přidává hodnotu každý účet, který přibude na stránku s informacemi o osobním portfoliu. Následující příklady vytvářejí kompletní vertikální hodnototvorný řetězec: například aerolinky odkazují na cestovního agregátora, který se naopak stává komponentou dalších přidružených webů. Výsledkem takového hodnototvorného řetězce jsou narůstající a rozšiřující se možnosti, které se mohou postupem času navíc měnit s tím, jak se mění celkový kontext. V každém případě platí, že ať už jsou členové komunity různé interní týmy, nebo nezávislé společnosti, jejich interakce jsou federované. A je důležité pochopit, které technologie a řídicí postupy jsou pro realizaci těchto propojení a pro celkový úspěch SOA nepostradatelné.

Federované interakce Na tzv. federované interakce (z angl. „federated interactions“ – tj. interakce, jejichž správa je rovnovážně rozdělena mezi lokální a centrální řízení, viz dále) lze pohlížet ze dvou úhlů: podle technického charakteru servisně orientované architektury a komunitního charakteru sociálně orientované architektury. Oba pohledy přitom spolu souvisejí – technické charakteristiky umožňují a podporují rozvoj komunitní dimenze sociální struktury SOA a naopak – členové sdružení vyžadují, aby specifické technologie a řídicí postupy společně a úspěšně fungovaly (viz obr. 3). Technický charakter

Komunitní charakter

•

Heterogenní systémy

•

Bojuje s diverzitou

•

Volně provázané transportní vazby

•

Předvídá a přeje si neočekávané vztahy

•

Nezávislé bezpečnostní domény

•

Chrání suverenitu jednotlivců a členů

•

Procesy řízené událostmi

•

Spolupracuje jako „virtuální“ tým

•

Flexibilní, standardní sémantika

•

Nové vazby založené na důvěře a závazcích

•

Sdílí společný slovník

Servisně orientovaná architektura

Sociálně orientovaná architektura

Obrázek 3: Technická a sociální dimenze federovaných interakcí

14


Z technického hlediska sestává servisně orientovaná architektura z heterogenních systémů s nezávislými bezpečnostními doménami – jako sociální struktura totiž SOA zahrnuje různé členy ovládající jejich vlastní domény, což zahrnuje i vlastní výběr platformy a zabezpečení. Integrace heterogenních systémů vyžaduje standardizované, volně provázané transportní vazby, které fungují během provozu. Pokud by se integrační prvky pevně „zadrátovaly“ už v návrhu, každá změna by vyžadovala změnu návrhu a nový zdrojový kód. Volně provázané transportní vazby podporují otevřenost sociálně orientované architektury umožňující předvídat vznik neočekávaných vztahů a vazeb. Avšak jak tyto nezávislé domény přinutíte spolupracovat jako virtuální tým a sdílet společný slovník – aby bylo možné optimalizovat výkonnost v provozním prostředí a zároveň prosazovat bezpečnost v celém rámci SOA? Právě to je totiž nepostradatelná podmínka toho, aby členové SOA mohli účinně a efektivně fungovat. SOA prochází napříč celou organizací, takže centralizované příkazy a řízení shora dolů nebudou fungovat. Jednotlivé domény budou řídit svůj díl procesu (nebo budou vyžadovat, aby jim byla tato kontrola přidělena – jako v případě pracovních buněk u výrobce letadel). Proto sociálně orientovaná architektura potřebuje konsenzuální formu governance – založenou na kontraktech a opírající se o bezpečnostní politiky a dohody

15


SLA. Dohled nad plněním odsouhlasených kontraktů a jejich prosazování pak pomohou vybudovat důvěryhodné vztahy. Jinými slovy – ve sdružení založeném na SOA (oproti tradičnímu hierarchickému řízení IT) si domény udržuji vliv na klíčové funkce, ale určitou část kontroly předávají centralizovanému orgánu. Ten řídí funkce, které probíhají napříč hranicemi uvnitř SOA a propojují je. Jde například o integraci služeb, zajištění výkonnosti pracovních procesů, bezpečnost a přesnou výměnu dat. Tato rovnováha mezi centrálním a lokálním řízením se může měnit podle potřeb SOA. Pro zajištění svrchovanosti domén a akceschopnosti SOA na jedné straně a spolehlivé spolupráce na straně druhé však musí vždy existovat nějaká dělba moci.

Výsledný požadavek na řízení Pro praktickou implementaci SOA mají koncept federace a charakter federovaných interakcí zřetelné důsledky. Zaprvé SOA vyžaduje změnu řízení: • přestaňte uvažovat o SOA governanci v kontextu konvenčních hierarchických organizačních modelů, • začněte smazávat tradiční linie moci a vedení a orientujte se na spolupráci, budování důvěry a závazky plynoucí ze smluv SLA. Spolupráce založená na smlouvách SLA umožňuje využití stejných mechanismů pro insourcing i outsourcing služeb. Výsledkem je optimální akceschopnost a produktivita (jak ukazuje příklad s výrobcem letadel). Tento přístup funguje rekurzívně na úrovni pracovní buňky, úrovni oddělení, úrovni divize, úrovni společnosti – i na ještě vyšší úrovni, kde umožňuje sloučení, akvizice i rozdělení společností a realizaci partnerských vztahů a aliancí. Zadruhé federace vyžaduje i klíčové „umožňující“ (enabling) technologie: takové, které překračují hranice heterogenních systémů a podporují spolupráci a SOA governanci. Jak bylo řečeno výše, tato infrastruktura SOA musí: • Volně propojovat interakce. Hledejte platformu pro distribuci zpráv a událostí, která je navržena tak, aby překračovala hranice platforem, sítí a organizací. • Aktivně zprostředkovat politiky. Hledejte technologii, která poskytuje přehled o pracovní výkonnosti, prosazuje soulad s bezpečnostní politikou a smlouvami SLA pokrývajícími SOA procesy a upozorňuje na rozpory s touto politikou a smlouvami. • Přesně kontrolovat sémantiku. Pro řešení sémantických nekonzistencí hledejte technologii, která vám prostřednictvím vizuálních nástrojů umožní vytvářet a řídit komplexní, sdružený, společný datový model – a umožní, aby tato sémantika fungovala v distribuovaném provozním prostředí. Toto jsou základní předpoklady pro sdružování a spolupráci, které mohou splnit 16


pouze takové softwarové produkty, které jsou od základu určeny pro integraci a propojení různých výpočetních prostředků.

SOA dnes a zítra Tyto kritické technologie a požadavky na řízení budou hrát stále větší roli. V budoucnu bude úspěch podniku záviset na schopnosti začlenit jeho činnosti elektronicky do hodnototvorného řetězce (což mu umožní participovat v servisně orientované architektuře). Tak se může podílet na nové, dynamičtější a bohatší zkušenosti federované komunity založené na sociálně orientované architektuře. Příklady raného využívání architektur SOA ukazují, že výsledkem dalšího rozvoje SOA jsou nové, jedinečné příležitosti a zisky. SOA zapouští kořeny právě nyní – a postupuje rychle. 17


Průzkumy ukazují, že během následujících dvou let dojde ke zdvojnásobení počtu aplikací založených na SOA. Součástí tohoto posunu bude začlenění i jiných existujících architektur do SOA. V tuto chvíli jsou k dispozici tři kriticky důležité technologie – konektivita, prosazování politik a sémantika, které fungují v rámci SOA jako funkce a/nebo služby. V budoucnosti budeme svědky zrodu infrastruktury typu „integrace jako služba“ vestavěné do hardwaru nebo nabízené jako spravované služby. Schopnosti, jako je například analýza, budou nabízené jako služba v reálném čase. Významná telekomunikační společnost už dnes vyrábí zařízení s vestavěnými funkcemi pro integraci založenou na SOA. Toto zařízení umístěné ve vašem sklepě vás propojí se službami poskytovanými v rámci sítě této společnosti.

Shrnutí: začněte se změnami Nejlepší cestou jak začít je praktický přístup. Začněte s projektem změn podnikových činností, nejlépe v inovativní části vašeho podnikání. Tak se můžete něco naučit o SOA a vyzrát. Aplikovat tyto změny na velké, základní podnikové systémy, které udržují kontinuitu a stabilitu podnikání, je v začátcích realizace SOA méně vhodné. Inovativní oblasti jsou také vhodnější pro aplikaci změn řízení IT, které jsou potřebné pro úspěšný vstup do SOA komunity. K nim patří nepřetržité zdokonalování služeb místo softwarových verzí vydávané k určitému termínu a spolupráce s federovanou komunitou místo hierarchického modelu řízení shora dolů. Pro úspěšnou technickou federaci jsou kritickými faktory úspěchu konektivita, možnost prosazování politik a sémantická integrace. Zvolte si nejlepší SOA řešení ve své kategorii navržené tak, aby bylo maximálně přizpůsobitelné – nikoli platformu nebo uzavřené produkty, které vás uzamknou ve svém prostředí. S takto vybudovanými základy se můžete stát součástí dynamičtějšího prostředí sociálně orientované architektury postaveného na interakcích – a využívat jeho rostoucí příležitosti a výhody.

18

Slovníček pojmů

Servisně orientovaná architektura SOA (service-oriented architecture) SOA je souhrn nejlepších postupů (best practices), které si daná organizace zvolila pro budování či integraci svého informačního systému a představuje další fází vývoje trhu podnikových aplikací. Jde o koncept, který uvažuje o softwarových prostředcích jako o službách dostupných kdekoliv na síti. Tento koncept je založen na několika elementárních zásadách (kontrakt služeb, volná vázanost, kompozice služeb, autonomie a bezstavovost služeb, znovupoužitelnost, úložiště metadat). Aplikací těchto zásad je integrační (nebo aplikační) logika orientovaná na poskytování služeb. Čím více částí takto orientované logiky dané řešení obsahuje, tím více se stává servisně orientovaným. Nutno poznamenat,že SOA není ani konkrétním produktem ani konkrétním oborovým standardem, nelze ji ani koupit, je nutné ji postupně vybudovat.

Sociálně orientovaná architektura (socially oriented architecture) Servisně orientovaná architektura přináší i další, sociální (myšleno komunitní) rozměr. Vytváří totiž nejen vztahy mezi službami, ale také mezi společnostmi, resp. mezi lidmi – uživateli z daných společností. Obchodně spřátelené společnosti mohou utvářet specifická SOA společenství. Vzniká tak hodnototvorný řetězec, do něhož každý člen společenství (resp. každá jeho služba) přidává určitou hodnotu obohacováním/rozšířením o možnosti (a zkušenosti) koncových uživatelů. Softwarové služby, které jednotliví členové nabízejí, se navíc mohou stát obchodovatelnou komoditou, přičemž každý z uživatelů může mít nastaveny jiné obchodní podmínky využívání těchto služeb. Zákazníci využívající SOA tak získají možnost zapojit se do mnohem většího a dynamičtějšího komunitního společenství (lhostejno zda čistě vnitřního nebo i vnějšího), které může jejich podnikání akcelerovat.

Komunita vlastníků služeb (service owner community) Zatímco dřívější technologie, jako jsou mainframy, klient/server i webové aplikace, interagují s jedním subjektem, architektura SOA vytváří mnohostranné interakce. Na základě těchto interakcí vznikají komunity více či méně nezávislých vlastníků služeb, kteří v příslušném kontextu dynamicky spolupracují, společně nabízejí své služby a zprostředkovávají bohatší zákaznický prožitek při jejich využívání. Pro zajištění svrchovanosti domén a akceschopnosti SOA na jedné straně a spolehlivé spolupráce na straně druhé však musí vždy existovat nějaká dělba moci. V takové federaci založené na SOA (oproti tradičnímu hierarchickému řízení IT) si domény udržuji vliv na klíčové funkce, ale určitou část kontroly předávají 19

Slovníček pojmů

centralizovanému orgánu. Ten řídí funkce, které probíhají napříč hranicemi uvnitř SOA a propojují je. Jde například o integraci služeb, zajištění výkonnosti pracovních procesů, bezpečnost a přesnou výměnu dat.

Hodnototvorný řetězec (supply chain) Vlastníci služeb spojení ve federaci založené na SOA mohou propojovat nabízené služby do hodnototvorného řetězce. V něm může každá služba zároveň zprostředkovávat funkce dalších služeb. Výsledkem je širší uživatelská zkušenost a bohatší prožitek zákazníků, kteří mají k dispozici obsáhlejší nabídku služeb, které na sebe logicky navazují.

Federovaná architektura (federated architecture) Způsob organizace distribuovaného výpočetního prostředí, v kterém dochází jak k autonomnímu zpracování dat v geograficky vzdálených místech, tak zároveň k výměně dat mezi centrálním řešením a touto autonomní jednotkou.

Federované interakce (federated interactions) Interakce mezi jednotlivými členy komunity vlastníků služeb a jejich službami, jejichž správa je rovnovážně rozdělena mezi lokální a centrální řízení.

Software jako služba SaaS (Software as a Service) Obchodní model, který umožňuje zákazníkovi využívat aplikační softwarovou funkcionalitu na dálku jako službu aniž by vlastnil licenci na příslušný software. Výše platby za plnění služby se vždy odvozuje z klíčových obchodních parametrů zákazníka (např. počet objednávek, velikost obratu apod.), tj. z hodnoty či přínosu, které zákazník získá z užívání služby – není tedy postavena na ceně za licenci. Základním principem SaaS je sdílení rizik a odměn plynoucích z podnikání zákazníka, a to neměnným způsobem od začátku do konce trvání obchodního vztahu. Dodavatel společně se zákazníkem nese rizika spojená s podnikáním zákazníka, ale zároveň se podílí na výnosech z tohoto podnikání. Stanovení výše plateb odvozené z hodnoty či přínosu služby pro zákazníka vychází ze dvou veličin: hodnotové metriky (value metric) a objemu za metriku (amount per metric).

20

Informační zdroje

Internetové zdroje • http://www.progress.com/progress_software/products/docs/socially-orien-

ted-architecture-ebook.pdf – průvodce komunitně orientovanou architekturou • http://www.sonicsoftware.com/solutions/soa_enterprise/service_orien-

ted_architecture/soa_maturity_model/index.ssp – model zralosti SOA • http://www.enterpriseintegrationpatterns.com/ – integrační vzory

Analytické zprávy • IDC Opinion, Western European Market Preliminary Forecast: Services

Automation and Management for SOA, 2006–2010 • CurrentAnalysis, B. F. Shimmin, The Changing Role of Service-Oriented

Architecture, 10/2007 • The Forrester Wave: Standalone SOA And WS Management Solutions, 10/2007 • Gartner Magic Quadrant for Integrated SOA Governance Technology Sets,

11/2007 • Gartner – J. Thompson, Management Update, Predicts 2006: The Strategic

Impact of SOA Broadens • Burton Group, A. T. Manes, Service-Oriented Architecture: Developing the

Enterprise Roadmap, 06/2006

Materiály Progress Software • Produktové listy Sonic ESB, Actional a DataXtend Semantic Integrator

Knihy • D. A. Chappell, Enterprise Service Bus, O’Reilly, ISBN 0–596–00675–6 • Thomas Erl, Service-Oriented Architecture, Prentice Hall, ISBN

0–13–185858–0 • Jason Bloomberg, Ronald Schmelzer, Service Orient or Be Doomed!, Wiley,

ISBN 0–471–76858–8

Informační zdroje

Kontakt Jinřich Štumpf, Business Consultant Progress Software ČR, Michelská 60/300, 140 00 Praha 4 tel.: +420 241 095 223 e-mail: [email protected]

Reference 1 Market Assessment, B. Shimmin, August 07, 2007, Module: Application Infrastructure 2 SOA: Developing the Enterprise Roadmap, Anne Thomas Manes, 07/2006 3 Enterprise Service Bus, D. A. Chappell, O`Reilly Media, 06/2004 4 Parafráze citátu „You only need one service to need governance. You only need one service to destroy your business.“ Daryl Plummer, Managing VP, Gartner Inc. 5 Socially Oriented Architecture, Hub Vandervoort, CTO Progress Software

22

Poznámky

23

Na obsahu brožury se podíleli odborníci společnosti Progress Software Hub Vandervoort a Jindřich Štumpf.

Prod code: CZ08-04-03-009-Rev0

Sociálně (komunitně) orientovaná architektura

Recommend Documents