Tomáš pracuje jako šéf IT architektury ve středně velké společnosti. Jeho oddělení je pod silným tlakem obchodního oddělení, které požaduje rychlé přizpůsobování IT systémů měnícím se potřebám obchodu.
Tomáš má dlouholeté zkušenosti s enterprise architekturou a strategií rozvoje IT. Z toho pramení jeho skepse vůči „módní vlně“ pod nálepkou „architektura orientovaná na služby (SOA, Service-Oriented Architecture) a Business Process Management (BPM)“, která (podobně jako některé dřívější iniciativy) slibuje vyřešit nespokojenost byznysu se schopností IT pokrýt jeho požadavky. Pojďme se podívat na některé Tomášovy námitky a pokusme se najít k nim argumenty, které by mohly jeho pochopitelnou skepsi zmírnit. Začneme jednou z definic.
SOA je IT strategie, která organizuje funkčnosti z enterprise aplikací do celků zvaných „služby“. Tyto služby jsou postaveny na standardech, mohou být opakovaně použity v různých řešeních a dají se snadno a rychle kombinovat tak, aby naplnily potřeby byznysu.
Tato koncepce představuje nový přístup k vytváření IT systémů a aplikací v enterprise měřítku – jde o posun zaměření od celých aplikací/systémů ke službám a k jejich snadnému skládání do obchodních procesů odpovídajícím reálnému byznysu firmy.
Čemu Tomáš nevěří
„Definice je to pěkná,“ namítá Tomáš, „ale nemá reálný obsah. Dnes musí mít všechno nálepku SOA, aby se to dobře prodávalo.“
Hlavním problémem dnešního IT je malá pružnost a přetrvávající vysoké náklady na vytváření, změny a integraci systémů. Každá změna v IT je drahá a pomalá – často z pohledu byznysu malý zásah znamená přepracování velkých částí IT řešení.
Jako prvotní příčina tohoto stavu byla identifikována deformace pohledu na poptávané řešení a ztráta informace při předávání od byznysu přes analýzu k vývoji. V každé fázi se řešení modeluje a popisuje jiným vyjadřovacím jazykem. Tedy i představa o něm je jiná. Byznys pak ve finále sice dostane do rukou systém, který vypadá i se chová zhruba tak, jak bylo původně požadováno. Nicméně jeho vnitřní struktura je na hony vzdálena původnímu modelu, ze kterého poptávka na řešení vzešla. Jsou tak vytvářeny systémy, které odrážejí pouze momentální stav obchodních procesů a jejich vnitřní struktura nepodporuje změnu přirozeně v místech, kde ji byznys může nejpravděpodobněji provést. Cílem tedy je tyto dva světy sladit. Jak toho dosáhnout?
Základní myšlenka je poměrně jednoduchá. Nesoustřeďme se už na systémy a aplikace. Místo toho budujme IT komponenty (služby), které odpovídají aktivitám v reálných obchodních procesech – například odeslání faktury, kontrola skladových zásob, zaevidování obchodního partnera. Procesy pak přirozeně přímočaře technicky realizujme skládáním těchto služeb – proces objednávky zboží nejprve zaeviduje partnera, zkontroluje stav zásob, vyskladní a odešle zásilku partnerovi spolu s fakturou. Dílčí kroky procesu jsou pak realizovány buď IT službami, nebo jsou zpracovávány ručně – BPM nástroje toto zpracování řídí a umožňují také procesy a jejich trendy přímo sledovat a optimalizovat.
Tomášova skepse
„Proč by ale mělo zavedení služeb pomoci? Jak vyřeší problémy IT, když žádný z dosavadních přístupů je nevyřešil?“ ptá se logicky Tomáš.
Pokud služba odpovídá obchodní aktivitě, dá se očekávat, že je-li na obchodní úrovni potřeba ji opakovaně použít, bude podobně použitelná i její technická realizace. Větší průhlednost systémů navíc znovupoužití usnadňuje – je snazší nalézt již existující funkčnosti a přesně určit, zda odpovídají novým požadavkům. Přímá technická realizace skutečných obchodních procesů pak přirozeně přináší pružnost tam, kde ji čeká byznys – sled aktivit/služeb v procesu lze snáze přeskládávat a jednotlivé kroky přeskakovat či doplňovat.
Náročnost změn realizace je pak úměrná rozsahu změn v obchodním procesu. Přidání nové aktivity realizované stávající službou je snazší než vytvoření nové služby, případně kompletní reorganizace celého procesu.
Nástroje umožňující snadné skládání služeb a tvorbu procesů, jako jsou Enterprise Service Bus, BPM engine a integrační nástroje, dovolují snadné zkombinování správně navržených služeb do nového celku.
Významná úspora je i v čase a nákladech na testování, protože služby jako samostatně definované celky jsou odděleně testovatelné. End-to-end testy pak ideálně zahrnují pouze otestování procesu nově poskládaného z již existujících služeb bez nutnosti znovu tyto služby prověřovat.
Tomášovy námitky
„Vše, co popisujete, už řešíme. Vybudovali jsme komponentový framework a integrační vrstvu, na nichž stavíme systémy. I přes všechny zkušenosti uvedené cíle není snadné naplnit. Máme vše zahodit a začít znovu?“
Problém současných komponentových řešení a Enterprise Application Integration postupů a nástrojů spočívá v soustředění na technickou realizaci problémů IT. Čili zaměření na znovupoužití komponent pro IT. Jak ale poznat, jaké komponenty vytvářet a co mají umět, aby znovupoužitelné byly? SOA poskytuje jednoduchou odpověď: „Takové, jaké jsou v reálném světě.“
U SOA nejde zdaleka jen o technologii. Velký důraz je kladen na metodologii vytváření systémů a management celého procesu tvorby systémů v IT. Jinými slovy nejde o „hračku pro techniky“, ale o větší sladění mezi byznysem a IT realizací. Pro úspěch iniciativy je vyžadována postupná změna postupů ve většině oblastí tvorby informačních systémů – od analýzy až po testy.
V technické rovině SOA přebírá klady současných úspěšných přístupů – workflow management, EAI, modulárních komponent a dalších. Jsou to například sdílení infrastruktury, unifikované zabezpečení a další. Navíc odstraňuje nedostatky proprietárních frameworků tím, že staví na standardech, což dovoluje snazší sdílení know-how, větší nezávislost na dodavateli i snazší integraci s balíkovými řešeními.
Přímo v konceptu se předpokládá znovupoužití stávajících řešení zapouzdřením již hotových funkčností v existujících systémech do služeb. Integrační nástroje pro SOA k tomu poskytují rozsáhlou podporu. Není tedy potřeba začínat na zelené louce.
Tomášovy obavy
Tomáš je ovšem zkušený a chápe, že tak velká změna není snadná: „Dobře, cíle i způsob, jak je chcete naplnit, jsou jasné. Ale umí to někdo? Špatně navržené služby nebudou opětovně použitelné. Dokonce už procesy mohou být namodelovány špatně.“
SOA a BPM přebírají přínosné myšlenky z minulosti i v oblasti analýzy. Využívají se zkušenosti s mapováním a popisem obchodních procesů, prováděných již nyní kvůli jejich zefektivnění. Výstupy Business Process analýzy poskytují popis reálných obchodních aktivit. Ty pak představují kandidáty na služby spolu s existujícími logickými funkčnostmi stávajících systémů. Mezi kandidáty se pak identifikují služby k realizaci v IT, ostatní mohou být prováděny ručně. Lze přitom definovat priority realizace těchto služeb opět v souladu s potřebami byznysu, případně podle očekávání brzké potřeby opakovaného použití. Tento postup je přirozený a známý. Novinkou je právě jeho promítnutí až do technické realizace.
Funkčnosti stávajících (i značně heterogenních) řešení je přitom možné s využitím integračních nástrojů pro Service-Oriented Architecktura do tohoto procesu zapojit. Samotní lídři na trhu SOA často získali své produkty nákupem a pohlcením jiných firem. Mohou tedy těžit z vlastních zkušeností se změnami procesů a s potřebou znovu použít a integrovat stávající řešení ve velmi heterogenním prostředí.
„Vím o firmách, které se SOA začaly a někdy jim to pojmy spíš zamlžuje a proces vývoje komplikuje,“ namítá ale Tomáš.
Problémy s pochopením celého konceptu, s nastavením nových procesů vývoje, vymezením hranic zodpovědnosti i se správným návrhem služeb jsou průvodním jevem každého nového přístupu. Iniciativy SOA počítají s tím, že zkušenosti s novým konceptem je potřeba v organizacích teprve nabýt, což se odráží i v praktických postupech pro jeho postupné zavádění.
Ve správně vedené SOA iniciativě je věnována pozornost tomu, aby nebyla nastavena nadnesená očekávání. Také jsou dnes již k dispozici školení shrnující praktické zkušenosti early adopters. Jsou zaměřena nejen na technickou oblast, ale i na organizační a architektonickou stránku realizace IT pomocí SOA.
Váhající Tomáš
Hlavní silné stránky konceptu SOA spočívají v identifikaci skutečné příčiny současného rozdílu v očekáváních byznysu a schopnosti IT naplnit je – a tuto příčinu odstranit. S jistou nadsázkou se dá říct, že díky přímočarosti této myšlenky by mělo být přirozenější vytvářet systémy podle SOA než stávajícím způsobem.
Koncept vychází z minulých zkušeností a využívá nejlepší myšlenky předchozích iniciativ. Velký důraz je kladen i na praktické postupy managementu celého procesu.
Technologie SOA staví na standardech, které vznikají dohodou nejvýznamnějších hráčů na trhu. V současnosti jsou technologickými lídry investovány značné prostředky a úsilí do rozvoje, dotažení a také standardizaci celé iniciativy.
Iniciativa SOA již překonala fázi prvotní nejistoty. Společnosti získávají praktické zkušenosti a překonávají počáteční období nutných investic do rozvoje. S tím, jak v nich postupně vznikají opakovaně použitelné služby a procesy nad nimi a SOA governance je uváděna do praxe, roste i potenciál IT a jeho pružnost. Tím se postupně zrychluje návratnost investic a pružnější IT snáze plní očekávání byznysu. Zpoždění v této oblasti se tedy může do budoucna stát významným handicapem. Otázka tedy, Tomáši, zní – můžete si takový handicap dovolit?
Autor pracuje jako Software Architect ve společnosti Cleverlance Enterprise Solutions.
PŘEDPLATNÉ
ČLÁNKY DO MAILU