Metodologia progettuale per lo sviluppo di sistemi interoperabili?

Puoi seguire il metodo di Jeff Bezos come descritto qui link

Il suo grande mandato è andato su questa linea:

1) Tutti i team esporranno i loro dati e funzionalità attraverso le interfacce di servizio.

2) I team devono comunicare tra loro attraverso queste interfacce.

3) Non ci sarà altra forma di comunicazione tra processi consentita: nessun collegamento diretto, nessuna lettura diretta dell'archivio dati di un'altra squadra, nessun modello di memoria condivisa, nessuna back-door. L'unica comunicazione consentita è tramite chiamate all'interfaccia di servizio attraverso la rete.

4) Non importa quale tecnologia usano. HTTP, Corba, Pubsub, protocolli personalizzati - non importa. A Bezos non interessa.

5) Tutte le interfacce di servizio, senza eccezioni, devono essere progettate da zero per essere esternalizzate. Vale a dire, il team deve pianificare e progettare per poter esporre l'interfaccia agli sviluppatori nel mondo esterno. Nessuna eccezione.

6) Chiunque non lo faccia verrà licenziato.

7) Grazie; buona giornata!

Suggerirei di progettare una suite di programmi di esempio che interagiscono con il tuo sistema. Usa le piattaforme che più probabilmente saranno utilizzate per interagire con te, ad esempio una suite .NET, una suite Java, una suite PHP ... considerando quali versioni potrebbero essere in uso (ad esempio se fornisci una suite Java 5+ ... sei sicuro che non ci siano persone bloccate in 1.4 nella tua zona?).

Gestisci queste suite, usale come suite di test (puoi utilizzarle per verificare la presenza di modifiche), forniscile liberamente a chiunque voglia interagire con il tuo sistema.

Se mi dai un vaso con classi che incapsulano la comunicazione con il tuo sistema e esempi di utilizzo, sarò felice. Inoltre, se qualcuno ha un problema, avrai meno problemi come "eh, stiamo usando XFire per il sapone, non l'asse ...".

E soprattutto, comunica!

we've seen more of a shift towards gathering "intelligence" across all systems within our customers requirements.

Hai chiaramente bisogno di un sistema di BI \ Data Warehouse (Business Intelligence). La costruzione di uno implica fondamentalmente la creazione di un nuovo archivio dati centrale, in cui tutti i sistemi spingono (o hanno tirato) i dati su tali sistemi su base regolare. Questi dati sono tutti sposati insieme in qualche modo, quindi ottimizzati per il recupero dei dati e l'amp; velocità di reporting.

Poiché sei un negozio .Net, ti consiglierò di dare un'occhiata a SSAS & SSRS (servizi di analisi SQL Server e servizi di reporting di SQL Server.)

Link obbligatorio: link

Is there a particular methodology or programming practice for designing systems to maximise

their ability to interface to other systems?

Non c'è davvero alcuna correlazione tra metodologia e design. Non ho mai sentito parlare di una particolare metodologia che pretende di funzionare meglio per particolari schemi di programmazione, design o tecnologie.

La mia esperienza con questo è molto piccola, ma credo che potresti esaminare SOA ( architettura orientata ai servizi ) . Il suo obiettivo è esattamente quello che vuoi: componenti software interoperabili.

Non confondere i servizi SOA con i servizi .NET tipici (asmx, wcf). La comunicazione tra 2 servizi SOA può passare attraverso asmx o wcf, ma può anche usare Messaging (MSMQ, ...) per esempio.

Suggerirei di usare qualcosa di gratuito come Buffer del protocollo . È disponibile per tutte le principali lingue, viene fornito con i generatori ed è ragionevolmente veloce. Ed è dimostrato sul campo.

Da quello che sembra, la forza di WCF sta nella sua capacità di consumare una grande varietà di formati. Tuttavia, in una prospettiva a lungo termine, il tuo interesse dovrebbe essere quello di dare forma ai fornitori per l'interoperabilità, non i tuoi consumatori.