Také v osobním životě se pravidelně setkáváme se situacemi, kdy se nabízí jednoduché a dle všeho správné řešení, avšak skutečnost nás velmi rychle vyvede z omylu. Představme si, že chceme koupit nový prostorný rodinný vůz, který by sice splnil veškerá očekávání, ale nevejde se nám do garáže. Pokud si tuto omezující podmínku uvědomíme dostatečně brzy, máme možnost zvolit různé alternativy (menší vůz, stavba přístřešku, …). Pokud však vůz koupíme bez rozmyslu, čeká nás kromě nemilého překvapení ještě spousta starostí, které jen tak nezmizí.

Shodné principy lze aplikovat i na krabicová řešení, která většinou nabízejí množství skvěle aplikovatelných vlastností, je však otázkou, zda tyto skvělé vlastnosti bude zákazník schopen plně využít i ve svém prostředí.

Při zvažování nákupu krabicového řešení by si měl každý svědomitě odpovědět na tyto otázky:

• Musí se zakoupené řešení přizpůsobit společnosti anebo se může společnost přizpůsobit řešení?
• Bude možné řešení plně integrovat do stávajícího prostředí anebo bude celá oblast udržována naprosto odděleně (vznikne tedy další specifický systém)?
• Bude řešení respektovat aktuálně plánovaný rozvoj, přesněji řečeno bude rozvoj v požadovaném rozsahu proveditelný i po nasazení řešení?
• Je společnost připravena na případné další investice spojené s přizpůsobením řešení a investice spojené s „náběhem“ řešení (zaučování uživatelů, přizpůsobení se procesům, apod.)?

Obdobných otázek lze samozřejmě identifikovat více, ale výše uvedené jsou naprosto stěžejní. Pojďme si je nyní rozebrat ve větším detailu.

Přizpůsobení řešení nebo přizpůsobení se řešení

Řekněme si naprosto upřímně, že nalezení přesně vyhovujícího řešení není zcela obvyklou záležitostí. Samozřejmě, pokud existuje varianta, která perfektně odpovídá svými procesy a možnostmi konfigurace řešené doméně, proč ji neprozkoumat nebo rovnou nevyužít - zkušenosti však hovoří spíše o opaku (ideál málokdy existuje).

Téměř ideálním stavem může být situace, kdy řešení konkrétní oblasti ve společnosti de facto neexistuje. Představme si kupříkladu rychle rostoucí firmu, která doposud pracovala se CRM v podobě tabulek uložených na sdíleném disku. Vzhledem k růstu společnosti narazí tento přístup na své limity a je nutná změna. V této konkrétní situaci je nákup již připraveného řešení naprosto logický a celá otázka výběru se zužuje na výběr jedné z mnoha nabízených variant.

Oproti výše uvedené situaci si představme příklad s interním core systémem pro správu klientských úvěrů, který používáme již více než 10 let. V systému bude nejspíše existovat několik dlouho neřešených či odložených chyb, některé oblasti nejspíše nebudou pokryty vůbec, některé věci budou uživatelům vadit, atd. Na druhou stranu bude systém s velkou pravděpodobností přizpůsoben našim procesům a uživatelé budou schopni se systémem pracovat téměř i poslepu, nehledě na fakt, že za dobu své existence již systém umí pracovat s většinou mnohdy sporných požadavků a odchylek od standardů, které jsme doposud požadovali. Představu, že krabicové řešení v tomto případě pouze nahradí stávající core systém, si dovolím označit za značně ambiciózní. Nové řešení bude disponovat vlastním GUI, vlastními pravidly, vlastními procesy, atd. Ano, vše lze samozřejmě přizpůsobit. Nicméně potom se již bavíme spíše o zákaznickém vývoji a výhody krabice se významně stírají. Pokud se naopak rozhodneme ctít pravidla zakoupeného řešení, musíme se připravit na jisté zpomalení, které změna u uživatelů bezesporu způsobí.

Integrace řešení do stávající architektury

V dnešním světě SOA architektur je velmi nepravděpodobné, že by mezi sebou nebyly jednotlivé systémy integrovány. Pokud se opravdu bavíme o SOA architektuře, je samozřejmě situace jednodušší. Avšak ruku na srdce, současnou realitou je mnohdy stále point-to-point řešení (slangově „špagety“), případně nasazení ESB, které však slouží jako jednoduchá proxy služba bez dalších přiřazených odpovědností.

Přidání dalšího systému do nepřipravené architektury může být mnohdy téměř zničující. Postupně se velmi často objeví požadavky na doplnění dalších nezbytných systémů, se kterými se dosud nepočítalo. Jako příklad uveďme: podpora pro Single Sign On, doplnění nezbytných webových/REST služeb u rozhraní, kde byl doposud pouze databázový přístup, nutnost zavedení ESB, atd. Nelze než souhlasit, že díky integraci nového systému vlastně může dojít ke konsolidaci celé architektury. Znovu je však nutné se ptát, zda byl toto pravý cíl a zda je pak reálné nasadit řešení v krátkém čase a s malými náklady. Z pohledu integrace je samozřejmě klíčovou otázkou také datová kompatibilita, jelikož stávající data lze jen výjimečně ignorovat a začít takzvaně na zelené louce. V některých případech lze problémy vyřešit vhodně navrženými rozhraními, nicméně i přesto lze očekávat problémy například s atributy klientů nebo adres, kdy každý ze systémů modeluje konkrétní entity odlišně a pro další rozvoj je nutné oba přístupy sjednotit nebo alespoň dosáhnout určité kompatibility. Typicky se však v této úloze budeme potýkat s intenzivní datovou analýzou, návrhem nezbytných transformací a definicí kvalitativních pravidel pro ověření úspěchu migrace.

Bezesporu existuje i možnost nové řešení kompletně oddělit od zbytku stávající architektury. Takovou volbu si však dovolím nazvat čistě politickým řešením. Samozřejmě se vždy jedná o rozhodnutí jen a pouze zákazníka a jeho odpovědnost, přičemž si lze představit situace, kdy se takové řešení jeví jako nezbytné. Je ale smutnou pravdou, že z dočasných řešení se obvykle stávají řešení trvalá a je tedy ke zvážení, zda společnosti prospějí například dvě oddělené databáze klientů, dvě odlišná tisková řešení nebo dva přístupy k výpočtu provizí. Úroveň komfortu koncových uživatelů (a tedy spokojenost zaměstnanců) již netřeba zmiňovat, stejně jako náklady na straně IT, které bude muset spravovat dva „odlišné světy“, kde každý svět disponuje svojí unikátní sadou problémů

Dodržení plánovaného rozvoje

S předchozí oblastí silně souvisí i zanesení nového řešení do plánovaného rozvoje celé architektury. V případě rozvoje stávajících systémů lze samozřejmě narazit na limity (nepodporované technologie u interních systémů, výkonnostní problémy, škálovatelnost, …), nicméně IT dodavatelé umí být velmi kreativní a pouze výjimečně opravdu neexistuje způsob, jak konkrétní požadavek splnit. Důvod tohoto stavu je zřejmý, jelikož i systémy a s nimi svázaní dodavatelé s architekturou již delší dobu žijí, znají její výhody i úskalí a zažili si její postupný rozvoj - mnohdy dokonce podobu architektury sami určovali.

V případě krabicových řešení je ale situace odlišná. Architektura obsahuje specifické oblasti, specifické služby, nároky a pravidla, oproti tomu krabicové řešení bude nejspíše obsahovat skvělou podporu pro standardy a nejvíce používaná rozhraní, avšak konkrétní implementaci přímo aplikovatelnou u zákazníka spíše sporadicky. Bude nutné přizpůsobení, a ne vždy lze očekávat, že bude pouze přímočaré. Jádro nového systému například pracuje odlišně, je tedy možné velmi jednoduše vystavit rozhraní, ale pro získání konkrétních hodnot nebo dodržení požadovaného flow by již znamenalo zásah do jádra, apod.

V některých případech se může zákazník rozhodnout směřovat svůj další rozvoj čistě na základě nově zakoupeného řešení. Jestliže se jedná o situaci, kdy nakupujeme nový core systém, který poskytuje vše, co jsme dosud neměli, jedná se o velmi moudrou volbu. Pokud ale daná situace vede k nutnosti přizpůsobení N existujících systémů, reálně tím můžeme ohrozit funkčnost doposud bezproblémových oblastí. A pokud dokonce není možné řešit změny přírůstkově a v dostatečně bezpečném čase, jedná se téměř o nesplnitelný úkol a pro IT o sebevraždu (nové požadavky nebudou včas vyřešeny a stávající systémy přestanou fungovat).

Náklady na „krabicové“ řešení

Nikdy neplatí, že zákazník zaplatí pouze licenci produktu a tím veškeré náklady končí. V případě větších systémů takovou možnost neuvádí ani sami dodavatelé řešení, protože taková situace není reálná. Vždy je nutné přizpůsobit řešení konkrétnímu zákazníkovi a jeho nárokům. Jak se tedy tento přístup liší od čistě zakázkového vývoje? Mnohdy téměř vůbec. V tomto ohledu se můžeme bavit například o konektorech na specifické databázové rozhraní, napojení na dedikovaná rozhraní konkrétních systémů, atd. V některých případech zákazník požaduje vlastně kopii stávajícího systému, který akorát musí lépe vypadat (protože na aktuální systém jsou všichni vlastně zvyklí, akorát se jim nelíbí GUI…).

Specifickou oblastí je pak budoucí rozvoj. Zakoupený software má svoje release cykly, které se mohou, ale také nemusí, krýt s potřebami zákazníka. Pokud se bude jednat o čistý produkt (minimum přizpůsobení, pouze pravidelné aktualizace, atd.), mohou požadavky zákazníka „soupeřit“ i s prioritnějšími požadavky jiných zákazníků a v důsledku tak může dojít i ke zhoršení time to market oproti systému řešenému formou zakázkového vývoje.

Nezbytnou podmínkou při hodnocení „krabicového“ řešení je tedy zvážení minimálně těchto oblastí:

• Cena licence a cena přizpůsobení - včetně rozsahu přizpůsobení.
• Rozsah a pravidla SLA (jsou shodná pravidla pro přizpůsobenou i produktovou část?).
• Pravidla budoucího rozvoje (pravidelný release cyklus nezávislý na zákazníkovi v kontrastu k cyklu plně přizpůsobenému zákazníkovi).
• Možnost budoucí správy zalicencovaného řešení - bude nutné vše řešit přes dodavatele anebo bude moci systém spravovat interní IT. Pokud ano, jak bude řešeno předání?
• Předání zdrojových kódů k zakoupenému řešení (možnost využití principu escrow, apod.).

Výše uvedené otázky nemusí být v mnoha příkladech relevantní, stačí se vrátit k dříve uvedenému příkladu CRM. Oproti tomu v situacích, kdy kupříkladu plánujeme nahrazení celého core systému (systémů), je vyhodnocení těchto okrajových podmínek naprosto klíčové. Můžeme tedy zakoupit „krabicové“ řešení, ale hned od druhého dne vlastně pracujeme ve formě zakázkového vývoje a veškeré plánované výhody vlastně zanikají.

Vítězí zakázkový vývoj nebo krabicové řešení?

Pokud zákazník uvažuje mezi zakázkovým vývojem a „krabicovým řešením“, nikdy neexistuje jasný návod, jak v dané situaci postupovat. Vše samozřejmě záleží na konkrétní situaci a okrajových podmínkách, které se liší případ od případu. Jako vodítko však mnohdy poslouží zmapování aktuální situace IT systémů. Pokud je většina z nich vyvinuta tzv. na míru a společnost s takovými systémy již delší dobu pracuje, bude zavádění krabicového řešení určitě obtížnější v porovnání se společností, kde jsou naopak zvyklí na využití dostupných nabízených možností (a v důsledku i převzetí způsobu práce, jaký řešení předepisuje).

Rozhodně nelze tvrdit, že náhrada formou „krabicového“ řešení není možná. To samozřejmě není pravda a v mnoha případech je dané dokonce jediný logický postup. Nikdy bychom ale o této variantě neměli uvažovat pouze jako o snadné, rychlé, levné a jediné správné. Předem je ale nutné upozornit, že pozitivní vztah a silná očekávání vzhledem ke krabicovým řešením se velmi těžko oponuje, jelikož je reálně podložen velmi dobrými zkušenostmi: všichni používáme kancelářské balíky, souborové manažery, emailové klienty, … Vše funguje ihned po instalaci, tak proč by takto neměl fungovat například i nový systém na správu pohledávek a proč bychom na jeho zavádění vlastně měli trávit více jak tři měsíce, že? Pokud na takto položenou otázku naleznete díky článku odpověď, dokonale splnil svůj zamýšlený účel.

Michal Petřík Autor působí jako Senior Consultant ve společnosti Profinit, kde je v současné době zodpovědný za dodávky systémů převážně pro zákazníky z finančního sektoru. Mimo výše uvedeného se zaměřuje i na oblast návrhu architektury, designu, dohledu nad dodržením kvalitativních nároků vývoje a taktéž je silným zastáncem myšlenek Continuous Delivery a DevOps obecně.