2009-11-23 14 views
6

Ho sentito spesso un'architettura orientata al servizio (SOA) lanciata come parola d'ordine tra clienti non tecnici o responsabili di programmi con scarsa attenzione o comprensione per ciò che effettivamente comporta (esempio: "Posso acquistare un SOA? "). C'è anche molta disinformazione su SOA (esempio: "Solo le app web possono usare SOA") e una generale mancanza di comprensione per le sue capacità (esempio: "SOA può far lavorare tutti i tuoi dati insieme").Aiutare manager e clienti a capire SOA

Quali sono alcuni fatti chiave che, come qualcuno che capisce il lato tecnico di SOA, utilizzare per istruire i gestori del programma sull'uso appropriato e la comprensione di SOA? Qual è il modo migliore per impostare il record direttamente con persone non tecniche?

+1

Sto anticipando i commenti di "rendere un wiki della comunità" ... Direi che la risposta migliore (ovvero la più completa/ben pensata) dovrebbe ottenere il maggior numero di voti e essere accettata come risposta –

risposta

4

Per le persone non tecniche vorrei utilizzare il seguente concetto. L'intero mondo professionale è orientato al servizio.

  • Invece di cuocere un biscotto da per conto proprio, vai al fornaio.
  • Invece di cercare di curare te stesso, vai dal medico.
  • Invece di scrivere un programma, è chiedere a un programmatore di farlo per voi.

Questo implica due importanti vantaggi:

  • Ognuno fa il suo lavoro meglio di se tutti noi stavamo cercando di risolvere tutti i nostri compiti separatamente.
  • C'è una via, che consente non professionisti di comunicare con coloro, che risolverà il nostro compito (in mondo reale modo è denaro e contratti commerciali)

Nel mondo del software, l'architettura viene implementata definendo servizi specializzati (applicazioni) che sono dedicati all'esecuzione di compiti specifici e alla definizione di protocolli, che risolvono il problema delle comunicazioni tra tali applicazioni. Quando tale architettura è distribuito, si ottiene alcuni benefici, che possono essere mappati anche al mondo reale:

  • Se medico non è disponibile, non si può essere curata, ma almeno si può ottenere un biscotto dal forno! Nel software questo significa che un servizio fallito non distrugge l'intero sistema.

  • Di solito i medici e i fornai non condividono la stessa stanza e questo consente loro di operare meglio. Proprio come nel software è possibile posizionare ogni servizio sul proprio hardware.

Per il mondo del software questo significa maggiore disponibilità, manutenibilità, riutilizzo e costi ridotti. Buona fortuna!

0

Forse avete alcune applicazioni nella vostra azienda da usare come dimostrazione.

Cerca di mostrare loro il quadro completo con molti servizi vagamente dipendenti con alcune esigenze/caratteristiche comuni create da vari team e estraendo quelle funzioni incorporate ma comunemente utilizzate e utilizzarle come fornitori di servizi.

L'altra cosa che mi è venuta in mente è di mostrare loro i vari connettori che i servizi possono usare per comunicare (forse ci sono alcune vecchie applicazioni legacy con screen-scraping). Inoltre, il concetto di bus messaggi con normalizzazione e gestione delle transazioni deve essere chiarito. Secondo me, le persone non tecniche dovrebbero vedere l'intero concetto SOA come servizi liberamente accoppiati che parlano tra loro con qualsiasi tipo di messaggio, in cui i servizi sono scritti/gestiti/governati da diversi team (così le dichiarazioni di servizio formali e gli SLA possono tornare utili) .

Cercare di evitare di menzionare i fornitori, se possibile. Oppure menziona molti fornitori e tecnologie per ciascuna parte per mostrare loro le varie opzioni.

1

"SOA è come assumere nuovi dipendenti quando il lavoro diventa troppo grande per il team attuale." Ogni parte dell'intero sistema è analoga a un dipendente. I manager capiscono i dipendenti;)