Come si avvia una discussione sull'architettura del software?

Question

Lavoro per un'organizzazione che è praticamente una start-up all'interno di una grande azienda. Il team ha diversi ingegneri di database e alcuni ingegneri del software (nel campo di data mining). Stiamo crescendo a un ritmo veloce, il che pone l'esigenza di avere una strategia di architettura globale o una roadmap tecnologica (o bussola) per i prossimi anni. Come ingegnere del software, mi è stato assegnato l'incarico di iniziare le riunioni bimestrali per condurre quella discussione. Quindi, la mia domanda è, come si avvia il tuo ruolo di architetto? come si avvia una discussione sull'architettura in tutta l'organizzazione? Ho iniziato a leggere il libro "97 cose che ogni architetto del software dovrebbe sapere", ma mi piacerebbe sentire di più dalle vostre esperienze. Quindi, come architetto, come hai iniziato?

Con i migliori saluti,

Answer 1

1. Scopri chi è sulla vostra squadra
2. Scopri quali sono interessati a a livello di analisi dei sistemi
3. scoprire chi sa che la gente nella società più ampia
4. scoprire cosa c'è in uso nella società più ampia
5. scoprire cosa la gente hanno usato prima nella vostra divisione particolare
6. prendere tutte le informazioni di cui sopra e di u per iniziare a parlare di Now, Soon e Eventually. Presta particolare attenzione a come ti connetti con il mondo esterno sia in termini di fuori divisione che al di fuori della società.

Non iniziare a parlare di architettura finché non sai cosa stai iniziando. Non iniziare una discussione sull'architettura fino a che anche gli altri non lo facciano.

Answer 2

non ho avuto personalmente questa esperienza, ma ecco alcuni suggerimenti:

• ottenere una formazione, e ottenere la gente che saranno in queste discussioni addestrati nel soggetto. Avrai un tempo più significativo.
• Avere una bozza iniziale da migliorare in base alle idee di altre persone. È molto più semplice iniziare da una bozza che iniziare da zero
• Chiedere a qualcuno di collaborare strettamente con te su questo (analogo alla programmazione della coppia). Due menti che lavorano per un'ora di solito forniscono un risultato migliore di una mente che lavora per un'ora quando si tratta di attività intensamente intelectually.

Answer 3

Questo è meno per esperienza e più dal pensiero pratico. Prima di tutto è difficile definire l'architettura del software: un ottimo riferimento per l'avvio è sempre 'design patterns explained' in quanto ciò richiede un approccio non software alla comprensione dell'architettura.

cominciare a guardare a questioni fondamentali specifici di architettura come

• Comunanza e la variabilità
• separazione degli interessi
• aggregazione oltre astrazione

L'architettura non è sulla rimozione di complessità piuttosto si tratta di gestirlo. Così inizia attraverso la comprensione dei temi che compongono la complessità nel contesto del progetto

Answer 4

Concentrati sui requisiti non funzionali e da lì prova a scegliere un modello architettonico. Un'analisi della qualità del software sarà utile. Vorrei quindi abbellire il modello e descriverlo al team, in base ai livelli di granularità a cui sono interessati.

Answer 5

La tua domanda è difficile perché tocca molte aree: processo, leadership e progettazione del software (o architettura). Presumo che tu abbia già un processo standard, ma se non lo fai, prova uno dei processi Agile. Parlerò di leadership e architettura del software.

Leadership. L'ottimo libro di Fred Brooks, The Mythical Man-Month, parla di avere un capo tecnico nel modo in cui un team chirurgico ha un leader. Personalmente, mi piace più collaborazione di quella che vedo con i medici, quindi consideriamo il team chirurgico di Brooks un estremo. Tuttavia, hai bisogno di qualcuno per coordinare tecnicamente chi sta facendo cosa, cose come allocare le persone a lavorare in diverse parti del sistema, decidere quali sono le parti più difficili (più rischiose) (in modo che non vengano rimandate finché non sono costose cambiare/correggere) e fare delle scelte quando il team non è d'accordo. Questo tipo di leadership tecnica è necessaria sia che tu stia costruendo software, macchine o pogo stick.

Architettura/Design. Il mantra standard è che "Ogni sistema ha un'architettura", ma il corollario è che non tutte le architetture vengono scelte deliberatamente. Puoi copiare implicitamente l'architettura dal tuo ultimo progetto, ad esempio un sistema a 3 livelli. Oppure può essere pre-deciso una volta che sai che stai usando un framework come EJB. All'inizio di un progetto, prenderai decisioni architettoniche e alcuni saranno difficili da cambiare in seguito. Come manterrai i dati? Userai un framework (es. Spring, EJB, RoR)? Elaborerai i dati in modo incrementale o in batch?

Praticamente qualsiasi architettura può essere costretta a soddisfare le vostre esigenze. Ad esempio, è possibile utilizzare RoR per creare un termostato. Ma avrai un tempo più semplice quando la tua architettura si adatta bene ai requisiti. A volte hai dei requisiti, come la bassa latenza dell'interfaccia utente, che può essere aiutata da una scelta di architettura saggia, come l'utilizzo di AJAX. Quindi l'inizio del tuo progetto è un'opportunità per pensare a queste cose e farle bene. (E questo non significa che tu salga sulla montagna, pensi intensamente, poi datti le tue risposte alla squadra - anche qui di nuovo io preferisco la collaborazione).

Non aver paura di pensare all'architettura in anticipo, soprattutto sui modi in cui può aiutarti a evitare le difficoltà, ma non cercare di decidere tutto in anticipo. Avrai dei problemi se una parte del tuo team ha iniziato a utilizzare Ruby on Rails mentre un'altra parte ha iniziato a utilizzare EJB, quindi prendi alcune decisioni tecniche, quelle che sono obbligate a te e quelle che faranno fronte ai tuoi maggiori rischi.

Un'ultima cosa: le prime discussioni sull'architettura sono una benedizione e una maledizione. Sono una benedizione in quanto ottengono le idee in anticipo e consentono di scegliere il scegliendo il piuttosto che fare un errore. Ma sono una maledizione in quanto tutti avranno opinioni, e può essere difficile farli puntare tutti nella stessa direzione (cioè tornare alla necessità di una leadership tecnica).

Raccomando il capitolo 12 di Applied Software Architecture per indicazioni sulla domanda. L'elenco dei titoli dà una buona idea del suo consiglio: creare una visione, l'architetto come consulente tecnico chiave, l'architetto prende le decisioni, gli architetti, le coordinate dell'architetto, gli strumenti dell'architetto, i sostenitori dell'architetto. Il libro 97 Things che menzioni è più una collezione di perle di saggezza piuttosto che una guida coesa all'architettura.

George Fairbanks, autore di Just Enough Software Architecture