Integrace SaaS: Obtížná, avšak zvládnutelná

Potřeba výměny dat mezi různými hostovanými aplikacemi (jedná se například o zpracování transakcí, řízení vztahů se zákazníky, tisk materiálů, platební systémy apod.) však vytvořila spletitou integraci založenou na webu a propojující systémy SaaS navzájem (SaaS to SaaS) a také SaaS řešení s vlastními aplikacemi.

A to představuje záludnost řešení SaaS: Zavedete příliš mnoho aplikací a zjistíte, že jste na tom jako za starých špatných časů, kdy spolu různé aplikace podnikové infrastruktury nedokázaly efektivně komunikovat. „Pokud zavedete systémy SaaS do své infrastruktury ve vysoké míře, dostanete se do opět situace zamotané datové struktury,“ vysvětluje Benny Lasiter, architekt podnikových systémů ve firmě Hines Real Estate Securities.

V mnoha organizacích nabídky SaaS proniknou do oddělení jednotlivých podnikových útvarů, ale často bez znalosti pozadí firemního IT. Nevyzpytatelné projekty se v podniku stanou tzv. SaaS profilem, jak uvádí Ron Papas, viceprezident společnosti Informatica. Později, jak se tyto aplikace rozmnoží a vyrostou, nastanou problémy. „Uděláte to jednou, dvakrát a potom pětkrát – a tato nesourodá řešení stále hlouběji pronikají do IT infrastruktury. Bez strategie, bez konzistence, takže velmi brzo vzniká problém,“ uvádí Benoit Lheureux, analytik společnosti Gartner. „Většina společností vůbec netuší, že by měly mít strategii pro integraci SaaS a koordinovat ji se svou vlastní interní integrační strategií B2B. To pak představuje obrovskou potíž.“

Nemusíte na to však být sami. Jak IT manažeři pracují se svými propletenci SaaS, vytvářejí nové integrační strategie. Přitom jim pomáhají nové nástroje i specialisté na integraci.

Možné komplikace
Věci se však mohou zvrtnout, i když se podaří aplikace SaaS integrovat se zbytkem infrastruktury. Společnost Pervasive Software uvádí následující tři nejčastější problémy.

1. Nové funkce zvednou laťku: Dodavatel SaaS přidá nové funkce, které byste chtěli používat.
Příklad: Dodavatel nabízí podrobnější reporting, ale aby se toho dalo využít, je nutné změnit již vytvořené pracovní toky.

2. „Vylepšení“ rozhraní API dodavatele SaaS: Poskytovatelé SaaS řešení mohou revidovat rozhraní API (aplikační programové rozhraní) několikrát ročně, a to může způsobovat problémy při realizaci vlastní integrace.

Příklad: Outbound messaging je mechanizmus oznamující jiné aplikaci, že nastala změna dat vyžadující aktualizaci na její straně. „Dodavatelé SaaS museli z různých důvodů změnit způsob sdělení této informace okolnímu prostředí,“ uvádí David Inbar, ředitel marketingu ve firmě Pervasive Software. To vynucuje změny, které se mohou zdát malými detaily, ale stále vyžadují opravy v procesu integrace či mapování.

Společnost Salesforce.com se snaží, aby aktualizace jejího řešení neporušily způsob, jakým její rozhraní API zpracovává transakce. „K selhání funkcionality by mohlo dojít, pokud bychom změnili chování volání API. Pokud by to pracovalo jinak, příslušný integrační kód zákazníků by nevěděl, co má dělat,“ říká Ariel Kelman, ředitel marketingu produktů v organizaci Salesforce.com. Tato firma udržuje staré verze rozhraní API on-line, aby takovým problémům předešla.

3. Sebepoškození: Provedení změn ve vlastních podnikových procesech, které naruší systém.
Příklad: Vytvoříte systém pro zpracování objednávek a potom se rozhodnete rozdělit pracovní postup v závislosti na velikosti zákazníka (zvlášť pro malé a pro velké), změnit proces a toky informací přes jedno nebo více řešení SaaS či přes interní aplikace.

Potřebná strategie
„Je nezbytné mít centrálního architekta s celkovým přehledem o datech, někoho, kdo rozumí v podstatě všemu z hlediska provozu firmy i z hlediska technické implementace procesů,“ říká Lasiter. Jinak neočekávané problémy určitě nastanou.

Většina integračních projektů ohledně řešení SaaS se týká tzv. backendových aplikací, jako jsou například finanční systémy. Jak se počet takových propojení ustavičně rozšiřuje, je centrální systém stále více zahlcován. „Často se výkon příslušné finanční aplikace nečekaně sníží, protože k ní jsou všechny tyto systémy naráz připojeny,“ vysvětluje Rick Nucci, technologický ředitel ve společnosti Boomi, která dodává integrační nástroje. „Je to jako za časů integrace podnikových aplikací. Vznikne efekt špagetového kódu.“

Flexibilita SaaS a schopnost v případě potřeby rychle změnit dodavatele rovněž vytváří výzvy, jako je například sloučení nových aplikací typu SaaS se starými daty. Lasiter třeba obměnil dodavatele SaaS v květnu loňského roku. „Když jsme pak prováděli uzávěrku vztahující se ke konci finančního roku, měli jsme data od dvou dodavatelů. Oboje bylo nutné sloučit za účelem vytvoření výroční zprávy,“ dodává. Vysvětluje, že ve světě SaaS probíhají neustálé změny. Je na IT odděleních odpovídajících organizací všechny tyto pohybující se fragmenty zvládnout.

Popisovaným problémům lze však předejít využitím integrační strategie, která zahrnuje řešení SaaS. To je však v rozporu s kulturou okamžitého „ad hoc“ nasazení, v rámci kterého jsou mnohé implementace systémů SaaS svými provozovateli prodávány.

Ad hoc není vždy špatným přístupem, jak uvádí David Inbar, ředitel marketingu ve společnosti Pervasive Software. „Může to být v rozporu s velkým množstvím učebnic o nasazování IT řešení – ale je splňuje to požadavky kupujícího – aby to proběhlo prostě rychle.“ Avšak ve velkých společnostech, kde je velké množství implementací SaaS (někdy to mohou být dokonce až stovky), mohou ad hoc projekty v konečném důsledku vytvořit relativně značný chaos.

Lasiter uvádí, že strukturované prostředí pro integraci se u nich vytvořilo postupně. Společnost Hines použila model SaaS především kvůli tomu, že podnikání v oblasti nemovitostí muselo začít fungovat rychle. Potřebovali flexibilní systém, který by umožnil rychlé změny, protože podnikové postupy se stále vyvíjely.

Lasiter také chtěl mít všechna data pro účely reportingu v běžném úložišti, takže se rozhodl vytvořit ve vlastní režii databázi, která by sloužila jako základní archiv a dohled nad provozem při výměně dat. K vytvoření integračních propojení pak použil nástroj od společnosti Pervasive. „Vytvořili jsme izolační vrstvu integrací, která nám umožňuje udržovat centrální středisko dat pro účely reportingu,“ pochvaluje si. Tento návrh umožňuje firmě Hines velmi snadno měnit dodavatele SaaS.

„Nepokoušeli jsme se to zvládnout vše najednou,“ popisuje. Namísto toho společnost Hines přidávala integrační funkci postupně jednu po druhé po dobu dvou a půl roku. Přibližně 20 % práce představovalo programování. Zbytek bylo definování podnikových procesů, analýza dat a zjišťování požadavků na reporting.

Zatímco společnost Hines použila vlastní middleware, mezi jinými společnostmi jsou populární i nabídky IAS (Integration as a Service) od dodavatelů, jako jsou Boomi nebo Informatica. Poskytují obecné integrační centrum pro všechny typy integrace SaaS–SaaS a SaaS–vlastní systémy.

„Hlavním důvodem pro použití hostovaných integračních nástrojů je rychlý vývoj,“ uvádí Papas. Zatímco vlastní software bývá aktualizován každých 12 až 18 měsíců, dodavatelé SaaS mohou své produkty revidovat třikrát ročně nebo dokonce ještě častěji. Dodavatelé řešení IAS dokáží pomoci zajistit, že upravené aplikace SaaS budou pro zákazníky stále funkční.

Saudskoarabská společnost Zamil Industrial ITG, která vyrábí stavební produkty, neměla žádné problémy s integrací svého middlewaru SOA s aplikací pro správu služeb od firmy Service-now.com. „Middleware Oracle Fusion jsme v podniku implementovali dříve, než jsme přešli k řešením společnosti Service-now.com,“ uvádí Ahmed Abdrabalnabi, manažer plánování služeb ve společnosti Zamil. Integrace s informacemi o zaměstnancích uložených ve službě MS Active Directory a ve vlastních aplikacích personálního oddělení byla stejně snadná jako vypít sklenici vody.“ Proces trval jen pár dní, a to díky tomu, že požadavky na integraci byly vyhodnoceny hned na počátku, aby se zjistilo, zda je produkt od Service-now.com pro naše účely vhodný.

Pro většinu integračních projektů je však časový rámec, který se podařil při implementaci ve společnosti Zamil, příliš optimistický. V přibližně 80 % případů se pro propojení používá základní technologie, jako jsou přenosy souborů, přičemž projekty s aplikacemi SaaS se nasazují rychleji než za 12 až 18 měsíců, což je doba obvyklá při u tradičních vlastních aplikací, jak srovnává Annrai O'Toole, viceprezident integrací ve společnosti Workday, která je poskytovatelem hostovaných aplikací. Přesto však typický projekt integrace se systémy společnosti Workday, včetně migrace a vyčištění dat, specifikací podnikových procesů a konfigurace systémů, stále trvá okolo 70 dní.