Pozor, zvyk je železná košile

Ve své praxi jsme se mnohokrát setkali se situací, kdy je portálové řešení podmíněno požadavkem, aby vlastní obsah portálu byl spravován mimo něj. Stejně tak nejsou ničím neobvyklým požadavky, aby dokumenty (typicky PDF, obrázky a další) byly ukládány v relační databázi, nebo aby obsah portálu spravovaly desítky uživatelů v různých rolích včetně zastupitelnosti. Ne, to se nebavíme o úsměvných historkách z natáčení, ale o reálných požadavcích zákazníků, kteří to komentují slovy „teď to tak děláme“.

Jistě se mnou budete souhlasit, že měnit něco jen proto, aby se něco měnilo, i když to funguje, není dobrý nápad. Mluvíme ale o případech, kdy měníme nebo nasazujeme nový portál v situaci, kdy věci zcela nefungují nebo je požadovaná úprava stávajícího prostředí neúměrně drahá či prakticky nemožná. A v tomto případě je portál jako služba vítanou variantou pro obě strany.

Výhody plynou z obou stran

Zákazník se nemusí starat o technologickou stránku portálu a může se prioritně věnovat jen svým požadavkům a především pak vlastní obsah portálu vydefinovat tak, aby co nejlépe odpovídal „jeho byznysu“. Naopak dodavatel má možnost zabývat se tím, jak budou informace získávány a poskytovány, jaká bude granularita služeb, jejich způsob integrace, jak bude řešena otázka zabezpečení a přístupů, volba technologie, a to jak frontendové, tak i backendové a mnohé další. Zjednodušeně řečeno, portál jako služba dává vyniknout doménovým znalostem a kompetencím jak na straně zákazníka, tak i dodavatele a naopak velmi elegantně potlačuje různé druhy „lidové tvořivosti“.

Portál jako služba je flexibilní

Velmi důležitým přístupem, který je možné zvolit pouze při dodávce portálu jako služby, je důraz na ty části portálu, které aktuálně potřebuji, bez nutnosti se detailně zamýšlet nad tím, jaké další služby budu v budoucnu zavádět nebo rozšiřovat. Tato elasticita mi umožní na začátku využívat a platit jen za to, co skutečně potřebuji, a z pohledu rozvoje přesně vyčíslit, co mě bude stát přidání nových služeb do systému v okamžiku, kdy je budu potřebovat. Pokud budu mít úspěšný portál, který v čase poroste, nebude nutné řešit, zda jsem na začátku vše správně nadimenzoval po stránce služeb, hardware, konektivity apod., aby řešení bez úhony zvládlo nejen rozvoj, ale i špičky. Úkolem dodavatele je především definovat parametry a procesy při rozšíření služeb, navýšení výkonu nebo během špiček tak, že samotné cloudové řešení dle aktuálního stavu a potřeb automaticky přidává nebo odebírá další instance portálového řešení, případně rozšíří infrastrukturu pro novou službu.

Služba je ihned k dispozici

Time to Market je kromě ceny další důležitý parametr, v němž se potvrzuje síla portálu jako služby, protože všechny strany nenásilně nutí uvažovat v rovině „Jak to co nejrychleji spustíme“, místo tak často se vyskytujícího „Co všechno ještě musíme rozmyslet a připravit, než to spustíme“. Dokonce i po stránce nákladů, kde mnozí budou argumentovat tím, že cloudová řešení jsou ve finále dražší a pouze přelévají prostředky z investic do operativy a umně je navyšují, se dostaví významné úspory. Ovšem nikoliv tím, že se prostředky přesunují a vše je v cloudu, ale tím, že konkrétní části řeší ti, kteří mají odpovídající kompetenci i rozhodovací pravomoc, a řeší je v okamžiku, kdy jsou skutečně potřeba. Přestane docházet k situacím, kdy jsou v zadáních požadavky z kategorie „co kdyby“ a dodavatel chystá složitá, nekoncepční nebo naopak technologicky velmi zastaralá řešení, protože naplňuje „požadavky zákazníka“.

Pokud tedy budete někdy uvažovat o vytvoření, změně nebo rozšíření vašeho portálu, intranetu nebo třeba jen webové prezentace či e-shopu, zkuste zvážit, zda nezkusit portál jako službu.

Vítězslav Košina Autor článku je IT konzultant a šéf inovačního oddělení INIBA ve společnosti IBA CZ.