Naše děti takové problémy nemají. Když jsem docela nedávno dostal od zaměstnavatele svůj první dotykový mobil, volal jsem dceři na rande, co mám dělat, aby se mi na displeji objevila klávesnice a já mohl vytočit číslo. Takovýto otravní jsme. My, co jsme zažili léta v IT, a všechno za našich časů fungovalo. V tomto příspěvku zkusím přispět k tomu, abychom za pár let nebyli našimi šikovnějšími mladými „ajťáky“ posílání do muzea anebo rovnou do hrobu.

Současné teorie o řízení IT dobře shrnuje rámec ITIL, který popisuje, jak musí být jakákoliv služba nejprve strategicky promyšlena (Service Strategy), pak navrhnuta (Service Design), přesunuta do živého prostředí (Service Transition), provozována v něm (Service Operation) a poté neustále vylepšována (Continuous Improvement). Jak tyto oblasti ovlivňuje využívání softwaru formou služby? Vezměme to popořadě.

Service Strategy a Service Design trochu jinak

Pod pojmem SaaS se skrývá celá paleta vztahů. Každá služba má interface a obvykle nejenom jeden. Tady si každý zkušenější „procesář“ povzdechne. A právem. Kde je hranice mezi tím, co spravujeme my a co spravuje dodavatel? Když budeme mít štěstí, nebudeme muset příliš myslet na správu sítí. Jednoduše přidáme pravidlo do firewallu a pak už se o to nestaráme. Co ale, když přestane fungovat spojení? Odpovědnost za všechny aspekty služeb musí být jasně stanovené ve strategii a designu. Podívejme se na tyto procesy blíže.

Finanční management je základ rozhodování o tom, co si do firmy pustíme. Když chceme porovnat, která služba formou SaaS je pro nás výhodnější, musíme uvažovat o celkové ceně za vlastnictví (Total Cost of Ownership). Takže nemůžeme brát do úvahy jenom ceny serverů, ale také lidí, kteří se o danou službu starají, jejich zázemí nebo třeba počítání výplat. To ale není všechno. Jaké prostředky vynaložíme kromě běhu služby na její zálohy, zajištění bezpečnosti a kontinuity? To vše musíme brát v úvahu.

Když nám finanční management řekne, že můžeme jít dál, ještě není ve strategické rovině vyhráno. Na úrovni procesů se SaaS přístupem moc nemění, co ale service portfolio management? Co se změní tady? Prakticky všechno. Většinu vývoje a testování můžeme zapomenout. Strategii služby sice uvažujeme, ale veškerá odpovědnost za to, co a jak zlepšíme, je na úrovni Operation, tedy u dodavatele. Znamená to sice méně starostí, na druhou stranu ale také zásadní závislost. Zda se to vyplatí, ukáže spolehlivě jen čas. Co poradit? Zvážit a rozhodnout se podle individuální situace.

Co učinit s fází designu, když službu navrhoval někdo jiný? Služba po vývoji u dodavatele nějak vypadá, ale my musíme vyřešit ještě mnoho věcí. Třeba dostupnost služby a zajištění kapacity a výkonu, které se pro tento případ sbíhají v Service Level Managemenu. Musíme získat garance, že služba bude fungovat pro naše plánované potřeby a námi očekávaným způsobem. To sice není nic nového, ale rozdíl je v tom, že tyto parametry musíme nastavit přesně a dostatečně, protože do detailů případných problémů neuvidíme. Musíme se ujistit, že dodavatel bude schopen naše požadavky ustát ještě předtím, než s ním podepíšeme smlouvu. Design musí být naprosto přesný, protože příští změny budou složitější, než kdybychom měli službu ve vlastních rukách.

Do designu vstupují ještě některé technické faktory. Například bezpečnost (Security Management) a zajištění kontinuity činností (Service Continuity Management).

Security Management přitom bude mít trochu jiný charakter než v běžných službách. Musíme ho totiž vytáhnout do širšího prostoru, než je jenom naše vlastní firma. Když máme službu jenom v prostorách naší firmy, víme, že když vytáhneme všechny komunikační kabely a zamkneme servery, dosáhneme bezpečí. Pro SaaS to ale neplatí a nutí nás přemýšlet jinak. I pokud vyřešíme bezpečné připojování do našich prostor, stále máme data pravděpodobně někde jinde. Jak jsou chráněna? To je zajímavá a velice důležitá otázka. Víme, jak jsou chráněny prostory dodavatele a jeho servroven? Víme vůbec, ve které krajině jsou data uložena? Jsou země, kde k datům mohou volně přistupovat orgány státní moci a uložením dat v této lokalitě důvěřujeme tomu, že nebudou zneužita. Tohle je velmi důležitý faktor, který v rámci strategie a designu musíme posoudit. Spojujeme s ním svojí budoucnost. Víceméně to stejné platí i pro Service Continuity Management. Jsou služby, kde mohou být vaše data ve velice vzdálených destinacích. V případě zemětřesení „někde po cestě“ potom můžete být od služby odříznuti takovou dobu, kterou budou zákazníci vnímat jako nekonečnou. Možná tohle riziko akceptujete (z osobních zkušeností vím, že se takové situace občas stanou), ale vaše rozhodnutí musí být informované. O tom, jak je řešeno zajištění kontinuity služeb u vašeho dodavatele musíte vědět podrobnosti.

Service Transition a jeho záludnosti

Dostáváme se k zajímavé oblasti přesunu služeb do produkčního prostředí. Jak řešit její výzvy? Vidím zde především dvě zcela zásadní. První výzvou je struktura Configuration Management systému, který poskytuje logický model infrastruktury a služeb. Jsou situace, kdy je výhodné znát schéma infrastruktury u dodavatele alespoň do určité míry. Typicky pokud nějakým způsobem ovlivňuje interface mezi dodavatelem a firmou. Co se například stane, když se dodavatel rozhodne vyměnit router na své straně? Obvykle nic. Ale když ano, možná se nestačíte divit. Začnou vznikat Incidenty, o kterých nebudete nic tušit, a to je v takovém případě velmi nepříjemné. Je tedy třeba informovaně zvážit konkrétní situaci. Stejně jako v případě důležitých změn, které mohou ovlivnit dodavatelskou stranu vaší služby, možná i způsobit plánovaný anebo neplánovaný výpadek. To byste jistě udělali rádi v čase, kdy to vaše zákazníky příliš nebolí. Pokud ovšem dodavateli dáte volnou ruku, nemusí to dopadnout ve váš prospěch.

Když už jsme u těch změn, je tu ještě jeden faktor. Změny na straně dodavatele mohou přímo ovlivňovat vaše nastavení a některé změny je třeba spravovat společně. V případě SaaS si určitě tyto případy projděte s dodavatelem a přesně vymezte, co musí která strana v takových případech učinit. Na vaší straně to může posuzovat i více lidí, někdy CAB. To znamená, že takové změny musí být zdokumentovány v rozumném čase. To všechno musí být součástí smlouvy.

Service Operation

Potud jsme mluvili jenom o přípravě a plánovaných akcích. Ale ještě zajímavější je, když přijdeme k mimořádným situacím, které spolehlivě nabídne fáze Service Operation, tedy provoz služby v „živém“ prostředí. Když už nastane incident, je pozdě se dohadovat, kdo co udělá, kdy je kdo přístupný v kanceláři a na telefonu a do jaké doby jaký typ incidentu vyřeší. Tohle je důvěrně známá situace pro kohokoliv, kdo se v IT pohybuje byť jenom chvíli. Mohlo by se zdát, že SaaS v podstatě tyhle situace řeší a na tahu je dodavatel. To ovšem není zdaleka tak jasné, jak se zdá. Záleží na konkrétním případě, ale velice pravděpodobně se vaší účasti na závažných Incidentech nevyhnete. A dokonce za to ještě budete rádi, protože máte mnoho vědomostí, které pomůžou incidenty vyřešit rychleji. Řešení incidentů v režimu SaaS je složitější a úzká spolupráce s dodavatelem zaknihovaná ve smlouvě je nezbytností.

Zde se kvůli omezenému prostoru příspěvku zastavím a nepůjdu do dalších podrobností. Co říci závěrem? SaaS má určitě své místo a možná právě takovému nastavení služeb patří budoucnost. Při jejich zavádění buďme ale dobří hospodáři a nenechme se unést jejich kouzlem. Vezměme to pevně do rukou a vyhněme se nepříjemným překvapením.

Ľubomír Lukáč Autor působí jako senior business konzultant ve společnosti Anect.