V prvním díle povídání o architektuře informačních systémů (IS) jsem se pokusil zamyslet nad tím, co vlastně ta architektura IS je, tedy myslím si, že by mohla být.
Nyní se chci podívat na kvalitu architektury. Kvalita je celkem obecný pojem, něco co člověk celý život hledá, o co usiluje. O tom je řada publikací od filosofických, duchovních, uměleckých až po ryze velmi technické. Já se rovnou vrhnu do úvah o kvalitě architektury informačního systému.
Architektura je relativně exaktní věda, ale stále je to disciplína mladá, není na konci své cesty poznání a dále se vyvíjí. Máme řadu metodik, pravidel a standardů. Je stále řada témat málo definovaných, a ty jsou na architektovi, jeho schopnosti vnímat současnou situaci a předvídat vývoj, potřeby a také individuální smysl pro kvalitu věci.
Jak se pozná, že je informační systém kvalitní
Moje úvaha říká, že informační systém je systém, který se zabývá informacemi o reálném světě a jejich získáváním, uchováváním a zpracováním. Zachycuje vybrané aspekty reálného světa. Informační systém je proto tak dobrý, jak odpovídá reálnému životu a jak běží dnes, ale i zítra. Systém se musí nějakým způsobem vypořádat s tím, že náš způsob života a fungování se vyvíjí a tedy i systém by se měl vyvíjet, kopírovat změnu našich potřeb a ta změna by měla být co možná nejvíc přirozená.
Hodně často slyším, jak architekti velmi učeně diskutují, jestli je něco „architektonicky čisté“ nebo „architektonicky pěkné“. A pokud se mě ptají co si o tom myslím, říkám toto: „Pro mě tento pojem značí to, že daný návrh odpovídá zadaným kritériím, stanoveným pravidlům.“ To, co je pro někoho super, je pro někoho jiného strašné. Takže „architektonicky čistý návrh“ je ten návrh, který vyhovuje těm parametrům, který si na něj kladu. Zkusím jich pár nastínit. Určitě ne všechny.
Parametry návrhu architektury
Business požadavky
Zásadní pravidlo je vyhovět business požadavkům. Takže, jinak řečeno, mělo by to dělat to, co to dělat má. Ale neznamená to vyhovět slepě všemu, co po nás klíčový uživatel chce. Je potřeba s ním probírat užitečnost jednotlivých požadavků, ekonomičnost, dalo by se až říci business case.
Prostě musíme říci, jestli nám funkčnost, kterou někdo chce, stojí za cenu vyrobení takové funkčnosti. A to nejen výroba sama, ale i provoz a údržba. Říká se tomu TCO (Total Cost of Ownership). Prostě pokud mám funkci, která je složitá, použije ji jeden člověk dvakrát do roka, tak bych měl přemýšlet, jestli k tomu nezbytně potřebuje specializovaný SW.
Flexibilita systemu
Co to znamená, když uživatel po nějaké době přijde s tím, že něco chce jinak? Jak je to obtížné a nákladné? Dost velkou část těchto požadavků bych měl předvídat a už s nějakou vizí očekávané změny design navrhovat. Určitě bychom měli koukat hlavně na změny, které dávají smysl a ne se snažit udělat návrh SW úplně flexibilní. Jsou věci, které se nejspíše měnit nebudou, u některých se změna požadavků očekávat dá. Hledáme nějaký správný kompromis. Už jsem viděl velmi flexibilní řešení, kde na všechno byl parametr. Samozřejmě v XML souborech. Jen ty soubory nikdo nedokázal udržovat, rozumět jim a požadovanou změnu v nich udělat.
Škálovatelnost systemu
To znamená schopnost zvýšit výkon systému nějakou relativně jednoduchou cestou. Vždy předpokládáme, že firma, pro kterou systém navrhujeme, bude úspěšná a počet klientů utěšeně poroste. Je hloupé říci, že už se tam více klientů prostě nevejde.
Provozovatelnost systemu
Říká jak složité je systém provozovat. Do toho lze zahrnout několik témat:
- Jak náročné je takový systém provozovat. Kolik lidí a jak schopných tato činnost vyžaduje.
- Jaké další nástroje ten systém ke svému provozu požaduje.
- Zdali jsem schopen sledovat chod systému. To lze též nazývat schopností systém monitorovat.
Dostupnost systemu
Má celou řadu složek. Pokud si o systému řekneme, že je dostupný například v režimu 24×7, což znamená 24 hodin, 7 dní v týdnu, tedy bez přestávky, to může znamenat celou řadu aspektů:
- Systém se nevypíná, je neustále zapnutý, běží bez přerušení i včetně provozních zásahů – nedojde přerušení dostupnosti služby pro koncového uživatele.
- Systém je neustále pod dozorem – někdo se o něj nepřetržitě stará a je schopen v kterékoli době možno udělat provozní zásah. Tedy spíše dostupnost obsluhy.
Stabilita systemu
Představuje velmi klíčový parametr pro on-line systémy, kde se předpokládá, že uživatel může kdykoliv službu použít. To je důležité zejména pro systémy s uživateli z různých časových pásem. V době kdy jedni spí, druzí chtějí systém intenzivně využívat.
Toto se řeší různými mechanismy, které zajišťují vysokou dostupnost (high availability, známe pod zkratkou HA) systému. Tady se uplatňují postupy, jako jsou redundance, buď jen klíčových anebo až všech prvků systému, clustering, mirroring a podobné mechanismy. Jsou to drahá řešení a je proto nutné vždy zvážit, jak odolné zařízení vlastně potřebujeme.
Otevřenost systému
Znamená, jak je náš systém schopen kooperaci či integrace s ostatními systémy. To se dnes dá zajistit mnohem lépe než dříve. Pokud systém dodržuje obecně uznávané standardy, tak to už skoro máme v ruce.
Bezpečnost systému
Poslední, ale ne nejméně důležitá. Zjednodušeně říkáme, zdali je systém schopen zajistit to, že nabízí informace a své služby pouze těm, kteří na to mají právo. Pokud se chceme zabývat tím, jestli jsou informace správné a víme, že ten kdo něco udělal se systémem, to opravdu udělal, tak se bavíme o pojmech jako důvěryhodnost, auditovatelnost a nepopíratelnost. A také se zabýváme odolností proti útokům.
A k čemu všechny tyto parametry slouží?
Je to něco, co potřebuji k tvorbě architektonického návrhu a k validaci, k ověření toho, jestli jsem návrh udělal dobře.