V roce 2008 vyšel český překlad velmi zajímavé knihy věnované správě softwarových požadavků: "Požadavky na software" Originál vydal Microsoft Press, český překlad vydal Computer Press. Na tuto knihu jsem si vzpomněl, když jsem se začetl do knihy dvojice autorů  Petera Eeles a Petere Crippse „Softwarová architektura“. Obě pojednávají na téma vývoj softwaru. Jedna akcentuje zejména vývoj a správu požadavků, druhá akcentuje proces a postupy navrhování softwaru. Obě se vyznačují vyváženou kombinací teorie a praxe, s jasným zaměřením na pomoc při praktickém projektování softwarových systémů. Obě jsou psány srozumitelným jazykem, jsou bohaté na postupy a metody, obě zdůrazňují procesní přístup. Troufnu si říci, že by obě patřily do povinné literatury pro řadu profesů z oblasti ICT a její implementace v businessu. 
-
Knihu napsali velmi zkušení autoři:
Peter Eeles působí v softwarovém průmyslu od roku 1985. Je vedoucím IT architektem, ve své funkci pomáhá firmám zlepšovat jejich procesy při vývoji softwaru, přičemž se zaměřuje a zajímá především o proces navrhování. Má za sebou poměrně bohatou autorskou činnost.
Peter Cripps je IT architektem.  Během své kariéry pracoval jako programátor, softwarový inženýr a procesní inženýr v mnoha odvětvích. Do oblasti jeho zájmů patří především návrh postupů pro vývoj dobré softwarové architektury.

Kniha se zaměřuje na ty úkoly, související s architekturou, s nimiž se může čtenář setkat poměrně často a které může použít v mnoha různých typech organizací, obchodních oblastí, systémů apod.

Obsah:
- Úvod do architektury softwaru
- Architektura, Architekt, Navrhování
- Základy metody
- Dokumentace architektury softwaru
- Opětovně použitelné prvky architektury
- Úvod do případové studie
- Definice požadavků
- Tvorba logické architektury
- Tvorba fyzické architektury
- Za hranicemi základů
- PŘÍLOHA A - Metamodel architektury softwaru
- PŘÍLOHA B - Katalog hledisek
- PŘÍLOHA C - Přehled metody
- PŘÍLOHA D - Kontrolní seznam požadavků na architekturu
- Přehled pojmů

Podtitulek knihy zní: „ Nepostradatelný průvodce návrhem softwarové architektury, která funguje“.  Kniha je dobrým rádcem ve všech fázích procesu, jehož cílem je vývoj softwaru. Dozvíte se, co je architektura softwaru, jak se projevuje, kdo ji dělá a jaké jsou její vazby na další části projektů. Základní orientace autorů, je zaměřena na zkoumání metody navrhování. Při tom využívají zejména modelový přístup.
Překlenutí mezery mezi logickou a fyzickou architekturou systému při výkladu systému, je pro mnohé autory z dané oblasti obtížným a ne vždy úspěšně řešeným problémem. O to více si bude čtenář knihy „Architektura softwaru“ vážit autory zvoleného přístupu, který v sobě spojuje teoretickou a praktickou část problému.
Autoři zvolili optimální vztah mezi podrobností výkladu a jeho srozumitelností. Díky tomu se jim podařilo vytvořit úplný obrázek architektury systému.  K nejcennějším částem knihy patří komplexní pohled na roli architekta softwaru, případně celého týmu architektury systému.

Tato kniha je pozoruhodná zejména tím, že – aniž by ignorovala teorii – její těžiště leží v praktických návodech, orientovaných na navrhování softwaru. Návody a postupy prezentují autoři formou, která umožňuje jejich okamžité využití v praktické činnosti. Autoři staví na svých bohatých zkušenostech v oblasti vývoje softwaru. Na základě dobře zvolené a systémově prezentované případové studie, autoři ilustrují praktické využití myšlenek prezentovaných v jednotlivých kapitolách knihy.

Existuje řada knih, popisujících určité aspekty procesu navrhování softwaru. Některé z těchto knih se věnují například dokumentování architektury softwaru, jiné zase jejímu vyhodnocování. Každý z těchto aspektů zapadá do většího celku, neboť každý z nich představuje důležitý prvek procesu navrhování softwaru. Jedním z cílů knihy autorské dvojice P.Eelese a P. Crippse je ukázat tento větší celek, a to pomocí konsolidovaného pohledu na všechny aspekty navrhování v kontextu typického projektu vývoje softwaru.

Autoři sami zdůrazňují, že jejich kniha nepředepisuje žádný konkrétní způsob pro vývoj softwaru. Namísto toho popisuje klíčové prvky, s nimiž se setkáváme v kterémkoliv moderním vývojovém prostředí v rámci podpory procesu návrhu.

Tato kniha je určena především softwarovým architektům (či těm, kteří se jimi chtějí stát), snažícím se pochopit to, jak jejich role zapadá do celého procesu vývoje softwaru. Může však být užitečná i pro specializované architekty. Vzhledem k zvolenému přístupu prezentace poznatků, může knihu využít každý, kdo chce lépe pochopit roli softwarového architekta.  Prostudování knihy může být přínosem pro všechny členy vývojového týmu, včetně vývojářů samotných, testerů, business analytiků, projektových manažerů, manažerů konfigurace a procesních inženýrů. Knihu ocení i studenti a pedagogové, kteří chtějí získat představu o rostoucím roli softwarových architektů během procesu vývoje softwaru.
Kniha může být přínosem pro každého, kdo chce navrhovat lepší software, kdo cítí potřebu prověřit a zdokonalit základy architektury  navrženého projektu a kdo se che naučit navrhovat architekturu, která se stane základem úspěšného projektu.

Dvojice autorů nám nabízí základní postupy nutné pro správný návrh softwarové architektury a  proces tvorby dokumentace a znovupoužitelných prvků architektury.

Kniha je zhruba rozdělena do tří částí.
První část je tvořená kapitolami 1 až 5,  obsahujícími souhrnný přehled základních konceptů architektury, roli architekta a postupy navrhování, dokumentování architektury softwaru a opakovaně použitelných prvků architektury.
Druhá část sestává z kapitol 6 až 9 a její hlavní náplní jsou kapitoly, související s případovou studií.
Tyto kapitoly nás na základě ukázkové aplikace provázejí vhodně vybraným typickým projektem vývoje softwaru, přičemž naše pozornost je směrována především k roli architekta. Zvolený přístup výkladu obsahu těchto kapitol nám umožňuje rychlé čtení a snadné vyhledání těch témat, která nás zajímají. Každá kapitola, související s případovou studií, je uspořádána podle úkolů a činností
V poslední části knihy nacházíme kapitolu 10, obsahující různá dílčí témata, Zabývají se možnostmi využití konceptů, popsaných v předcházejících kapitolách, při navrhování složitých systémů.

V případové studii se autoři zaměřili na roli architekta v procesu vzniku softwaru a na obvyklé problémy, které tento proces mohou provázet. Knihu uzavírá soubor univerzálních postupů, které lze aplikovat na většinu dnes vznikajících složitých systémů.

Kniha je cenným zdrojem informací nejen pro softwarové architekty, hodnotné informace v ní najdou i projektoví manažeři, vedoucí vývojových týmů, programátoři, testeři a analytici.

V knize se čtenář naučí:
- znát vazby architektury na další části softwarového projektu
- zvládnout roli architekta v typickém projektu vývoje softwaru
- přesně navrhnout architekturu na základě požadavků
- nasazovat opětovně použitelné prvky architektury
- vytvářet dokumentaci architektury pro další zainteresované strany
- spolupracovat s dalšími členy vývojového týmu

Vydání této knihy bylo provázeno zpřístupněním webové stránky:
http://processsoftwarearchitecting.com
na které čtenáři najdou dodatečné informace a jejímž prostřednictvím mohou i komunikovat s autory. Stránka je spravována jedním z autorů knihy.
Na webu CPressu ( www.cpress.cz ) najdete nejen výstižnou anotaci knihy, ale i její podrobný obsah, kopii úvodu ke knize a vhodně vybranou ukázkovou kapitolu s názvem „Základy metody“.

Podrobnější charakteristika knihy
Kniha je pozoruhodná nejen svým obsahem, ale i přístupem k tématu. Ve svaze o přiblížení přístupu autorů, jsem zvolil kombinaci vlastního hodnocení a volné citace z textu knihy

Účelem první kapitoly je seznámit čtenáře s tématy, rozebíranými v následujících částech  knihy.
V druhé kapitole, ještě než se ponoří do rozboru detailů, se autoři snaží ujasnit (či definovat) některé základní koncepty, s nimiž pracují ve zbývajících částech knihy. Těmito koncepty jsou role architekta, vlastnosti jednotlivých úloh navrhování, které architekt provádí, a výsledná architektura.  V textu druhé kapitoly se seznámíme s třemi základními koncepty, vztahujícími se k tématu této knihy. V závěru nacházíme pojednání o přínosech navrhování. Zmíněnými třemi koncepty jsou role architekta, vlastnosti jednotlivých úloh navrhování, které architekt provádí, a výsledná architektura.  Role architekta představuje v každém projektu vývoje softwaru tu největší výzvu. Architekta považují autoři knihy za technického vedoucího projektu a z technického hlediska také nese odpovědnost za technický úspěch či neúspěch celého projektu.

Velkou pozornost věnují autoři metamodelu architektury softwaru.
Úplný popis metamodelu, používaného v této knize, prezentují autoři v příloze A.
Vztahy v tomto metamodelu zobrazují autoři ve schématu a slovně je vyjadřují takto:
- Systém má architekturu.
- Systém plní jeden či více cílů.
- Systém má jednoho či více investorů.
- Systém existuje v nějakém prostředí.
- Prostředí ovlivňuje systém.
- Architektura je popsána popisem architektury.
- Popis architektury identifikuje jednoho či více investorů.
- Popis architektury identifikuje jeden či více zájmů.
- Popis architektury obsahuje základ.
- Investor má jeden či více zájmů.
- Zájem je důležitý pro jednoho či více investorů.

Tyto hlavní vztahy doplňují autoři dalšími, vedlejšími vztahy:
- Vývojový projekt je řešen týmem.
- Vývojový projekt následuje vývojový proces.
- Vývojový projekt vyvíjí systém.
- Vývojový proces obsahuje navrhování.
- Firma obsahuje architekta.
- Architekt provádí navrhování.
- Architekt vytváří architekturu.
- Architekt je určitým druhem investora.
- Výsledkem navrhování je architektura.
- Základ odůvodňuje jedno či více rozhodnutí o architektuře.
- Rozhodnutí o architektuře odpovídá na jeden či více zájmů.

Navrhování softwaru považují autoři za uznávanou vědní disciplínu, byť se stále ještě vyvíjí. S tímto uznáním přichází také důraz na postupy, procesy a prvky, zaměřený na zvýšení zralosti procesu navrhování. Jedním z možných způsobů rychlého zvýšení zralosti je čerpání z již existujících znalostí.  Ačkoliv navrhování softwaru  považují autoři  za vědu, vždy je nutné v tomto procesu vynaložit určitý stupeň kreativity, což je obzvláště pravdivé ve chvíli, kdy před vámi stojí úkol navrhnout architekturu pro nějaký zcela nový systém, pro který dosud neexistuje žádný vzor.

Podle autorů platí, že proces navrhování hraje klíčovou roli při snižování nákladů, zvyšování kvality, zajištění včasné dodávky, zajištění dodávky odpovídající požadavkům a snižování rizik.
- Navrhování řeší otázku systémových kvalit
- Navrhování vede ke shodě
- Navrhování podporuje proces plánování
- Navrhování umožňuje zachování integrity návrhu
- Navrhování pomáhá řídit složitost
- Navrhování vytváří základ pro opětovnou použitelnost
- Navrhování snižuje náklady na údržbu
- Navrhování podporuje analýzu dopadu

Navrhování architektury softwaru pokrývá mnoho disciplín
Autoři zdůrazňují skutečnost, že se architekt se vedle navrhování účastní také mnoha dalších aspektů vývojového procesu softwaru. V knize se uvádí následujícíc:
- Architekt se podílí na formulaci požadavků, čímž například zajišťuje zachycení těch požadavku, které mají pro architekta zvláštní význam.
- Architekt se účastní procesu prioritizace požadavků.
- Architekt se účastní implementace, definuje struktury implementace, které budou použity pro uspořádání jak zdrojového kódu, tak i výsledných spustitelných produktů.
- Architekt se účastní testování, čímž si ověří to, že jím navržená architektura je jak testovatelná, tak i otestována.
- Architekt je odpovědný za určité prvky vývojového prostředí, a to především z hlediska definice určitých standardů a směrnic projektu.
- Architekt pomáhá při definici strategie řízení konfigurace, neboť struktury řízení konfigurace ^odporující správu verzí) často odrážejí definovanou architekturu.
 
Druhá kapitola definuje a vysvětluje základní koncepty, používané v dalších částech této knihy: architekturu, architekta a navrhování. Autoři odpovídají na otázky: co je výsledkem práce architekta a jaký je vztah role architekta k ostatním rolím, účastnicím se projektu.  Po definici základních konceptů přesouvá se v knize pozornost k jejich využití v rámci celého procesu vývoje softwaru. To je předmětem třetí kapitoly, nazvané „Základy metody“. Osnova kapitoly je stručná ( klíčové koncepty, obsah metody a proces ), ale obsah je bohatý. Třetí kapitola je v plném znění nabízena ke stažení na webu knihy na CPressu.

Hlavním cílem třetí kapitoly je nabídnout přehled klíčových prvků metody, z nichž kniha vychází. Tato kapitola je základem pro kapitoly zbývající, neboť v nich se staví na těchto konceptech. Přehled prvků metody, najdeme v příloze C „Přehled metody“. 
Svoji pozornost přesouvají autoři k aplikaci obsahu metody, a to z hlediska posloupnosti, v níž jsou jednotlivé úkoly prováděny. Obsahem metody se míní role, výsledky práce a úkoly, tvořící příslušnou metodu. Autoři se postupně věnují  všem třem prvkům obsahu.
Mnohé z rozdílů mezi jednotlivými metodami, používanými v softwarovém průmyslu, se týkají především procesu, podle kterého se postupuje, nikoliv rolí, výsledků práce, činností a prováděných úkolů.  Autoři věnují se věnují postupně všem třem typům procesu, označovaným jako sériový proces (proces vodopádu), iterativní proces a agilní proces. Je zdůrazněn rozdíl mezi obsahem metody a procesy stanovujícími tento obsah.

Následující dvě kapitoly – kapitola 4 „Dokumentace architektury softwaru“ a kapitola 5 „Opětovně použitelné prvky architektury“ – se zaměřují na specifické aspekty metody, zaručující důkladnější a podrobnější diskuzi a prostupující celým životním cyklem projektu.

Čtvrtá kapitola je věnována dokumentaci architektury.  Za základní smysle dokumentace architektury softwaru je podle autorů umožnit komunikaci o vytvořené architektuře. Taková komunikace je nezbytná především proto, aby všichni účastníci navržené architektuře porozuměli a mohli včas přijít se svými připomínkami. Díky ní může mít celý vývojový tým konzistentní náhled na vytvářený systém. Čtvrtá kapitola je přednostně věnována pojednání o různých aspektech popisu architektury softwaru. Klíčovými koncepty pro popis architektury jsou hledisko, pohled a model.

Významnou částí čtvrté kapitoly je „Metamodel prvků“ týkajících se popisu architektury, zahrnující:
- Popis architektury uspořádaný podle jednoho či více pohledů.
- Pohled tvořený jedním či více modely.
- Model jako součást jednoho či více pohledů.
- Model jako součást jednoho či více popisů architektury.
- Pohled řídí se hlediskem.
- Popis architektury s výběrem jedno či více hledisek.
- Hledisko určující metody pro jeden či více modelů.
- Hledisko pokrývající jeden či více zájmů.
Za naprosto základní pro popis architektury softwaru považují autoři koncepty, hledisko, pohled a model.

Tvorba modelů má kromě obecných přínosů k dokumentování architektury, několik dalších, specifických přínosů:
- Detekce chyb a opomenutí v brzké fázi životního cyklu.
- Prozkoumání relativních hodnot různých možností. 
- Porozumění dopadům změn. Obsah
- Pomoc pří plánování projektu. Prvky modelu.

Ve čtvrté kapitole nás autoři seznamují s rámcem popisu architektury, založeným na osvědčených postupech, používaných při dokumentování architektury softwaru.
Použití tohoto rámce popisu architektury je názorné ukázáno v kapitolách, věnovaných případové studii (kapitoly 6 až 9). Ještě předtím se autoři věnují dalšímu základnímu konceptu, týkajícímu se navrhování softwarových systémů: opětovnému použití již existujících prvků. Toto téma je námětem páté kapitoly „Opětovné použitelné prvky architektury“

Dílčími tématy páté kapitoly jsou:
- Zdroje architektury
- Model prvků architektury
- Druhy prvků
- Atributy prvku architektury
- Další úvahy týkající se opětovné použitelnosti

Inspirace pro odvození či navržení architektury pochází z mnoha zdrojů a liší se v závislosti na mnoha faktorech, mezi něž patří i původnost systému, metoda, podle níž architekt postupuje, a samozřejmé i zkušenosti architekta.
Architekti přijímají různá rozhodnutí v průběhu celého životního cyklu projektu. Přitom jejich rozhodnutí mohou vycházet ze zkušenosti, metody či nějakého jiného prvku. Rozhodnutí o architektuře jsou mnohdy informativnější než konečná řešení architektury, neboť jejich součástí obvykle bývají diskuze o alternativách a zdůvodnění výběru té či oné volby. Považování rozhodnutí o architektuře za opětovně použitelné prvky je novou, formující se disciplínou. Z tohoto důvodu jsou metody a nástroje, podporující tyto prvky, ve srovnání s metodami a nástroji ostatních popisovaných prvků stále ještě relativně nedokonalé.

Šestá kapitola je nazvána „Úvod do případové studie“.
Cílem této kapitoly je uvést čtenáře do problematiky případové studie, kterou v kapitolách 7 až 9 autoři používají jako příklad. V těchto kapitolách se čtenář postupně seznamuje jak s podrobnými požadavky, tak i se zvoleným řešením.

Předností případové studie je, že na tomto příkladu mohou autoři názorné ukázat mnohé výzvy, které musí architekt řešit na typickém projektu, jako například:
- Základní funkční požadavky.
- Vývojové kvality.
- Běhové kvality.
- Systémová omezení. 
- Opětovně použitelné prvky.
- Integrace aplikací.
- Fyzické rozmístění.

Autoři zdůrazňují význam vize, která představuje první přiblížení toho, co by aplikace měla nabídnout, a z tohoto důvodu slouží jako velmi zásadní vstup při rozhodování o tom, zda v projektu pokračovat či nikoliv. Je-li rozhodnuto o pokračování v projektu, tyto informace se často stávají základem pro vývoj či definici podrobnějších požadavku. Popisem tohoto procesu se zabývá kapitola 7 „Definice požadavků“.

Sedmá kapitola je celá věnována definici požadavků.
Osnova kapitoly je sama o sobě výmluvná. 
- Souvislost požadavku s architekturou
- Funkční a nefunkční požadavky
- Postupy dokumentování požadavků
- Použití procesu
- Porozumění popisům úkolů
- Definice požadavků: přehled činnosti

Důvodem velké pozornosti  tématu definice požadavků, je potřeba pochopit souvislost požadavků s architekturou.
Hodně napoví následující výčet výstupů činnosti Definice požadavků:
- Změnové požadavky
- Funkční požadavky.
- Nefunkční požadavky.
- Seznam prioritizovaných požadavků.
- Protokol RAID.
- Dokument architektury softwaru.
- Požadavky účastníků procesu.
- Kontext systému.
Zvláštní místo přísluší výstupu, který autoři označují pojmem Koncept systému. Tento výstup popisuje celý systém jako jedinou entitu či proces, a identifikuje rozhraní mezi systémem a externími entitami.

V průběhu životního cyklu projektu dochází k postupnému upřesňování požadavku, což ještě více zdůrazňuje potřebu efektivního řízení požadavků a jejich změn. Řízení požadavků prezentují autoři jako systematický přístup ke zjišťování, uspořádávání a dokumentování požadavků na zamýšlený systém takovým způsobem, že jim rozumí všichni účastníci procesu (včetně vývojářů). Kromě toho je to i přístup k vytvoření a následnému udržování shody mezi zákazníkem a projektovým týmem v otázce měnících se požadavků na systém.
Autoři upozorňují na to, že celý projekt je často provázen špatným procesem řízení požadavků, v jehož důsledku jsou přijímány další požadavky od účastníků, aniž by probíhala odpovídající diskuze o jejich dopadech na celý systém. 

V sedmé kapitole nám autoři ukázali proces dokumentování požadavků na systém, vedoucí k následujícím výstupům: Přehledu pojmů, Požadavkům investorů, Kontextu systému, Funkčním požadavkům, Nefunkčním požadavkům a Seznamu prioritizovaných požadavků. Tyto výstupy jsou základem pro vývojové činnosti, popsané v kapitole 8 „Tvorba logické architektury“ a kapitole 9 „Tvorba fyzické architektury“.

Osmá kapitola je věnována tvorbě logické architektury
V této kapitole se autoři věnují úkolům, jejichž cílem je připravit logickou architekturu, realizující ty požadavky, které byly definovány v kapitole 7 „Definice požadavků“.
V této kapitole se poprvé autoři věnují přechodu od požadavků k řešení.

Logická architektura představuje základní kámen přechodu od požadavků k řešení – první krok, zvažující architekturu způsobem, který je převážně nezávislý na konkrétní technologii.

Pozoruhodný je výčet výstupů činnosti Tvorba logické architektury podaný autory:
- Vyhodnocení architektury. 
- Rozhodnutí o architektuře. 
- Přehled architektury.
- Změnový požadavek. 
- Datový model.
- Model nasazení. 
- Funkční model. 
- Protokol RAID. 
- Záznam kontroly. 
- Dokument architektury softwaru.

Úkoly, související s logickou architekturou, považují  autoři za  nejvýraznější ve fázi Rozpracování. V rámci této fáze doporučují autoři zaměřit pozornost především na analýzu těch požadavků, které mají největší vliv na architekturu. Teprve ve fázi Zhotovení se třeba věnovat analýze veškerých zbývajících požadavků. Množství času, které vyžaduje práce na na logické architektuře, se během fáze Zhotovení postupně snižuje, neboť postupně klesá počet požadavků, které je ještě třeba analyzovat. Důraz se přesouvá směrem k vývoji.

Dalším krokem, kterému se autoři v knize věnují, je identifikace rizik, souvisejících s jednotlivými variantami. U každého rizika doporučují autoři knihy uvádět jeho potenciální dopad na dodávku projektu. Kromě samotného konstatování rizik je vhodné také rizika kvantifikovat, a to z hlediska pravděpodobnosti jejich skutečného výskytu a případného vlivu na projekt, pokud se riziko skutečně projeví.

Definice logické architektury považují autoři za  kritickou část celého procesu vývoje softwaru. Je-li tato činnost provedena dobře, výsledkem je robustnější a srozumitelnější architektura, jasně oddělující zájmy jednotlivých prvků systému a rovnoměrné rozdělující odpovědnosti mezi tyto prvky.

V deváté kapitole je vyložen přechod od logické architektury, popsané v kapitole 8 „Tvorba logické architektury“, k tvorbě odpovídající fyzické architektury. Na rozdíl od svého logického protějšku fyzická architektura se již zabývá i všemi produkty a technologiemi, které jsou následně použity pro podrobný fyzický návrh a nakonec i pro psaní kódu.

Tvorba fyzické architektury zahrnuje následující úkoly (činnosti):
- Průzkum prvků architektury
- Definice přehledu architektury
- Dokumentace architektonických rozhodnutí
- Přehled funkčních prvků
- Přehled prvků nasazení
- Ověření architektury
- Ukázka realizovatelnosti architektury
- Podrobné funkční prvky
- Podrobné prvky nasazení
- Validace architektury
- Aktualizace dokumentace architektury softwaru
- Kontrola architektury s investory

V deváté kapitole autoři ukazují na to jak dva klíčové modely, které byly použity pro popis architektury systému – Funkční model a Model nasazení – přecházejí z fáze, kdy obsahují čistě logické (neboli technologicky nezávislé) prvky, do fáze, kdy obsahují fyzické (neboli technologicky specifické) prvky.

Během přechodu od logické architektury k fyzické je třeba zvážit komponenty, lokality, uzly, spojení mezi uzly a jednotky nasazení.

Pří přechodu od logické architektury k fyzické doporučují autoři  provedení několika výběrů:
- Výběr technologie.
- Vyber produktů.
- Opětovně použitelné prvky.
- Vývoj na zakázku.

Tvorba fyzické architektury představuje určité zaměření většinou shodných úkolů, souvisejících s tvorbou architektury. Jediným rozdílem je důraz na fyzické, nikoliv na logické, aspekty vyvíjeného systému.

Autoři zdůrazňují iterativní charakter procesu vývoje architektury softwaru. Architekt musí neustále vylepšovat, ověřovat a potvrzovat architekturu vyvíjeného systému. Současné musí být schopen dosáhnout i souhlasu ze strany všech účastníků procesu, kteří se o vyvíjený systém zajímají. V důsledku získávání dalších a dalších informací a lepšího chápání požadavků je architekt schopen se přesunout od čistě koncepčního pohledu na architekturu k pohledu více fyzickému.

V deváté kapitole autoři ukázali, jakým způsobem můžeme upravit a dále rozvíjet prvky logické architektury, a to na základě použití téhož vzoru procesu pro vytvoření fyzické architektury, jasně identifikujícího technologie, produkty a prvky, které mají být použity pro návrh a sestavení systému

Desátá kapitola knihy, nazvaná „Za hranicemi základů“ se zabývá jak dalšími aspekty projektu vývoje softwaru, tak i specifickými výzvami, souvisejícími s navrhováním systémů ve složitých prostředích.
Jde o tato významná dílčí témata:
- Architekt a projektový tým
- Architekt a externí vlivy
- Navrhování složitých systémů

V této kapitole se autoři věnují především účasti architekta s ohledem na aspekty vývoje softwaru, jimž se nevěnovali v předchozích kapitolách: testování, konfigurační management, změnové řízení a vývojové prostředí. Mohou se vyskytnout některé další složité faktory, vyžadující architektovu pozornost, jako na příklad rozsáhlost systému, velikost týmu, jehož práci musí někdo koordinovat, a distribuovaný vývojový tým – všem těmto tématům se budeme věnovat dále v této kapitole. Autoři pozornost i dalším aspektům projektu vývoje softwaru, přičemž se zaměřují zejména na účast architekta s ohledem na další disciplíny a tedy i role v týmu.

Architekt má vzhledem k požadavkům poměrně různorodou sadu odpovědností. Mezi nejvýznamnější příspěvky architekta řadí autoři zajištění názoru technických uživatelů systému (jako například Systémových administrátorů). Dále se architekt účastní i prioritizace požadavků.

Kniha se sice nezabývá problematikou podnikové architektury, autoři vychází z předpokladu, že pokud si nějaká organizace takovou architekturu definovala, pak veškeré systémy musí bvt vyvíjeny v souladu s těmi oblastmi, které podniková architektura pokrývá.

Principy podnikové architektury vyjadřují:
- Model podniku.
- Model podnikových procesů.
- Podniková pravidla,
- Stávající IT prostředí.

Desátá kapitola doplňuje kapitoly předcházející, a to o seznámení s tématy, která překračují hranice základního chápání role architekta v typickém projektu vývoje softwaru. Cílem autorů knihy bylo popsat řadu postupů, které lze částečně nebo úplně využít v procesu navrhování architektury softwaru. Pokusili se připravit určitý základ znalostí, které by každý architekt mel mít.

Kniha obsahuje 4 přílohy:
Příloha A: Metamodel architektury softwaru
Tato příloha obsahuje úplnou definici metamodelu konceptů, s nimiž jsme v této knize pracovali.
Příloha B: Katalog hledisek
Tato příloha obsahuje přehled všech hledisek, použitých v této knize. Podrobnějšímu popisu problematiky hledisek se věnuje kapitola 4 „Dokumentace architektury softwaru. Oproti popisům hledisek v jednotlivých kapitolách, tato příloha se věnuje především souladu hledisek.
Autoři uvádějí tabulku, v které nacházíme popis souladu mezi všemi pohledy rámce popisu architektury.
Příloha C: Přehled metody
V této příloze najde čtenář souhrnné informace o metodě, kterou autoři použili při přípravě této knihv. Přehled základních konceptů, souvisejících s metodou, pak najdete kapitole 3 „Základy metody“.  Dílčí témata přílohy: role, výstupy. Činnosti, úkoly, fáze. Zvláštní pozornost věnují autoři fázi  „Přechod“. Fáze Přechodu je tou fází, během níž má architekt zajistit to. Že software ie přístupný všem koncovým uživatelům a je jimi také přijat. Jedná se o tu fázi, během níž je systém nasazován do prostředí koncových uživatelů za účelem závěrečného vyhodnocení a testování. Přitom hlavním cílem je vyladění produktu a vyřešení veškerých případných problémů, souvisejících s konfigurací, instalací a použitelností. Na konci této fáze by mělo být možné projekt ukončit.
Poslední, čtvrtou přílohou je příloha D: Kontrolní seznam požadavků na architekturu.
Tato příloha obsahuje kontrolní seznam vybraných požadavků, majících významný vliv na architekturu..
Obsah přílohy je členěn na:
- Funkční požadavky
- Požadavky použitelnosti
- Požadavky spolehlivosti
- Požadavky výkonu
- Požadavky podporovatelnosti
- Omezení

Ačkoliv proces, který autoři popisují, může být použit pro mnoho různých druhů iniciativ, omezili se na jedinou případovou studii, díky níž mohou názorně předvést ty klíčové úkoly, jichž se účastní softwarový architekt. Autoři jsou přesvědčeni, že úkoly, popsané v této knize, mohou být přizpůsobeny potřebám jakékoliv dané situace, a to včetně rozsahu, v němž je každý úkol prováděn.  Autoři vyjadřují optimismus pokud se týče vývoje vztahu lidí k navrhování architektury. Spolu s tím, jak se proces navrhování softwaru stává stále častějším a obvyklejším, vzrůstá pravděpodobnost, že na něj většina lidí přestane pohlížet jako na „nějakou záhadnou sadu postupů“, jimž rozumí pouze několik vyvolených, a začnou jej považovat za široce přístupnou sadu dobře definovaných a vyzkoušených postupů, majících určitý vědecký základ a těšících se všeobecnému přijetí.

Knihu vřele doporučuji všem, kdo chtějí získat přehled o navrhování architektury softwaru

doc. Arnošt Katolický,
18. dubna 2011.