Zavádíme portál

Důvodů pro zavedení portálu může být více, avšak základem je, že jsou dané důvody smysluplné a reálné. Příkladem špatného důvodu může být potřeba nového CMS. Ano, většina portálových platforem obsahuje CMS i DMS, vyhledávací funkcionality, atd., nicméně hlavní deviza portálu je jinde, a to v unifikaci přístupu k řešení problémů. S instalací portálu typicky získáte opravdovou platformu nabízející větší či menší množství služeb již v základu a každý potencionální vlastník portálu by si měl dostatečně ověřit, do jaké míry bude tyto služby využívat. Platforma, v současné době postavená primárně na Java nebo .Net technologiích, má také své nároky na okolní systémy. Roztříštěná správa uživatelů, absence SOA architektury, nebo velké množství aplikací v různých technologiích rozhodně při zavedení portálu nepomohou. Každý, kdo se rozhodne pro jeho zavedení , by měl investovat nemalé množství času a energie do odpovídajícího PoC (Proof of Concept), které ověří nejenom vhodnost zvoleného řešení, ale předně schopnost začlenění řešení do stávajícího ekosystému, včetně s tím souvisejících nákladů.

Stažení vývojářské verze, spuštění a umístění diskuzního portletu na hlavní stránku dozajista není správným PoC. Pracuje vaše společnost s tisíci uživatelů denně? Pokud ano, musí být součástí PoC ověření funkce řešení při odpovídající zátěži a také vertikální i horizontální škálovatelnost. Je cílem zavedení unifikované platformy pro komunikaci se zákazníkem a migrace stávajících aplikací do portálu? Pokud ano, musí PoC odpovědět na otázky týkající se správy uživatelů napříč aplikacemi, schopnosti stávajících aplikací poskytnout data pro portál, čistoty dat (je klient A v systému S1 opravdu stejným klientem A v systému S2?), apod. Je nutné smířit se s faktem, že podobná ověření odhalí větší, či menší množství bolavých míst a pověstných kostlivců ve skříni. Japonské přísloví říká: „Vize bez akce je jen sen, akce bez vize je noční můrou.“ V případě implementace portálů dané platí několikanásobně. V rámci každé společnosti se jedná o strategické rozhodnutí a pokud neexistuje podpora od business i IT, je daná úloha předem odsouzena k záhubě. Na konci projektu pak může zůstat celkem drahé řešení, které ale vlastně nikdo nechce.

Modelové situace

Pojďme pro zjednodušení uvažovat dva nejtypičtější příklady společností, které se rozhodnou pro implementaci portálu. Prvním z nich je společnost zavádějící vše takzvaně „na zelené louce“. Mohlo by se zdát, že v takové situaci k ideálnímu stavu téměř nic nechybí, jelikož společnost je vlastně omezena pouze svou představivostí a s ní ruku v ruce jdoucím rozpočtem. Portál může navíc sloužit jako ideální předpis architektury pro budoucí rozvoj celého IT. Velké riziko však přeci jen existuje, a tím je obecná vyspělost IT jako celku v rámci firmy. Zavedení portálu není jako instalace lokálního izolovaného software. Dříve nebo později se začne celý ekosystém rozrůstat a bude potřeba někdo, kdo určí správný směr – zjednodušeně řečeno bude potřeba odpovídající governance. Je nutné definovat předepsanou architekturu, povolené technologie, identifikovat společné strategické moduly, atd. V případě portálů se dá použít krásná paralela se železnicí. Zákazník vlastně staví novou trať ve volné krajině, přičemž spojení dvou stanic jednou kolejí a jedním vlakem je na provoz celkem jednoduchá úloha. Když ale stanic přibude a zvýší se i počet vlaků, určitě se budou hodit semafory, znalost všech, že červená znamená stůj, a že dva vlaky proti sobě na jedné koleji nejsou nejlepší nápad. Bez odpovídající governance se totiž může z nákladného portálu stát pouze běhové prostředí pro mnoho „kostiček“ v celé mozaice aplikací, které spolu nesdílí ani kus společné funkcionality.

Druhou modelovou situaci lze ukázat na společnosti se zavedeným IT a větším množstvím vlastních aplikací. Je nutné zmínit, že tyto aplikace jsou typicky roztříštěné z pohledu funkcionalit, použitých technologií i uživatelského rozhraní. Management společnosti se rozhodne situaci zunifikovat a pro daný účel zvolí právě portálovou platformu. Zde bychom opět neměli opomenout výše uvedené přísloví. Myšlenka unifikace je bezesporu správná a nezbývá, než ji podpořit. Management si však musí být 100% vědom všech rizik a okolností, co dané znamená (přeloženo investic, a to krátko i dlouhodobých). Z praxe jsou známy případy, kdy se management rozhodl spojit implementaci portálu s pilotní aplikací pro koncové zákazníky. Z obchodního pohledu se jednalo o logický nápad, nicméně ze strategického hlediska nikoliv, jelikož očekávání zákazníka na dodání aplikace bylo shodné, jako u stávajících systémů. Nebohý dodavatel (včetně interního IT i subdodavatelů) tak společně zažili nepříjemné chvíle spojené s implementací proti teprve vznikajícím rozhraním backendů, paralelní tvorbou SOA architektury a předně governance, která taktéž teprve vznikala. V tomto případě se tedy jednalo o čistou akci bez vize, kdy jedinou myšlenkou byla potřeba portálu, mnohem více však byla potřebná vize celkového řešení v podobě unifikované platformy a odpovídající podpora ze strany vedení. Nemalým rizikem strategických rozhodnutí ve větších společnostech je jejich setrvačnost (proto se opravdu vyplatí důkladný PoC, viz výše). Pokud opět použijeme paralelu s vlaky, tak si představte, že sedíte v TGV z Paříže do Lyonu a při 300 km/h si uvědomíte, že jste nastoupili špatně, protože ukazatele hlásí další stanici Rennes. Samozřejmě můžete použít záchrannou brzdu, nicméně ta vás zpátky rozhodně rychleji nedostane a navíc nejspíš naštvete spoustu spolucestujících. Většinou bude lepší dojet do další stanice, ztratíte však dost času a v Lynou hned tak nebudete.

Migrujeme do portálu

Ať už jste v jakékoliv společnosti používající portálové řešení nebo se na tuto úlohu teprve chystáte, tak dříve nebo později narazíte na potřebu migrace současných aplikací do zvolené platformy. Při větším množství aplikací se nikdy nevyplatí metoda „velký třesk“, ale spíše plnohodnotná analýza současného stavu a zvolení pilotní množiny, na které se migrace ověří. Hodnocení aplikací pro výběr do pilotu by mělo obsahovat minimálně faktory spojené s business přínosy aplikace i náročností její migrace. Po sestavení hodnocení lze zvolit k migraci ty nejvhodnější, případě se řídit paretovým pravidlem, které funguje téměř vždy.

K migraci lze přistoupit čtyřmi nejčastějšími způsoby a stav IT architektury konkrétní výběr velmi ovlivní.

Prvním způsobem, který se nabízí, je implementace od nuly. Jedná se tedy o vývoj, který je svázaný pouze současnými možnostmi portálového řešení a zákazníkem definovanými požadavky. Pokud je navíc přítomna vyspělá governance, jedná se téměř o ideální projekt.

Velmi často však situace takto ideální není a zákazník navíc nemá ani dostatek času. V takové situaci se dle stavu IT architektury a v migrované aplikaci použitých technologií nabízejí dvě možnosti. Nejjednodušší z nich je čisté přesměrování, případně začlenění již existující aplikace do portálového řešení. Míra integrace se logicky liší případ od případu, ale rozhodně nelze očekávat ideální stav. Spíše se bude jednat o kompromis. Uživatel nejspíš pozná rozdíl oproti zbytku portálu, některé funkce budou pracovat jinak a bez úprav přímo v migrované aplikaci bude možná nezbytné i opětovné přihlášení, atd. Základem však je, že uživatel portálu o žádné funkce nepřijde. Tato možnost se nejčastěji volí u business critical aplikací, které by však byly neúměrně náročné na úpravy nebo přepis.

Třetí a o něco přívětivější variantou je využití portálu pouze jako prezentační vrstvy, kdy veškerou business logiku poskytuje originální aplikace skrze vystavená rozhraní. Tato varianta je z pohledu uživatele naprosto nerozpoznatelná od ostatních portálových aplikací, naneštěstí stojí a padá se schopností originální aplikace poskytovat odpovídající rozhraní. Pokud originální aplikace žádným rozhraním nedisponuje, případně vzhledem k použití obstarožní technologie není dané ani v definovaném čase možné, jedná se o slepou uličku.

Poslední možností je kompletní přepis stávající aplikace. S výjimkou malých aplikací s omezenou funkcionalitou se však téměř vždy jedná o problémové projekty. Implementátor řešení typicky narazí na zastaralou dokumentaci, spoustu nevyřešených problémů (u kterých se však očekává řešení právě v rámci migrace) a v neposlední řadě připomínek z testování, kdy stará verze přece fungovala jinak a lépe a to a to v ní jednoduše šlo). U této možnosti se doporučuje spíše postupný přepis, například skrze třetí variantu, kdy je původní aplikace rozšířena o potřebná rozhraní. Opět se nejedná o ideální stav, ale migrace je o něco bezpečnější pro všechny strany a typicky je o něco méně časově náročná.

Portál ano, či ne

Portály, stejně jako každé jiné komplexní systémy, jsou dobří sluhové, ale špatní páni. Každý, kdo o této možnosti vážně uvažuje, by měl jasně definovat požadované cíle, důsledně zvážit všechna pro a proti, zainvestovat do netriviálního PoC a v případě negativního výsledku aktivitu co nejdříve přehodnotit, resp. ukončit. Jednoduchá samospasitelná řešení neexistují a ani portálové platformy jimi nejsou. Proto je dobré být na pozoru vždy, kdy se předpokládá, že portál sám o sobě vše vyřeší nebo zlepší. Cesta k fungující portálové platformě chce čas a také úsilí. Pokud se dané obětuje, výsledky se dostaví. Pokud se ale pouze věří v úspěch bez potřebných kroků, většinou po projektu zůstane pouze pachuť.

Michal Petřík Autor článku působí na pozici Head of Software Development ve společnosti Profinit