Tra le varie sessioni sulle software factories specifiche, software factory in generale, build your own software factory e chi più ne ha più ne metta, anche questo argomento mostra un notevole trend di crescita.
In questo Teched, almeno un paio di sessioni a testa si potevano contare per la Smart Client, la Web Client e la recentissima Web Service Modeling Edition uscita proprio nei giorni della manifestazione.
Ma che cos'è esattamente una Software Factory?
Volendo essere precisi, la definizione di Greenfield autore del libro che introduce l'argomento sarebbe:
"...A software product line that provides a production facility for the product family by configuring extensible tools using a software template based on a software schema..."
che volendola dire tutta significa....boh?!
Infatti (come ho già avuto modo di dire sia negli scorsi Community Days sia ai miei recenti corsi di architettura) credo che il miglior modo di comprendere il significato di una SF è esprimerla in questi termini:
La SF è uno strumento. Anzi è "lo strumento" principe per un architetto per imporre ad un proprio team delle linee guida in uno specifico topic. Ad esempio quello di costruire applicazioni web fortemente modularizzabili con dei pattern specifici sul presentation (Web Client Softare Factory), o costruire dei web services per una architettura SOA evidenziando contratti e messaggi estrapolati dalle business entities (Web Service Software Factory).
Ragionando su un team di tre persone (o una singola applicazione) alcuni presupposti possono sembrare banali, ma ragionando su un team di trenta persone (o trenta applicazioni) niente è mai banale. Neanche scegliere un modo per scrivere un web service.
Se la vostra azienda scala fortemente verso l'alto in termini di numero di persone e/o numero di applicazioni, state passando dal software crafting (lorenzo di diceva così?) ad una vera e propria factory.
Ecco il vero motivo delle SF.
Le SF sono composte da una serie di "asset", ad esempio:
1. Una reference Implementation: Una applicazione funzionante che serve da modello applicabile
2. Una documentazione architetturale: Una documentazione dei pattern usati che serva da guida per i developer
3. Dei Designer eventualmente basati sui DSL Tools di Visual Studio: eventuali designer che possano modellare entity/servizi/quellochevolete.
4. Delle estensioni alla Guidance Automation: wizard applicabili alle GAT/GTX di Visual Studio ed eseguibiili dai developer all'interno dei propri progetti
5. Dei Quickstart: una serie di mini implementazioni con dei focus più granulari rispetto ad una reference implementation
6. Degli Application Block: dei componenti/librerie riutilizzabili, ad esempio quelli di pattern & practices o qualsiasi altro tipo di libreria
E varie ed eventuali.
Buono studio...e chi si ferma è perduto.