Sociálně (komunitně) orientovaná architektura

Transkript

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

2 Obsah oučasná řešení OA 3 Povaha a skladba řešení OA 3 Podmínky úspěšné implementace OA 3 Nemalé investice se vyplatí 4 Architektura je zásadní prvek 4 oftware as a ervice 5 Otázky potenciálního zákazníka 7 ociálně (komunitně) orientovaná architektura 8 Komunity vlastníků služeb 8 Technické příležitosti, komunitní výzvy 8 Faktory úspěchu OA 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 OA dnes a zítra 17 hrnutí: začněte se změnami 18 lovníček pojmů 19 Informační zdroje 21 Kontakt 22 Reference 22

3 oučasná řešení OA Povaha a skladba řešení OA Trh s řešeními OA 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é OA ř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é infra struk tury OA 1. Podmínky úspěšné implementace OA 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 OA 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 OA nelze koupit, je možné ji pouze vybudovat 2. Její vybudování nespočívá v trojím kliknutí myší, což by si mohli myslet ti, kteří se OA zatím nic praktického nezkusili. OA 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

4 oučasná řešení OA služeb - EB (Enterprise ervice Bus 3 ). EB nepředstavuje bohužel žádný oborový standard, takže jsou za EB č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 OA 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í OA 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 OA 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 oftwaroví dodavatelé nezřídka pomíjejí to zásadní v OA a tím je A tedy architektura. (Vývoj architektur podnikových informačních systémů přibližuje 4

5 Akcescchopnost podniku oučasná řešení OA Událostně řízená OA Objednávky ERP CRM Dodávky ERP Fakturace WM FIN EB Tradiční OA Hub & poke A Point-to-point A G 1980 C 1990 D G F D F C B H Dávky B H CRM ERP WM FIN E E Čas Obrázek 1: Vývoj architektur od dávkového zpracování k událostně řízené OA 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 OA, tak další praktické aspekty zmiňované v úvodu. tejnou flexibilitu, kterou OA poskytuje softwarovým aplikacím, musí poskytnout i všechny spodní vrstvy OA, resp. celá výpočetní infrastruktura. Dynamická virtualizace zdrojů se ukazuje jako technicky životaschopné řešení, působí však potíže OA 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. oftware as a ervice Odpovědí některých dodavatelů je zásadní změna licencování využitím modelu aa (oftware as a ervice). 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

6 oučasná řešení OA měřuje-li tento obchodní model spíše do hardwarové infrastruktury či outsourcingu/outhostingu, uplatňuje se zde model označován jako Xaa (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ěčů OA 1. Zejména z pohledu servisně orientované integrace se implementace principů OA 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

7 oučasná řešení OA 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 OA, když všichni deklarují, že jejich přístup z principů OA 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í OA zákazník ptát svého potenciálního dodavatele OA: Jak mi zaručíte, že deklarované přínosy skutečně nastanou i v mém případě? Pomůže mi OA spíše ušetřit nebo více vydělat či obojí? Zvládnu OA 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 OA 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 OA na moje obchodní partnery? 7

8 ociálně (komunitně) orientovaná architektura 5 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 OA 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í OA 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 OA: 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 OA se týkají technologií, výzvy OA se týkají lidí (viz obr. 2). Příležitosti Integrace Integrace Bezpečnost Akceschopnost Governance Opakované použití Vlastnictví ervisně orientovaná architektura ociálně orientovaná architektura Obrázek 2: Vazby mezi servisně orientovanou a sociálně (komunitně) orientovanou architekturou 8

9 ociálně (komunitně) orientovaná architektura 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 OA 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

10 ociálně (komunitně) orientovaná architektura Aktivní sjednávání pravidel. ilné 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

11 ociálně (komunitně) orientovaná architektura 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í. oftwaroví 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 OA 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 onopa a Napa. Pro návštěvníky těchto webů je OA 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

12 ociálně (komunitně) orientovaná architektura 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 OA 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 OA komunity na nové inovativní úrovni a zásadně přepracoval své výrobní postupy. polečnost vytvořila dodavatelský řetězec OA, 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. poleč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 OA 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 OA 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 OA se dostaví v okamžiku, kdy IT oddělení dokáží poskytovat přizpůsobitelné a stále se rozšiřující možnosti OA 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ů obchod- 12

13 ociálně (komunitně) orientovaná architektura ního modelu software jako služba aa (oftware as a ervice). poleč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? OA 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áří OA komunita společností poskytujících finanční 13

14 ociálně (komunitně) orientovaná architektura 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 OA 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é architek tury. Oba pohledy přitom spolu souvisejí technické charakteristiky umožňují a podporují rozvoj komunitní dimenze sociální struktury OA 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 Volně provázané transportní vazby Nezávislé bezpečnostní domény Procesy řízené událostmi Flexibilní, standardní sémantika Bojuje s diverzitou Předvídá a přeje si neočekávané vztahy Chrání suverenitu jednotlivců a členů polupracuje jako virtuální tým Nové vazby založené na důvěře a závazcích dílí společný slovník ervisně orientovaná architektura ociálně orientovaná architektura Obrázek 3: Technická a sociální dimenze federovaných interakcí 14

15 ociálně (komunitně) orientovaná architektura 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ž OA 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 OA? Právě to je totiž nepostradatelná podmínka toho, aby členové OA mohli účinně a efektivně fungovat. OA 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

16 ociálně (komunitně) orientovaná architektura LA. 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 OA (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ř OA 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 OA. Pro zajištění svrchovanosti domén a akceschopnosti OA 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 OA mají koncept federace a charakter federovaných interakcí zřetelné důsledky. Zaprvé OA vyžaduje změnu řízení: přestaňte uvažovat o OA 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 LA. polupráce založená na smlouvách LA 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 OA governanci. Jak bylo řečeno výše, tato infrastruktura OA 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 LA pokrývajícími OA 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

17 ociálně (komunitně) orientovaná architektura pouze takové softwarové produkty, které jsou od základu určeny pro integraci a propojení různých výpočetních prostředků. OA 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 OA ukazují, že výsledkem dalšího rozvoje OA jsou nové, jedinečné příležitosti a zisky. OA zapouští kořeny právě nyní a postupuje rychle. 17

18 ociálně (komunitně) orientovaná architektura Průzkumy ukazují, že během následujících dvou let dojde ke zdvojnásobení počtu aplikací založených na OA. oučástí tohoto posunu bude začlenění i jiných existujících architektur do OA. 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 OA 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. chopnosti, 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 OA. 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. hrnutí: 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 OA 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 OA méně vhodné. Inovativní oblasti jsou také vhodnější pro aplikaci změn řízení IT, které jsou potřebné pro úspěšný vstup do OA 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ší OA ř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í. 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

19 lovníček pojmů ervisně orientovaná architektura OA (service-oriented architecture) OA 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 do stup ný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 bezsta vovost 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 OA není ani konkrétním produktem ani konkrétním oborovým standardem, nelze ji ani koupit, je nutné ji postupně vybudovat. ociálně orientovaná architektura (socially oriented architecture) ervisně 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á OA 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ů. oftwarové 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í OA 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 OA 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 OA 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 OA (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

20 lovníček pojmů centralizovanému orgánu. Ten řídí funkce, které probíhají napříč hranicemi uvnitř OA 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 OA 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í. oftware jako služba aa (oftware as a ervice) 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 aa 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í. tanovení 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

21 Informační zdroje Internetové zdroje průvodce komunitně orientovanou architekturou model zralosti OA integrační vzory Analytické zprávy IDC Opinion, Western European Market Preliminary Forecast: ervices Automation and Management for OA, CurrentAnalysis, B. F. himmin, The Changing Role of ervice-oriented Architecture, 10/2007 The Forrester Wave: tandalone OA And W Management olutions, 10/2007 Gartner Magic Quadrant for Integrated OA Governance Technology ets, 11/2007 Gartner J. Thompson, Management Update, Predicts 2006: The trategic Impact of OA Broadens Burton Group, A. T. Manes, ervice-oriented Architecture: Developing the Enterprise Roadmap, 06/2006 Materiály Progress oftware Produktové listy onic EB, Actional a DataXtend emantic Integrator Knihy D. A. Chappell, Enterprise ervice Bus, O Reilly, IBN Thomas Erl, ervice-oriented Architecture, Prentice Hall, IBN Jason Bloomberg, Ronald chmelzer, ervice Orient or Be Doomed!, Wiley, IBN

22 Informační zdroje Kontakt Jinřich Štumpf, Business Consultant Progress oftware ČR, Michelská 60/300, Praha 4 tel.: jindrich.stumpf@progress.com Reference 1 Market Assessment, B. himmin, August 07, 2007, Module: Application Infrastructure 2 OA: Developing the Enterprise Roadmap, Anne Thomas Manes, 07/ Enterprise ervice Bus, D. A. Chappell, O`Reilly Media, 06/ 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 ocially Oriented Architecture, Hub Vandervoort, CTO Progress oftware 22

23 Poznámky 23

24 Na obsahu brožury se podíleli odborníci společnosti Progress oftware Hub Vandervoort a Jindřich Štumpf. Prod code: CZ Rev0