un progetto da uno, ovvero il presunto software architect inizia a tirare linee

Ho iniziato con un Activity Diagram. Per la prima volta ho provato a farlo con Enterprise Architect della Sparx e devo dire che mi ha fatto un ottima impressione, valuterò di comprarlo.
Il diagramma non ha la pretesa di essere ne esaustivo ne completamente corretto. Ci potrebbero essere errori formali (es. errori sintattici rispetto ad UML 2.0) oppure errori applicativi (es. il diagramma non aderente al flusso di lavorazione che hanno scelto di seguire). Non importa, per il momento mi serviva qualcosa di appena un po' più articolato della solita "carta da formaggio" in modo da poter fare un po' di brainstorming con colleghi e "committenti"

( ...dando anche solo di sfuggita al diagramma è facile accorgersi che i leggendari XY non sono altro che piccoli applicativi software... sì è così, sono piccoli moduli C, molto cablati e molto specifici)

un progetto da zero, ovvero l'autocoscienza del software architect

Immaginiamo che un azienda che produce oggetti XY, uno diverso dall'altro, a un certo punto dica, "cavoli questi XY stanno diventando tanti, c'è un sacco di gente che ci lavora sopra: io voglio monitorare lo stato di avanzamento di ogni XY e sapere quando è pronto per essere consegnato"
Beh, niente di male: si vuole gestire il flusso di lavoro su ogni XY
Visto che ciascun XY è diverso dall'altro, ciascuno prevederà una fase di analisi, una fase di implementazione, una di test, una di documentazione, etc. etc. fino al rilascio vero e proprio: ad ognuna di queste fasi lavoreranno persone diverse ed alcune fasi potranno essere in parallelo (es. posso iniziare a scrivere la documentazione di un XY anche se il test non è finito)
Cosa significherà implementare il sistema di gestione del flusso di lavoro degli XY?
Prima di tutto sentire i diretti interessati e definire la sequenza di passi che devono essere svolti, e poi capire quali form, report, azioni automatiche, notifiche etc. etc. deve gestire il sistema.
Lasciamo ai signori dell'ISO la documentazione delle procedure ed occupiamoci del software di gestione.

Immaginiamo ora che non ci siano grossi vincoli di deploy o tecnologici: possiamo scegliere ambiente di sviluppo, framework web, workflow engine e perfino il S.O.
Come ci muoviamo? Da dove partiamo?
Un bell'Activity Diagram UML oppure iniziamo da agilisti duri e puri? Andiamo di Django o ci sogniamo di usare J2EE? Valutiamo di utilizzare un workflow engine? Etc. etc.

Ammesso che abbia tempo di scriverli (e non è detto) questo post dovrebbe essere il primo di una serie orientata ad incrementare la consapevolezza software-architetturale :-)
Sono in discussione i metodi, gli strumenti e lo stesso modo di lavorare... oddio, mettere in discussione proprio tutto-tutto è un tantino irrealistico però quante volte ci siamo detti che sarebbe stato bello poterlo fare... :-)
Non credo che questi post saranno granché sistematici, però diciamo che qualche appunto spero di scriverlo :-) Commenti sarebbe grandemente graditi, anzi auspicati, anzi attesi... insomma... fatevi sotto :-D