suunnittelupäätökset, jotka määrittävät ohjelman (ohjelmistojärjestelmän) ensisijaiset käyttäytymis- ja rakenneominaisuudet. Strategiset päätökset kohdistuvat globaaleihin, koko järjestelmän laajuisiin huolenaiheisiin, ja niillä on suurimmat seuraukset. Strategisiin päätöksiin kuuluvat ohjelmointiparadigman (”olio-ohjelmointi”), arkkitehtuurityylin (”putket ja suodattimet”), sovelluskehyksen (”Microsoft Foundation Classes”), komponenttipohjaisten ohjelmistosuunnittelustandardien (”Enterprise JavaBeans”) ja suunnitteluperiaatteiden (”universaali perusluokka”) valinta sekä oletukset, jotka voivat johtaa arkkitehtuurin yhteensopimattomuuteen (”Softbenchin lähetysviestipalvelin odotti, että kaikilla komponenteilla on oltava graafinen käyttöliittymä”), ja lakien säätelemät säännöllisyyksien soveltaminen (”kaikki järjestelmän luokat periytyvät luokan C luokkien väliltä C”). Niiden seurausten vuoksi strategiset päätökset on tehtävä ohjelmistokehitysprosessin alkuvaiheessa, ja ne on määriteltävä nimenomaisesti ennen yksityiskohtaisen suunnittelun aloittamista.
Taktiset suunnittelulausekkeet sen sijaan ilmaisevat suunnittelupäätökset, jotka koskevat tiettyä moduulia. Taktiset päätökset kuvaavat usein yhden moduulikokoelman (objektit, proseduurit, luokat jne.) ja toisen moduulikokoelman (objektit, proseduurit, luokat jne.) välistä korrelaatiomallia. Intuitiivisesti ajateltuna taktiset lausekkeet ovat ”paikallisia” siinä mielessä, että niiden soveltamisala rajoittuu johonkin ohjelman osaan eikä sen ulkopuolelle. Taktisia päätöksiä ovat esimerkiksi suunnittelumallien valinta (”Factory Method”), refaktoroinnit (”Replace Conditional With Polymorphism”) ja ohjelmointi-idiomit (”counted pointer”), ja ne tehdään yleensä paljon myöhemmin kuin strategiset suunnittelupäätökset ohjelmistokehitysprosessissa.
Vaikka olenkin pitkälti samaa mieltä yleissäännöstä, jonka mukaan globaali = strateginen ja paikallinen = taktinen, sitä ei kuitenkaan pidä pitää ehdottomana. On mahdollista, että järjestelmän yhdellä segmentillä on näkökohtia, jotka vaikuttavat voimakkaasti kokonaisarkkitehtuuriin (mikä oikeuttaa Boochin merkittävyyskriteerit). Tästä syystä en ole sitä mieltä, että toiminnalliset vaatimukset ovat suunnittelua ja ei-toiminnalliset arkkitehtuuria.
Arnon Rotem-Gal-Oz, arkkitehtuuripäällikkö Nice Systemsillä, erittelee useita arkkitehtuurin näkökohtia esityksessään ”Software Architecture”. Arkkitehtuuri käsittää järjestelmän pääkomponentit, niiden suhteet ja vuorovaikutukset. Näiden pääkomponenttien tiedot ja käyttäytyminen ovat arkkitehtuurin kannalta merkityksellisiä vain näiden komponenttien välisten vuorovaikutusten näkökulmasta. Boochin tavoin Rotem-Gal-Oz luonnehtii arkkitehtuuria järjestelmän vaikeimmin muutettaviksi osiksi. Edenin, Kazmanin ja Hirshfeldin tavoin hän määrittelee arkkitehtuurin suunnittelupäätöksiksi, jotka on tehtävä prosessin varhaisimmassa vaiheessa.
Strategisten, perustavanlaatuisten suunnittelupäätösten arvon pitäisi olla ilmeinen. Koska näitä järjestelmän osia on sekä vaikea että kallis muuttaa, optimaalisten valintojen tekemiseen pitäisi olla huomattava kannustin. Kuten Kevlin Henney toteaa developerFusionin artikkelissa ”What is Software Architecture?”:
Kysymys ei ole siitä, onko järjestelmällä arkkitehtuuri vai ei, vaan siitä, onko sen arkkitehtuuri hyvä vai ei. Kaikilla järjestelmillä on arkkitehtuuri, oli se sitten tarkoituksellista tai satunnaista, eksplisiittistä tai implisiittistä, hyvää tai huonoa – jopa ”ei arkkitehtuuria”-järjestelmillä on arkkitehtuuri!
Sitottuamme arkkitehtuurin ja muutoskustannusten väliseen suhteeseen meillä on yksinkertainen tapa arvioida arkkitehtuurin laatua. Kyse ei ole siitä, että hyvä arkkitehtuuri tekee järjestelmästä halvan luoda; kyse on siitä, että sitä on myös halpa kehittää. Toisin sanoen hyvä arkkitehtuuri on sellainen, jossa suunnittelupäätösten merkitys on minimoitu. Voit vapaasti muuttaa monia järjestelmän osa-alueita ilman pelkoa siitä, että muutokset ovat haastavia, kalliita tai aiheuttavat vikojen kaskadin. Hyvä arkkitehtuuri on siis kestävä.
Kun otetaan huomioon näiden suunnittelupäätösten kriittisyys, ei ole järkevää jättää niitä sattuman varaan. Kestävä, joustava arkkitehtuuri ei todennäköisesti synny orgaanisesti. Tarvitaan riittävää suunnittelua ja koordinointia joltakin arkkitehdin roolissa olevalta (riippumatta siitä, onko rooli koko- vai osa-aikainen). Paikalliset suunnittelupäätökset voidaan sitten tehdä tämän kehyksen sisällä hajautetusti.
Tällöin kuulen ihmisten edelleen nostavan esiin ketterän mantran Big Design/Requirements Up Frontia vastaan. Asia on niin, että Agile Manifesto ei koskaan sanonut, että pitää tarkoituksella haudata pää hiekkaan järjestelmän tarkoituksen suhteen. Se oli vastalause sitä vastaan, että käytettäisiin kuukausia analyyseihin ilman, että mitään muuta kuin dokumentteja syntyy, mutta tavoitteena oli päästä keskitien päähän. Kukaan ei koskaan sanonut ”ei suunnittelua etukäteen” tai ”ei vaatimuksia etukäteen”.
(Udi Dahan artikkelista ”A CQRS Journey – with and without Microsoft”)
Reposted from Form Follows Function