vyjadřuje rozhodnutí o návrhu, která určují primární vlastnosti chování a struktury programu (softwarového systému). Strategická rozhodnutí řeší globální, celosystémové problémy a nesou s sebou největší důsledky. Strategická rozhodnutí zahrnují volbu programovacího paradigmatu („objektově orientované programování“), architektonického stylu („roury a filtry“), aplikačního rámce („Microsoft Foundation Classes“), standardů softwarového inženýrství založených na komponentách („Enterprise JavaBeans“) a principů návrhu („univerzální základní třída“), stejně jako předpoklady, které mohou vést k architektonickému nesouladu („Server Softbench Broadcast Message Server očekával, že všechny komponenty budou mít grafické uživatelské rozhraní“) a zákonitosti řízené zákony („každá třída v systému dědí z třídy C“). Vzhledem k důsledkům, které s sebou nesou, musí být strategická rozhodnutí učiněna na počátku procesu vývoje softwaru a měla by být explicitně stanovena před provedením jakéhokoli podrobného návrhu.
Naproti tomu taktické návrhové výroky vyjadřují návrhová rozhodnutí, která se týkají konkrétního modulu. Taktická rozhodnutí často popisují vzorec korelací mezi jednou kolekcí modulů (objekty, procedurami, třídami atd.) a jinou. Intuitivně řečeno, Taktické příkazy jsou „lokální“ v tom smyslu, že jejich rozsah je omezen na určitou část programu a ne mimo ni. Mezi taktická rozhodnutí patří volba návrhových vzorů („Factory Method“), refaktorizace („Replace Conditional With Polymorphism“) a programátorských idiomů („Counted pointer“) a obvykle se v procesu vývoje softwaru přijímají mnohem později než strategická návrhová rozhodnutí.
Ačkoli v zásadě souhlasím s obecným pravidlem globální = strategické a lokální = taktické, nemělo by být považováno za absolutní. Je možné, aby jeden segment systému měl aspekty, které silně ovlivňují celkovou architekturu (což odůvodňuje Boochova kritéria významnosti). To je důvod, proč nezastávám názor, že funkční požadavky jsou návrh a nefunkční jsou architektura.
Arnon Rotem-Gal-Oz, manažer architektury ve společnosti Nice Systems, ve své prezentaci „Architektura softwaru“ identifikuje několik aspektů architektury. Architektura zahrnuje hlavní součásti systému; jejich vztahy a interakce. Data a chování těchto hlavních komponent jsou pro architekturu relevantní pouze z hlediska interakcí mezi těmito komponentami. Stejně jako Booch i Rotem-Gal-Oz charakterizuje architekturu jako nejobtížněji měnitelné části systému. Stejně jako Eden, Kazman a Hirshfeld definuje architekturu jako rozhodnutí o návrhu, která musí být učiněna nejdříve v procesu.
Cena strategických, základních rozhodnutí o návrhu by měla být zřejmá. Vzhledem k tomu, že tyto aspekty systému je obtížné a nákladné měnit, měla by existovat značná motivace k optimálním rozhodnutím. Jak poznamenal Kevlin Henney v článku „What is Software Architecture?“ na serveru developerFusion:
Nejde o to, zda systém má nebo nemá architekturu, ale zda je jeho architektura dobrá nebo ne. Všechny systémy mají architekturu, ať už záměrnou nebo náhodnou, explicitní nebo implicitní, dobrou nebo špatnou – dokonce i systémy „bez architektury“ mají architekturu!
Pokud jsme architekturu vztáhli k nákladům na změnu, máme jednoduchý způsob hodnocení kvality architektury. Nejde o to, že díky dobré architektuře je levné systém vytvořit; jde o to, že je také levné jej vyvíjet. Jinými slovy, dobrá architektura je taková, v níž je význam návrhových rozhodnutí minimalizován. Můžete svobodně měnit mnoho aspektů systému bez obav, že takové změny budou náročné, nákladné nebo vytvoří kaskádu chyb. Dobrá architektura je tedy architekturou udržitelnou.
Vzhledem ke kritičnosti těchto návrhových rozhodnutí nemá smysl ponechávat je náhodě. Udržitelná a flexibilní architektura pravděpodobně nevznikne organicky. Bude zapotřebí dostatečné plánování a koordinace ze strany někoho v roli architekta (bez ohledu na to, zda je tato role na plný nebo částečný úvazek). V tomto rámci pak lze decentralizovaně přijímat lokalizovaná rozhodnutí o návrhu.
Občas slyším, jak lidé stále vznášejí agilní mantru proti Big Design/Requirements Up Front. Jde o to, že Manifest Agile nikdy neříkal, že je třeba záměrně strkat hlavu do písku, pokud jde o účel systému. Byl to tlak proti trávení měsíců analýzou, aniž by z toho vyšlo něco jiného než dokumenty, ale cílem bylo dosáhnout střední cesty. Nikdo nikdy neřekl „žádný návrh předem“ nebo „žádné požadavky předem“.
(Udi Dahan z knihy „Cesta CQRS – s Microsoftem a bez něj“)
Převzato z Form Follows Function
.