V dnešním pokračování o architektuře informačních systémů se podíváme na to, kdo je to IT architekt a co dělá.
Kdo je IT architekt?
Architekt je role, která výrazně figuruje v životním cyklu informačních systémů.
Šíře činností, kterou role architekta vykonává je dosti široká, a proto existují různé specializace s různými názvy a přídomky. Řekl bych, že v tom zatím příliš standardizace není.
Najdeme stejné specializace s různými názvy a významy. Takže je v tom občas nějaké to nedorozumění. Stále však platí, že architekt je dominantní rolí při budování a provozu IT systémů.
Čím se vlastně takový architekt zabývá?
Primární rolí architekta je návrh a řízení architektury. Má k tomu mít různé nástroje a prostředky.
Dobré je, když má i odpovídající pozici v organizaci a dostatečné pravomoci. Dost často se práce architekta zaměňuje s malováním modelů.
Já když jsem kdysi vytvářel oddělení architektury, tak jsem od týmu dostával otázku: „Jaké modely máme tvořit a používat“. Já na to vždycky říkám: „Mě příliš nezajímá, jestli modely vůbec a jaké ke své práci používáte. Mě hlavně zajímá, jestli se zabýváte řízením architektury“.
Architekt se tedy zabývá řízením architektury. Už to slovo „řízení“ něco napovídá. Znamená to manažerskou složku v práci architekta. Řízení architektury znamená:
Pochopit situaci, podmínky, potřeby
a umět si potřebné informace opatřit. Musím se umět správně ptát. Ale nejsou to ty známé otázky: „Jaké jsou vaše požadavky?“. Správná otázka je: „Vyhovovalo by vám, kdyby to řešení vypadalo takto a fungovalo takto?“
Vhodné řešení
Řešení, které vyhovuje dané situaci, parametrům, standardům, je optimalizované z hlediska kvalitativních parametrů a ekonomiky. A také by mělo mít nějakou vizi, odpovídající predikovatelnému rozvoji potřeb uživatelů a organizace. Dost často se nejedná jen o návrh finálního řešení, ale spíše plán rozvoje – roadmap.
Validaci řešení
Řešení, část opravdu reprezentované různými modely se musí validovat. To znamená hlavně prezentaci, komunikaci různým rolím v podniku. V praxi si teda například zkontroluji s vlastníkem systému, který chci on-line připojit, že jeho provozní parametry odpovídají našim potřebám. Tohle dost častá chyba, která se děje.
Pamatuji si na situaci z oboru pojišťovnictví.
Po povodních, myslím v roce 2002, byla tendence při pojišťování staveb, ověřovat zdali budova stojí v nějakém rizikovém povodňovém pásmu. A tato informace se nachází v GIS systému. A tak architekt navrhl propojit systém na sjednávání pojištění on-line (samozřejmě web service) se systémem GIS, co firma měla.
A to způsobilo neschopnost pojišťovacích agentů sjednávat majetkové pojištění. Proč to?
Prostě protože GIS systém byl instalován na PC, ležícím v kanceláři pod stolem. A to samozřejmě není server, který je schopen poskytovat službu v nějakém obstojném režimu, třeba 16×7. A pokud jsem na tento systém připojen synchronním on-line rozhraním a GIS neodpovídá, tak můj systém čeká a čeká…
Prostě čím více návrh ověřím, s čím více lidmi jej proberu, tím větší mám šanci, že můj návrh je dobrý a nic jsem neopomněl.
Komunikace řešení
Pokud už mám dobře ověřené řešení, tak jej musím komunikovat. A to většinou formou dokumentů, závazných pravidel a standardů. A také i pomocí osobních prezentací. Prostě ten, kdo má můj design architektury dobře implementovat, tak by měl můj návrh znát a rozumět mu.
Kontrola
Samozřejmá činnost architekta. Je potřeba zjistit, že se vývoj udává směrem, který jsem mu určil. A pokud tomu tak není, je to potřeba zjistit a něco proti tomu podniknout.
Např. nechat opravit vyvíjené řešení a také řešitelskému týmu poskytnout dostatečnou podporu formou rozhodnutí, rady, konzultace… A pokud je chyba v návrhu architektury, tak samozřejmě návrh poopravit. Chyby dělá každý.
Tolik o tom, kdo je a co dělá IT architekt. V dalším díle si povíme, co musí architekt umět, aby se stál dobrým architektem. Znáte ve svém okolí IT architekta? Napište nám o něm.