Domanda

Nella mia esperienza, un software che è ben allineato con i processi di business sono più facili da cambiare quando il business processi di cambiamento. Che tipo di architettura è più adatto per questo approccio?

È stato utile?

Soluzione

Buona domanda ... Ma prima ... SOA? Questa è una grande parola d'ordine, ma è spesso frainteso, in gran parte a causa della mancanza di una qualsiasi definizione "reale". Diamine! anche Martin Fowler ora si riferisce ad esso come "ServiceOrientedAmbiguity" e incoraggia le persone a evitare di portare in su a tutti.

non è davvero " una " " migliore " risposta. Le esigenze poste IT da parte delle imprese può essere; e di solito sono; abbastanza variato. Queste richieste sono spesso influenzate da fattori esterni quali clienti, partner, le tendenze del mercato, la legislazione, le autorità di regolamentazione, ecc In molti casi questi driver dettano l'architettura, o per lo meno compromesso o limitano la capacità di completamente acheive quello che si sente potrebbe essere una "migliore " architettura. Che può anche glib suono, ma che non è la mia intenzione. L'idea che ci sia una cosa come un "best" architettura porta molti a continuare a sprecare enormi quantità di energia (e denaro) nella sua ricerca. Anche se non può essere intenzionale, queste prospettive sono spesso supportati da persone che sono diventate deleghe per un singolo fornitore / comunità, o state vendendo un processo come un prodotto.

Con tutto quello che ha detto ... dal punto di vista dell'ingegneria del software, i vecchi principi continuano a rimanere il mezzo più affidabile per garantire è possibile soddisfare le esigenze di business. Ad esempio,

  • Separa le vostre preoccupazioni
  • Crea livello la vostra architettura
  • design per ogni esigenza
  • strati di prova in isolamento, e quindi verificare insieme
  • pratiche Impiegare integrazione continua per rendere visibile la regressione prima
  • requisiti marca e le specifiche dei driver principale
  • Investire in attrezzature, investire nel vostro sviluppatori
  • Etc ...

Avviso non si fa menzione di un qualsiasi modello di architettura, la tecnologia, o linguaggio ... è perché queste non sono realmente i piloti, anche se possono essere i fattori abilitanti e cambierà dato una varietà di fattori. Permettetemi di soffermarmi su un punto in più. "processi di business" e dei processi di ingegneria del software hanno molto diverse preoccupazioni, prospettiva, ecc ... Forzare entrambi i gruppi a funzionare lo stesso come l'altro che portare al fallimento totale. Questo non vuol dire che non dovrebbero impegni di condivisione come date, deliverable funzionali, ecc Questi gruppi devono essere diversi per fare il loro lavoro in modo efficace, ma certamente bisogno di trovare il modo di comunicare quelle cose che richiedono una visione condivisa. È qui che un qualsiasi numero di processi di progettazione e di gestione del ciclo di vita può aiutare. (Es. DDD, MSF, SCRUM, CMMI, ecc ...).

volevo dire questo per essere costruttiva ... spero che aiuta.

Altri suggerimenti

Glib risposta: un'architettura enterprise.

Che tipo di risposta stai veramente cercando? Nella mia esperienza, ogni azienda ha esigenze specifiche, soprattutto quando si tratta di indicazioni che vogliono evolvere in. Modificabilità è solo una delle qualità desiderabili, in competizione per le risorse con il controllo dei costi, i tempi di commercializzazione, l'efficienza, la sicurezza, l'usabilità e la resto del branco.

Autorizzato sotto: CC-BY-SA insieme a attribuzione
Non affiliato a StackOverflow
scroll top