Più volte nei post precedenti mi è capitato di sottolineare la sottile differenza tra Architettura e Design, evidenziando che si commette un errore parlando di “Design Architetturale” perché si coniugano tra loro due fasi progettuali diverse.
Cerchiamo allora di fare un po’ di chiarezza in merito.
Prima di tutto, cos’è un Architettura Software? Ebbene, forse sorprenderà sapere che ad oggi non esiste una definizione universalmente accettata di “Architettura Software”: si tratta del design del sistema o del blue print? Deve contenere dettagli relativi alla tecnologia o deve essere agnostico rispetto ad essa? E’ una visione di business del sistema o un costrutto da passare ai tecnici?
Tutte domande legittime che mettono in evidenza come un’Architettura Software abbracci diversi campi e ammetta più definizioni che enfatizzano diversi aspetti in funzione di chi è il destinatario dell’Architettura stessa.
Partiamo da due assunti:
1. Tutti i sistemi hanno un Architettura!
Sia essa voluta (intentional) che accidentale (accidental), esplicita (explicit) che implicita (implicit), buona (good) o cattiva (poor), non esiste un software senza Architettura.
2. Esistono diversi modi di descrivere e leggere la stessa Architettura!
Ciò è vero perché intorno ad un progetto (soprattutto enterprise) ruotano una serie disomogenea di stakeholder: dal committente, al developer, allo sponsor. Ognuno ha bisogno di una declinazione dell’Architettura in funzione delle proprie esigenze.
Bisogna evitare di sovraccaricare la descrizione architetturale (overly complex) così come bisogna essere capaci di non renderla povera (poor) e quindi inutile.
Lo scopo di una buona Architettura è quello di rendere il sistema “evolvibile”, quindi favorirne l’evoluzione in funzione di nuovi requisiti e nuove necessità, esplicite o implicite che siano:
Un Architettura è una Buona Architettura se riesce a governare la sua evoluzione e i costi che i cambiamenti comportano. Chiaramente se l’Architettura introduce elementi che semplifichino la realizzazione del sistema, di certo la cosa non dispiace, ma non è indispensabile.
Bisogna poter far evolvere (attenzione: evolvere, non stravolgere) l’Architettura, senza la paura che ciò si trasformi in un’impresa difficile da raggiugere, introducendo più problemi che vantaggi.
Questo aspetto è ben evidenziato da Martin Fowler nel suo Patterns of Enterprise Application Architecture:
“Architecture is a term that lots of people try to define, with little agreement. There are two common elements: One is the highest-level breakdown of a system into its parts; the other, decisions that are hard to change.”
Tale definizione pone l’accento sulla scomposizione del sistema e sugli elementi che ne costituiscono la struttura, principali responsabili dei costi di modifica. Con essa si evidenzia, implicitamente la differenza tra Architettura e Design di un sistema software, abilmente sintetizzata da Grady Booch
“All architecture is design but not all design is architecture. Architecture represents the significant design decisions that shape a system, where significant is measured by cost of change.”
E’ interessante notare che in quest’ultima definizione la questione del “costo del cambiamento” è esplicitata in modo diretto (esattamente come abbiamo evidenziato ed enfatizzato nel precedente post Agile Architecture una scelta possibile), creando uno spartiacque tra Architettura e Design.
L’Architettura infatti è assimilabile al blue print del progetto, ovvero ad una visione d’insieme sufficientemente completa da descriverlo, ma non tanto da dettagliarne i tecnicismi. Tocca al Design entrare nello specifico e descrivere come raggiungere gli obiettivi descritti dall’Architettura. Ecco il punto: l’Architettura è la STRATEGIA che adotto per raggiungere l’obiettivo mentre il Design è la TATTICA (o l’insieme di esse) che mi avvicina all’obiettivo.
Chiaramente la terminologia è preso a prestito dall’ambito militare in cui la tattica indica l'utilizzo di risorse in un ambito territoriale ristretto per limitate esigenze temporali (una singola battaglia con relativi movimenti e utilizzo di determinate tecniche). La strategia è, al contrario, l'impiego e l'organizzazione di risorse in funzione di un obiettivo di medio o lungo periodo.
Strategy vs Tactics
Modificare l’Architettura è più costoso che modificare il Design. Questo è dovuto proprio al fatto che il Design “specializza” l’Architettura, mentre quest’ultima definisce i confini in cui muoversi: si pensi all’utilizzo di un Pattern Architetturale come MVC (Model-View-Controller) e al costo di una sua sostituzione con un modello differente come PAC (Presentation-Abstraction-Controller). Dualmente la sostituzione a livello di Design di due diversi framework MVC è si costosa, ma sicuramente molto meno che nel caso precedente.
Possiamo quindi affermare che [FP]:
“Da un’Architettura possono scaturire più Design, mentre un Design è identificabile da una specifica Architettura”
["From an architecture may arise more Design, while a Design is identified by a specific Architecture".
La differenza tra Architettura e Design non è però così delineata, non essendo semplice individuare il giusto grado di astrazione dell’Architettura. Un utile esercizio è quello di rispondere a tre obiettivi fondamentali che sono alla base della definizione dell’Architettura:
1. “what” (cosa), indica cosa il sistema deve garantire da un punto di vista qualitativo per coprire le esigenze del relativo contesto applicativo;
Quali sono le esigenze qualitative (non – funzionali) del sistema?
2. “why” (perché) indica perché vengono effettuate determinate scelte;
Perché devo garantire determinati livello qualitativi (SLA, Service Level Agreement)?
3. “how” (come) indica come si intende rispondere alle esigenze non funzionali.
Quali sono gli elementi strutturali (moduli, module views and styles) del sistema?
Quali sono i componenti dinamici (componenti e connettori, C&C views and styles) che si sviluppano nel sistema?
Come si relazionano i componenti con l’ambiente di esecuzione (Allocation views and styles)?
Attenzione: non c’è traccia di scelte tecnologiche specifiche, ne Java, ne dotNet e ne altro!
Detto questo, vediamo di analizzare alcune delle definizioni più interessanti esistenti in letteratura, partendo da quella di Shaw e Garlan tratta dal testo Software Architecture: Perspective on Emerging Discipline:
The Architecture of a software system defines that system in terms of computional components and interactions among the component.
Arricchita da un'altra affermazione, sempre degli stessi autori:
In addition to specifying the structure and topology of the system, the Architecture shows the intended correspondence between the system requirements and elements of the constructed system. It can additionally address system-level properties such as capacity, throughput, consistency, and component compatibility.
La prima definizione abbraccia fortemente la relazione dinamica tra i componenti e le loro interazioni, di interesse del Component and Connection Style (C&C Styles), mentre la seconda evidenza gli aspetti relativi all’organizzazione statica (Module Styles) e l’importanza di soddisfare le proprietà non funzionali. Manca invece un riferimento all’allocazione dei componenti nell’ambiente di esecuzione (Allocation Styles).
Una definizione più forte è quella data da Bass-Clements-Kazman in Software Architecture in Practice:
“The software architecture of a program or computing system is the structure or structures of the system, which comprise software components, the externally visible properties of those components, and the relationships among them. By -externally visible properties- we are referring to those assumptions other components can make of a component, such as its provided services, performance characteristics, fault handling, shared resource usage, and so on.”
Questa definizione, probabilmente la più completa, è più ampia, perché oltre a considerare i componenti e le relazioni richiama direttamente le “proprietà visibili dall’esterno” che, ancora una volta, non sono quelle funzionali, bensì quelle qualitative: performance, tolleranza i problemi, condivisione delle risorse, e altri SLA di rilievo. Conoscendo tali caratteristiche è possibile valutare l’efficienza dell’Architettura e la sua efficacia nel contesto in cui si intende utilizzarla, permettendo di definire appositi Hot Spot (punti) di estendibilità.
