�asopis: Computerworld
�íslo: 11
Rok: 2008
Název: Softwarová architektura
Autor: Ond�ej Malé�, Adastra

P�i tvorb� komplexních informa�ních systém� si dnes ji� nelze vysta�it jen s popisem algoritm� a datových struktur, ale je nutné se zabývat strukturou systému na vyšší úrovni abstrakce.

Vývoj softwaru je disciplínou, která se neustále dramaticky vyvíjí a postupn� stoupá i slo�itosti systém� �ešících nový typ úloh. Proto je nezbytné, aby se na vzniku program� podílel i �lov�k, který se zam��í na komplexní strukturu nového �ešení. Zvlášt� patrná je tato pot�eba v okam�iku, kdy organizace pou�ívá více r�zných informa�ních systém�, které je pot�eba propojit.
�ešením jsou nejr�zn�jší snahy o integra�ní projekty, jejich� cílem je dosáhnout správné struktury celého IT systému organizace. Primárním po�adavkem p�itom je, aby tato struktura byla schopná efektivn� reagovat na zm�ny prost�edí.
Jednou z mnoha odpov�dí, které softwarový pr�mysl p�inesl jako reakci na tento vývoj, je rozvoj nových disciplín, jako je t�eba softwarová architektura. Dalšími jsou nap�íklad nov� vytvá�ené technologie a paradigmata, jako jsou architektura orientovaná na slu�by (nazývaná SOA), zm�ny v metodikách, nap�íklad iterativní vývoj �i agilní metodiky a další. V tomto �lánku bychom se však rádi zam��ili práv� na softwarovou architekturu a oblasti s ní související.

Softwarová architektura
Softwarová architektura je obor velmi mladý, a to i v kontextu vývoje softwaru, p�i�em� její ko�eny spadají do konce osmdesátých �i za�átku devadesátých let. Vznik pot�eby nového oboru softwarové architektury také souvisí s bleskovým rozvojem internetu b�hem devadesátých let, který p�inesl firmám ne�ekané mo�nosti v dobývání nových pozic na trhu a znamenal nové komplexn�jší po�adavky obchodu na IT slo�ku organizace. I p�es sv�j mladý v�k si softwarová architektura ji� však dokázala ve vývoji softwaru najít své místo.

Pokud se podíváte detailn�ji na strukturu IT slo�ky velkých spole�ností, jako jsou banky, telekomunika�ní spole�nosti, pojiš�ovny apod., naleznete zde zpravidla také odd�lení nebo skupinu lidí, kte�í se softwarovou architekturou úzce zabývají.
Softwarová architektura ale není v rámci vývoje softwaru n��ím, co by viselo jaksi ve vzduchoprázdnu. Cokoli, co je jejím výstupem, musí být spojeno s n�jakým po�adavkem �i pot�ebou spjatou s obchodním p�ínosem organizaci. Softwarová architektura tedy pracuje s pot�ebami/po�adavky a tyto transformuje do struktury vytvá�eného systému. D�le�itými aktivitami v tomto procesu jsou dekompozice systému na menší celky, nazývané nap�íklad komponenty, definice rozhraní mezi komponentami a vytvá�ení vhodných abstrakcí. Dalším d�le�itým p�edm�tem zájmu softwarové architektury jsou po�adavky nesouvisející p�ímo s funkcionalitou systému, kolektivn� ozna�ované jako atributy kvality. 

Architektura v IT
Softwarová architektura není jedinou „architekturou“ v oboru informa�ních technologií. Objevuje se zde toti� více r�zných pojm�, které v sob� slovo architektura obsahují a které s oborem softwarové architektury souvisejí.

• Business Architecture se primárn� zabývá obchodními strategiemi, �ízením, organizací a klí�ovými obchodními procesy. I kdy� tyto aktivity na první pohled nepat�í v�bec do oboru informa�ních technologií, je pot�eba si uv�domit, �e dnešní organizace a jejich procesy jsou s informa�ními technologiemi velmi úzce spjaty a n�které obory, jako nap�íklad telekomunikace, jsou na nich p�ímo fyzicky závislé.
• Information Technology Architecture definuje hardwarovou a softwarovou infrastrukturu pot�ebnou pro chod organizace a zabývá se otázkou, jak správn� a efektivn� �ídit investice do IT infrastruktury.
• Information Architecture se zabývá organizací a správou dat. V�tšina podnik� má k dispozici velké mno�ství dat, které jí mohou pomoci v obchodním rozhodování, ale smutnou skute�ností je, �e organizace zpravidla s t�mito daty nedoká�í efektivn� nakládat. Do této kategorie architektury spadá t�eba Master Data Management, business intelligence, datové sklady apod.
• Enterprise Architecture je pojem sdru�ující v sob� Business Architecture, Information Technology Architecture, Information architecture i softwarovou architekturu.

Softwarová architektura se v tomto kontextu zabývá tvorbou i rozvojem jednoho systému (aplikace) a jeho zasazením do prost�edí jeho b�hu, tedy nasazením systému na existující hardwarovou a softwarovou infrastrukturu a integrací systému s ostatními systémy. Pot�eba upravit stávající informa�ní systém, p�ípadn� vytvo�it nový, vychází zpravidla z pot�eb zm�ny nebo lepší podpory obchodních proces�, tedy z Business Architecture. Softwarová architektura pak pro dosa�ení svých cíl� vyu�ívá prost�edk� poskytovaných Information Technology Architecture a Information Architecture. Je vhodné doplnit, �e se v praxi lze setkat s r�znými dalšími pojmy, jako jsou Application architecture, System(s) architecture, Solution Architecture. I kdy� v ka�dé organizaci m��e ka�dý z t�chto pojm� znamenat trošku n�co jiného, dá se však zjednodušen� p�edpokládat, �e se jimi myslí práv� softwarová architektura.

Role architekta
S p�íchodem softwarové architektury se objevila v procesu vývoje softwaru také nová role softwarového architekta. Ten je zodpov�dný za návrh správné architektury systému tak, aby systém byl schopen naplnit po�adovanou funkcionalitu p�i dosa�ení po�adované kvality.
K tomu, aby �lov�k byl v pozici softwarového architekta úsp�šný, musí disponovat sadou znalostí a dovedností. Na jedné stran� jsou to takzvané „hard skills“, tedy dovednosti týkající se p�ímo meritu jeho práce, jako jsou znalosti technologií, schopnost návrhu systému, schopnost rychlé orientace v problémové oblasti, schopnost odhadovat pracnost a �asovou náro�nost �ešení atd.
Na stran� druhé jsou pak vy�adovány takzvané „soft skills“, neboli schopnosti komunikace, prezentace, dokumentace, vyjednávání, mediace. Vše dopl�ují po�adavky na mana�erské dovednosti, jako jsou vedení lidí, plánování, správa rizik, schopnost rozd�lování a delegace práce. Po�adavky kladené na kvalitního architekta jsou tedy tak vysoké, �e se tato role m��e bezpochyby m��it s ostatními mana�erskými posty.
Stejn� jako u pojmu „architektura“ se m��ete také s pojmem „architekt“ v oboru IT setkat na mnoha místech. Situace v oboru je taková, �e slovo „architekt“ má dnes na vizitce ji� skute�n� leckdo. Proto se krom� softwarového architekta (nazývaného té� systémový nebo aplika�ní architekt) lze v oboru setkat s rolemi Enterprise architect, Solution architect, Information architect, Data architect, Integration architect a dalšími.
S nadsázkou lze tedy �íci, �e sv�t IT dnes �elí invazi architekt�. Není autorovým úmyslem zde tvrdit, �e pokud má n�kdo na vizitce uvedeno softwarový architekt, pak je n��ím víc. Spíše bych rád upozornil na skute�nost, �e pou�ívaných termín� je mnoho a ka�dá organizace si je vykládá po svém. Proto je v�dy nutné se detailn� seznámit s tím, jaká je nápl� té �i oné role v p�íslušné organizaci.

Atributy kvality
Jedním z úkol� softwarového architekta je spolupráce na ur�ení atribut� kvality po�adovaného �ešení a navr�ení cílové architektury systému tak, aby tyto atributy kvality byly co nejlépe napln�ny. Atributy kvality jsou myšleny takové po�adavky na vytvá�ený systém, které nesouvisejí p�ímo s jeho funkcionalitou, ale mají vliv na jeho pou�ívání, provozování a další rozvoj. Jako p�íklad nej�ast�jších atribut� kvality lze uvést po�adavky na výkon, bezpe�nost, škálovatelnost, dostupnost apod.
Jedním z úskalí práce s atributy kvality je, �e jsou mnohdy protich�dné.
Tento jev velmi zt�uje softwarovému architektovi jeho práci. Ten je proto p�i návrhu systému zpravidla postaven p�ed situaci, kterou nelze �ešit jinak ne� hledáním kompromis� mezi jednotlivými atributy kvality a obhajobou nalezených �ešení sm�rem k zadavatel�m i implementa�nímu týmu.

Návrh architektury
P�i návrhu architektury systému se v celém procesu objevují t�i základní aktivity:

• zjišt�ní architektonicky významných po�adavk�,
• návrh architektury systému,
• ov��ení navr�ené architektury.

Zjišt�ní architektonicky významných po�adavk� v sob� zahrnuje identifikaci významných scéná�� pou�ití systému a zjišt�ní a popis po�adovaných atribut� kvality. D�le�itý je v tomto kontextu takový po�adavek, který má vliv na architekturu systému.
Ostatními po�adavky na systém, které vliv nemají, se softwarový architekt nezabývá.
B�hem návrhu architektury systému softwarový architekt rozd�luje systém do komponent, definuje jejich odpov�dnosti, vztahy a rozhraní. P�i návrhu p�itom zpravidla vychází z n�kterého ze známých architektonických vzor�, a sna�í se naplnit všechny po�adavky zjišt�né v p�edchozím kroku a v této fázi také vybírá pou�ité technologie.
V okam�iku, kdy je architektura systému navr�ena, je nutné ji také ov��it. Nej�ast�ji pou�ívanou technikou je tvorba prototyp� a jejich testování. Existují také další techniky jako nap�íklad manuální ov��ení technikou procházení významných scéná�� pou�ití systému.

Celý výše uvedený proces je velmi iterativní, architekturu systému nelze navrhnout na jeden pr�chod. Proto se architekt na základ� získaných znalostí k jednotlivým aktivitám vrací, upravuje jejich výstupy a znovu postupuje vp�ed, dokud architektura dostate�n� nenapl�uje všechny po�adavky na funkcionalitu a kvalitu.
Není to v�bec jednoduchý proces. Architekt musí navrhnout koncepci a strukturu systému a vybrat technologie d�íve, ne� za�ne vlastní vývoj. Situace je o to komplikovan�jší, �e vstupem tohoto procesu jsou �asto protich�dné po�adavky týkající se p�edevším atribut� kvality. Vše navíc umoc�uje tlak na dodr�ení rozpo�t� a termín� p�i sou�asném dodr�ení po�adované kvality �ešení.
Pom�rn� trefn� tuto nelehkou situaci shrnul Philippe Kruchten, jedna z významných osobností na poli softwarové architektury, kdy� prohlásil: „�ivot softwarového architekta je dlouhý (a n�kdy bolestný) sled suboptimálních rozhodnutí, která jsou �in�na �áste�n� v temnot�.“ 

�ivotní cyklus projektu
Zasa�me si pojmy softwarová architektura a softwarový architekt do �ivotního cyklu vývoje softwarového projektu. Role softwarového architekta se na projektu podílí ji� od prvních fází vývoje, tedy ji� ve fázi stanovování vize a definice hrubého zadání projektu. V této fázi je softwarový architekt konzultantem, který posuzuje proveditelnost �ešení, navrhuje první koncepty vlastního �ešení a pomáhá vytvá�et velmi hrubé odhady pracnosti.
T�išt� jeho práce pak spadá do fáze, které se n�kdy �íká studie proveditelnosti, jindy analýza a design, v metodice Rational Unified Process pak fáze rozpracování (Elaboration). V této fázi architekt identifikuje architektonicky d�le�ité po�adavky na systém a na jejich základ� navrhuje a ov��uje architekturu systému a zjiš�uje mo�ná rizika.
Výsledkem procesu je sada model� a popis� souhrnn� nazývaná nap�íklad dokument architektury softwaru (Software Architecture Document).

Dalšími aktivitami architekta jsou spolupráce na detailním odhadu a harmonogramu fází vývoje i nasazení a také identifikace architektonických rizik v�etn� popisu strategií vedoucích k jejich odstran�ní.
V dalších fázích vývoje systému, které zahrnují p�edevším aktivity týkající se implementace, testování a nasazení systému, architekt funguje p�edevším jako konzultant vývojovému týmu a jako spolu�ešitel konflikt� a potí�í, které b�hem t�chto fází vyvstanou a jsou spjaty s architekturou systému. Dále se architekt zabývá procesem správy architektonických rizik a podílí se na procesu správy zm�n, proto�e zm�ny po�adavk� b�hem vývoje systému jsou jeho nedílnou sou�ástí. Zkušený softwarový architekt v t�chto fázích také sbírá zp�tnou vazbu a opakovan� provádí vyhodnocování svých p�edchozích rozhodnutí. Odm�nou za tuto �innost jsou mu pak znalosti a zkušenosti, které uplatní v dalších projektech.