Metodi di integrazione delle applicazioni legacy

Probabilmente ci sono quelli in azienda che vedono troppi sistemi disparati che duplicano gli sforzi e rendono più difficile includere i dati nello stesso report. Il responsabile IT deve concentrarsi sul design e non essere così miope da pensare che chiunque utilizzi la stessa lingua sia la panacea.

Il consolidamento nello stack MS può facilitare la condivisione di sviluppatori e conoscenze. SQL Server è la parte più proibitiva del fare ciò. Esistono altri problemi di licenza per Windows Server e Visual Studio. Se riesci a trovare un ROI per le operazioni commerciali e / oi costi di sviluppo, puoi giustificare l'acquisto.

L'integrazione dei dati non sarà un puro problema tecnico solo perché sei su stack diversi. Potresti farlo attraverso i servizi web.

Con la presentazione, hai bisogno di un design dell'interfaccia utente coerente. Un utente di app Web può essere spostato su una tecnologia diversa quando passa da un'app a un modulo / reparto a un altro senza nemmeno saperlo. Devi decidere cosa ha senso consolidare. Esistono database separati contenenti dati dei dipendenti che vengono aggiornati manualmente per corrispondere? Risorse umane e vendite hanno questo in comune. Un buon test è vedere quanto sia difficile lasciare un dipendente, farsi assumere o cambiare nome a causa del matrimonio.

Dovresti fornire qualche input dal tuo dipartimento, ma qualcuno più in alto nella società deve vedere l'immagine più grande.

Hai almeno due diversi problemi qui che ti stai confondendo.

1. set di strumenti / stack
2. Comunicazione

Per prima cosa, potresti voler o meno voler migrare verso meno tecnologie. Avere uno di tutto sotto il sole può rendere difficile la manutenzione e limita la possibilità di condividere alcune parti delle applicazioni.

La comunicazione tra moduli / applicazioni / sistemi è la seconda parte. Hai menzionato abbonamento dati , hai davvero bisogno di requisiti push-type in tempo reale. Se lo fai, allora dovresti guardare le tecnologie del tipo message-bus come RabbitMQ , ActiveMQhere e altri (ci sono molte domande che riguardano questi su questo e altri siti).

Se invece si desidera semplicemente centralizzare alcuni dati, i servizi web semplici (siano essi SOAP o REST basati) potrebbero essere la soluzione migliore. I team .NET possono facilmente crearli e tutte le altre tecnologie possono semplicemente chiamarli e viceversa. Questa potrebbe essere la tua migliore scommessa a breve termine, che consente alle varie applicazioni con silenziai di comunicare mentre elabori un piano più grande.

Hai letto qualcosa su Enterprise Integration Patterns? C'è un intero libro su questo argomento e una varietà di quadri là fuori per aiutare.

link

Penso che una domanda sia quanto risorsa / budget ottiene il tuo dipartimento. Hai alluso a problemi di budget. Dove lavoro ora (fino a venerdì) il dipartimento non riceve alcuna risorsa e utilizza le tecnologie Microsoft. Questo porta a strumenti davvero scadenti perché nessuno vuole pagare i costi di licenza. Porta a tutti i tipi di cose frustranti come il desktop remoto a un computer con un sovraccarico lento per utilizzare SQL Server Management Studio (perché volevano solo pagare una copia), ecc ... O non avere un ambiente Dev / Test a tutti a causa di non voler spendere soldi per le licenze. Considerando che con PHP / Python / Java basta installare il server e andare. Un altro problema sono le librerie. Python / Ruby / PHP hanno molto più framework disponibili e gratuiti. Microsoft ha appena rilasciato la sua libreria MVC. Persino cose come Java avevano framework MVC per un tempo molto più lungo, e anche cose come Hibernate erano avanti. Inoltre molte delle migliori librerie .NET non sono gratuite all'inizio. So che un precedente datore di lavoro stava pagando una fortuna per i controlli web infragistici. E ogni volta che volevo scrivere excel senza Office Installed, le librerie più utilizzabili non erano gratuite (anche se ora puoi semplicemente usare NPOI). Ma anche al di là del denaro, molti dipartimenti Microsoft non sono disposti ad accettare librerie di terze parti che limitano anche te. Mentre la maggior parte dei negozi PHP / Java / Python / Ruby / Perl che ho visto utilizzano librerie di terze parti sul wazoo ...

Tuttavia, a quanto detto, Visual Studio 2010 sembra avere molte funzionalità e Microsoft sta recuperando alcune librerie (Entity Framework e LINQ da una prospettiva ORM e altro ancora, MS MVC per il framework web, F # per la programmazione funzionale, eccetera..). Purtroppo ci sono ancora molti posti che usano .NET 2003 o .NET 2005 che non hanno la maggior parte di queste funzionalità .... Poi ci sono altri negozi che aggiornano al più recente / più grande ASAP (di solito con un sacco di supporto aziendale PRO MS) . Quindi è difficile da dire. Ma sicuramente LINQ e Entity Framework (e persino nHibernate) sono usciti molto dopo che molte altre lingue avevano ORMS. MS MVC è uscito molto dopo DJango, Struts, Catalyst, ecc .... Quindi saranno indietro in molte delle ultime / più grandi scoperte.

Il problema non è tanto la formazione degli sviluppatori. La maggior parte degli sviluppatori può captare C # in un batter d'occhio se sono stati esposti ad un altro C come linguaggio orientato agli oggetti. Ho messo fuori gioco la mia prima applicazione .NET in meno di una settimana al mio primo Job (era VB.NET ma il tempo non era dedicato all'apprendimento di VB.NET, ma piuttosto al framework .NET, al ciclo di vita delle pagine dei moduli web di asp.net, eccetera..). Il problema è il fattore "divertimento". Molti sviluppatori godono di Python / PHP / Ruby molto più di C # o Java (ben più Python / Ruby di PHP). Alcuni di loro potrebbero semplicemente andarsene. Anche i framework / librerie aggiuntivi dell'altro linguaggio ti rendono più produttivo del semplice C # oltre alla produttività extra di un linguaggio di scripting.