IS na zakázku a jejich tvorba

Otázku, zda přistoupit k integraci nebo vývoji nové aplikace, si v poslední době kladou manažeři IT mnoha velkých a d...


Otázku, zda přistoupit k integraci nebo vývoji nové aplikace, si v poslední
době kladou manažeři IT mnoha velkých a dnes už i středních firem. Rozhodnutí
ani pro jednu z těchto dvou cest ale není jednoduché a ovlivňuje jej mnoho
faktorů.

Peníze, čas a omezení
Zda vyvíjet novou aplikaci nebo integrovat stávající, je nakonec otázkou času,
peněz a omezení stávajících systémů. Proč? Každá aplikace je technicky
integrovatelná! Může se ale stát (a stává se), že řešení integrace je pracnější
a dražší než vývoj nové aplikace.
Podívejme se nejdříve na některé požadavky kladené na informační systémy a proč
vůbec o otázce IS na zakázku uvažovat. Jsou jimi zejména:
single sign-on, sjednocení a zjednodušení ovládání
webové rozhraní
mobilní klienti
přidání nových funkcí
zjednodušení a zlevnění údržby
zrychlení a zpřesnění firemních procesů
customizace (úprava podle požadavků zákazníka, tj. personalizace) a
internacionalizace
škálovatelnost (scalability), tj. možnost stupňování výkonu systému podle
potřeb

Integrovat, nebo vyvíjet?
Vlastní rozhodnutí pak tedy leží na srovnání výsledku analýzy, zda integrováním
pokryji všechny požadavky kladené na systém, a to jak funkční, tak i výkonové
či finanční.
Typickými důvody, kdy integrace nestačí, jsou např.:
Výkon a škálovatelnost současného řešení je nedostatečný.
Údržba nebo modifikace je problematická a drahá.
Složitost a cena integrace by převýšila cenu vývoje.
Současné systémy nenabízejí potřebné funkce a jejich doplnění do integrace by
bylo drahé, nesystematické nebo obtížně realizovatelné.

Vhodné technologie
Podívejme se nejprve na nejpoužívanější technologie vhodné pro vývoj IS na
zakázku. Budeme mluvit pouze o vícevrstvých technologiích, protože v současné
době zřejmě není důvod používat pro nový projekt jinou architekturu.
Monolitické aplikace jsou pro tyto projekty také nevhodné.

Platforma Java
J2EE (Java 2 Enterprise Edition) spojuje výhody programovacího jazyka Java se
zkušenostmi z vývoje podnikových informačních systémů. O funkčnosti a
architektuře J2EE bylo publikováno již mnoho článků, daleko méně autorů si však
všímá faktu, že vzhledem ke své komplexnosti bývá J2EE někdy implementována
nepříliš vhodným způsobem.

Mýty a realita Javy
Mezi nejčastější chyby patří např. mýtus přenositelnosti kódu (WORA Write Once
Run Anywhere), kdy je v požadavcích projektu stanoveno, že aplikace má být bez
úprav přenositelná mezi různými aplikačními servery. Takový požadavek pak vede
ke ztrátě produktivity a méně uspokojivému výkonu a efektivitě aplikací.
Aplikace by měly být správně vyvíjeny tak, aby co nejvíce využívaly možnosti
aplikačního serveru, na němž budou provozovány, ale zároveň by měly být co
nejsnadněji přenositelné na jiný server. Toho se dá např. dosáhnout oddělením
nepřenositelných částí kódu do jasně definovaných modulů.
Přehnaný důraz na přenositelnost aplikací spolu s nadšením pro standardy a
specifikace J2EE pak někdy vede k dalšímu omylu, kterým je názor: není-li
nějaká část systému implementována pomocí J2EE, pak je to špatně. Typickým
příkladem tohoto omylu je EJB QL (Enterprise JavaBeans), které se dokonce stalo
součástí specifikace EJB 2.0 tento jazyk je sice dobře přenositelný, avšak
nezralý a komplikovaný. Je přinejmenším diskutabilní, zda ve své současné verzi
přináší EJB oproti zralému a standardizovanému jazyku SQL (Structured Query
Language), s nímž má většina vývojářů zkušenosti, nějakou významnou výhodu.

Důvěřuj, ale prověřuj
Nebezpečná může být i přílišná důvěra v možnosti aplikačních serverů v
oblastech nízkoúrovňových služeb, jako jsou např. správa transakcí a přístupu k
datům. Kupříkladu databáze Oracle provádí zamykání dat zcela jiným způsobem než
ostatní relační databázové servery. To pak může zapříčinit rozdílné chování
aplikace nad různými databázemi.

Nevěřte slepě ani EJB
Další častou chybou je přílišné tíhnutí k EJB, které jsou velmi komplexní
technologií. Zde neexistuje žádné pevné pravidlo, na jehož základě lze říci,
kdy EJB použít a kdy ne. Lze jen konstatovat, že ve většině aplikací J2EE je
použita jen malá podmnožina komponent J2EE ve formě servletů a stateless
session EJB.
Přes zmíněná úskalí při vývoji je J2EE vyzkoušenou a vhodnou platformou pro
vývoj celopodnikových náročných aplikací i aplikací sloužící tisícům paralelně
připojených uživatelů či zákazníků.

Platforma Microsoft
Net Platforma .Net je v současné době přímým (a vlastně i jediným reálným)
konkurentem architektury J2EE.
Je oproti J2EE mnohem mladší, je však postavená na nejmodernějších principech,
díky nimž řeší některé problémy, na které narážíme v J2EE. Mezi ně patří
například rychlý vývoj tlustého i tenkého klienta. Také vlastní tlustý klient
je díky úzkému propojení .Net na operační systém mnohem rychlejší a uživatelsky
přítulnější pro uživatele MS Windows.
Díky relativní mladosti je však .Net méně vyzrálé řešení s mnohem méně
referencemi, pro které neexistuje tolik odzkoušených postupů, návrhových vzorů
(design patterns) a metodik návrhu a vývoje systému.

Třívrstvé přínosy
Třívrstvá architektura a internetové technologie (HTML, WML, XML, protokol
HTTP) umožňují provoz aplikací určených různým typům klientů. Jsou-li správně
zvoleny architektonické modely a vhodně navrženy aplikační moduly, je možné
přidávat podporu dalších typů klientů bez nutnosti změn ve vlastní obchodní
logice aplikací a s vynaložením minimálních nákladů. Tak mohou s jednou
aplikací pracovat např. klienti přistupující z webového prohlížeče, mobilního
telefonu nebo PDA. Důsledkem podpory různých typů klientů je pak:
Rozšíření okruhu potenciálních zákazníků firmy, kteří mohou získávat informace
o produktech, podávat objednávky či využívat služby, aniž by byli jakkoli
omezováni požadavky na způsob přístupu či typ jimi používaného zařízení (zde
neodoláme a vkládáme vzkaz pro některé české webové designéry: existují i
uživatelé, kteří nepoužívají MSIE).
Díky možnosti využívat aplikace v terénu či u zákazníka mohou pracovníci firmy
poskytovat rychlejší a kvalitnější služby zákazníkům a okamžitě aktualizovat
data ve firemních informačních systémech.

Dostupnost 24 x 7 a škálovatelnost
Na první pohled by se mohlo zdát, že více vrstev poskytuje větší prostor pro
potenciální výpadky. Praxe však ukázala, že je tomu právě naopak a použití více
vrstev celkovou dostupnost systému zvyšuje. Jednotlivé vrstvy totiž mohou být
provozovány na více strojích, které formují tzv. clustery.
Přidáváním dalších strojů do clusteru pak lze snadno škálovat kapacitu systému
(tj. zvyšovat jeho výkon), opět bez nutnosti výrazných zásahů administrátora.
Pro provoz vnitřních firemních systémů představuje dostupnost nejdůležitější
faktor, který v dnešní době prakticky rozhoduje o bytí či nebytí firmy.
Clustering klíčových částí systému by proto měl být samozřejmostí.

Internacionalizace a web
Vzhledem k tomu, že komunikace na internetu probíhá bez hranic jakéhokoli typu,
je třeba rychle a elegantně vyřešit problém podpory uživatele nejen z hlediska
typu používaného zařízení, ale i preferovaného jazyka a konvencí pro
formátování vstupu/výstupu.
Protokol HTTP nám poskytuje informace o preferencích uživatelů prostřednictvím
parametru Accept-language, který je součástí hlavičky příchozího požadavku. Na
základě hodnoty tohoto parametru pak může aplikace automaticky s uživatelem
komunikovat jeho preferovaným jazykem (samozřejmě za předpokladu, že patří mezi
aplikací podporované jazyky). Podpora internacionalizace tak může pro firmu
znamenat konkurenční výhodu, neboť uživatelé se budou jistě raději vracet na
web, který s nimi komunikuje tím pro ně nejpříjemnějším způsobem.

Personalizace
Podobně jako internacionalizace je personalizace dalším zpříjemněním práce s
informačními systémy, byť ne natolik zásadním. Zpočátku existovala v jednoduché
formě osobních nastavení, jež byla uživateli nabídnuta v podobě formuláře,
který vyplnil a uložil.
Dnešní systémy umožňují mnohem sofistikovanější způsob personalizace, někdy i
bez nutnosti jakéhokoli zásahu uživatele. Předpokladem pro to je dlouhodobé
ukládání informací o komunikaci a operacích prováděných uživatelem tyto jsou
pak analyzovány a na základě výsledků analýzy jsou pak uživateli nabízeny jím
často používané aplikace, volby nebo informace. Personalizace dnes bývá
používána zejména v prostředí informačních a zákaznických portálů.

Konsolidace a zpracování dat
Konsolidace a zpracování zákaznických dat znamenají mnohonásobně větší možnosti
pro firemní marketing, služby atd. Ukládání a analýza dat o zákaznících pak
firmám umožňuje nejen personalizaci aplikačního prostředí, ale skýtá celou
škálu dalších možností: od efektivnějšího plánování marketingových kampaní a
cíleného oslovování zákazníků, až po zefektivnění vnitřních obchodních procesů.

Integrace a podpora procesů
Typický informační systém je dnes tvořen pestrou směsicí hardwaru, databází,
middlewaru a aplikací nejrůznějšího typu, jež se objevily v průběhu dlouhé řady
let, kdy se příliš nedbalo ani na čistotu architektury, ani na koncepci IS do
budoucna. Pro realizaci jednotlivých obchodních procesů tak často bývá nutná
spolupráce více různých aplikací, pracujících s daty umístěnými v nejrůznějších
datových zdrojích. Vývoj a integrace aplikací proto nejsou dvě různé, nezávislé
činnosti.

Tři druhy integrace
Jednotlivé scénáře lze rozdělit dle způsobu na integraci přímou, integraci
pomocí zpráv a tzv. Enterprise Application Integration (EAI). Při přímé
integraci dochází k modifikaci stávajících systémů, k rozšíření funkčnosti a k
novým definicím vzájemné komunikace.

Přímá integrace
Přímá integrace aplikací umožňuje pouze synchronní komunikaci, která spolu s
náročnou realizací změn představuje nevýhody této metody, které jsou ale
vyváženy rychlou komunikací a volností při výběru protokolu.

Integrace pomocí zpráv
Integrace pomocí zpráv využívá již hotová řešení v podobě služeb messagingového
(zpravodajskéno, někdy dávkového) serveru, který podporuje transakce a
asynchronní zpracování. Tento postup je však o něco pomalejší než přímá
integrace.

Integrace EAI
Řešení pomocí tzv. Enterprise Application Integration serveru je variabilní a
umožňuje rychlé zapracování budoucích změn. V současné době se výrazně
prosazují webové služby, poskytující nezávislost na vlastním systému, snadnou
rozšiřitelnost, provoz po internetu a standardizaci. Nevýhodou webových služeb
řešení je velká datová režie komunikačního protokolu a rychlost zpracovávaných
požadavků. Webové služby se ale dají použít jako univerzální rozhraní (či
komunikační protokol) pro všechny scénáře integrace.

Zabezpečení komunikace
Nedílnou součástí integrace a vícevrstvých řešení je také dostatečné zajištění
zabezpečené komunikace jednotlivých částí systému a samozřejmě zabezpečení
přístupu k aplikaci a datům.

Buďme nohama na zemi
Integrace aplikací založená na vícevrstvých technologiích je v současné době
jedním z hlavních směrů rozvoje informačních systémů ve velkých společnostech.
Již před časem byla opuštěna myšlenka, že vše zvládne jedna "superaplikace",
která bude pokrývat všechny potřeby společnosti. Jak se v praxi ukázalo, vývoj
takové aplikace je příliš složitý a nákladný a potřeby společností se dnes mění
natolik dynamicky, že takovýto systém není možné modifikovat dostatečně rychle.
Nové technologie (EAI, webové služby...) nabízejí vhodné prostředky, jak
takovou integraci zvládnout a implementovat.
Autor je technickým ředitelem společnosti Cleverlance.









Komentáře
K tomuto článku není připojena žádná diskuze, nebo byla zakázána.