Formas de integrar aplicaciones heredadas

7

Mi empresa ha crecido rápidamente en los últimos años en varios territorios. No somos una empresa de software per se, sino una técnica que ha desarrollado varias aplicaciones a medida. Algunos de estos se venden ahora como SAAS.

Soy personalmente responsable de 3 de estas aplicaciones: todas las aplicaciones web internas, una escrita en MySQL / Python / Django, una escrita en SQL Server / Python / Django y una en MySQL / PHP / Symfony. Mi recurso para desarrolladores incluye experiencia en todo esto, así como algunos Java y Adobe Flex. Ninguno de nosotros tiene experiencia significativa en tecnologías de Microsoft más allá de SQL Server.

Sin embargo, todos los demás departamentos de mi empresa que tienen desarrolladores trabajan con la pila de Microsoft, todas nuestras otras aplicaciones web son C # / asp.NET, etc., etc.

Se me ha pedido que evalúe la integración de nuestros productos de depts con otros miembros de la compañía a nivel de presentación de datos y presentación.

Veo 3 rutas posibles:

  1. Mordimos la bala y nos movemos a la pila de desarrollo de Microsoft, y esto se convierte en una política para toda la compañía. Pros: la estandarización, la capacidad de agrupar recursos, la integración se puede hacer en cualquier nivel. Contras: los costos de licencia masivos que realmente no podemos pagar en este momento, se requiere una capacitación completa de todos los desarrolladores, tener que usar IIS en lugar de servidores agradables de Ubuntu / Apache y oposición filosófica general (en su mayoría somos evangelistas de código abierto en mi departamento) .

  2. Middleware. Hemos estado buscando en Adobe Flex para manejar las suscripciones de datos entre servicios. Ventajas: la solución relativamente barata, la experiencia interna existente, puede utilizar cualquier tecnología subyacente que elijamos. Contras: me tomó mucho tiempo obtener una cotización para los servicios de datos de Adobe, no tengo claro qué tan a prueba de futuro es esta ruta: ¿estamos potencialmente comprando una tecnología que se está extinguiendo?

  3. DIY. Mantenemos el código abierto en todo momento y las API de servicios web de escritura personalizada entre todas las aplicaciones. Pros: barato en licencias, de código abierto. Contras: tiempo adicional requerido, más pruebas, problema central de la proliferación de tecnología no abordado

Me interesaría saber qué otros enfoques podría haber aquí. ¿Hay otras maneras de Middleware de hacer esto? ¿Estoy totalmente fuera de lugar con mis puntos de vista? ¿Qué es una apuesta segura para el futuro?

Gracias

    
pregunta meepmeep 13.10.2011 - 14:24

4 respuestas

5

Probablemente hay personas en la compañía que ven demasiados sistemas dispares que están duplicando esfuerzos y haciendo que sea más difícil incluir datos en el mismo informe. El jefe de TI debe centrarse en el diseño y no ser tan miope como para pensar que todos los que usan el mismo lenguaje es la panacea.

La consolidación en la pila de MS puede facilitar el intercambio de conocimientos y desarrolladores. SQL Server es la parte más prohibitiva de hacer esto. Hay otros problemas de licencia para Windows Server y Visual Studio. Si puede encontrar un ROI para las operaciones comerciales y / o los costos de desarrollo, puede justificar la compra.

La integración de datos no va a ser un problema técnico, simplemente porque estás en diferentes pilas. Podrías hacerlo a través de servicios web.

Con la presentación, necesitas un diseño de interfaz de usuario consistente. Un usuario de una aplicación web puede ser movido a una tecnología diferente cuando pasa de una aplicación de módulo / departamento a otra sin siquiera saberlo. Necesitas decidir qué sentido tiene consolidar. ¿Hay bases de datos separadas que contienen datos de empleados que se actualizan manualmente para que coincidan? RR.HH. y Ventas tienen esto en común. Una buena prueba es ver qué tan difícil es tener un empleado que se va, que lo contraten o que cambie su nombre debido al matrimonio.

Debería proporcionar información de su departamento, pero alguien más alto en la empresa necesita ver el panorama general.

    
respondido por el JeffO 13.10.2011 - 15:12
4

Aquí tiene al menos dos problemas diferentes que está combinando en uno.

  1. Conjunto de herramientas / pila
  2. Comunicación

Para la primera, puede o no desear migrar hacia menos tecnologías. Tener uno de todo bajo el sol puede dificultar el mantenimiento y limita su capacidad para compartir ciertas partes de sus aplicaciones.

La comunicación entre módulos / aplicaciones / sistemas es la segunda parte. Menciona suscripción de datos , ¿realmente tiene requisitos de tipo push en tiempo real? Si lo hace, entonces debería mirar tecnologías de tipo de bus de mensajes como RabbitMQ , ActiveMQhere y otros (hay muchas preguntas que cubren esto en este y otros sitios).

Si, por otro lado, simplemente desea centralizar algunos datos, los servicios web simples (ya sean SOAP o basados en REST) pueden ser su mejor opción. Los equipos .NET pueden crearlos fácilmente, y todas sus otras tecnologías pueden simplemente llamarlos, y viceversa. Esta podría ser su mejor apuesta a corto plazo, permitiendo que las diversas aplicaciones aisladas se comuniquen mientras usted elabora un plan más grande.

    
respondido por el sdg 13.10.2011 - 14:54
4

¿Has leído algo sobre los patrones de integración empresarial? Hay un libro completo sobre este tema y una variedad de marcos para ayudar.

enlace

    
respondido por el Steven S 13.10.2011 - 17:35
2

Creo que una pregunta es la cantidad de recursos / presupuesto que obtiene su departamento. Usted aludió a cuestiones de presupuesto. Donde trabajo ahora (hasta el viernes), el departamento no obtiene ningún recurso y usan las tecnologías de Microsoft. Esto lleva a herramientas realmente pobres porque nadie quiere pagar los costos de licencia. Lleva a todo tipo de cosas frustrantes, como el escritorio remoto a una computadora con una sobrecarga lenta para usar SQL Server Management Studio (porque solo querían pagar por una copia), etc ... O no tener un entorno Dev / Test en absoluto Por no querer gastar dinero en licencias. Mientras que con PHP / Python / Java solo instala el servidor y listo. Otro tema son las bibliotecas. Python / Ruby / PHP tiene muchos más frameworks web disponibles y gratuitos. Microsoft acaba de lanzar su biblioteca MVC. Incluso cosas como Java tenían frameworks MVC por mucho más tiempo, y cosas como Hibernate también estaban por delante. Además, muchas de las mejores bibliotecas .NET no son gratuitas al principio. Sé que un empleador anterior estaba pagando una fortuna por los controles web de infragística. Y cuando quería escribir Excel sin Office Installed, las bibliotecas más utilizables no eran gratuitas (aunque ahora solo puedes usar NPOI). Pero incluso más allá del dinero, muchos departamentos de Microsoft no están dispuestos a aceptar bibliotecas de terceros, lo que también lo limita a usted. Mientras que la mayoría de las tiendas PHP / Java / Python / Ruby / Perl que he visto están usando bibliotecas de terceros hasta el wazoo ...

Pero dicho esto, parece que Visual Studio 2010 tiene muchas características y Microsoft se ha puesto al día con algunas bibliotecas (Entity Framework y LINQ desde una perspectiva de ORM y más, MS MVC para el marco web, F # para la programación funcional, etc ..). Desafortunadamente, todavía hay muchos lugares que utilizan .NET 2003 o .NET 2005 que no tienen la mayoría de estas características ... Luego, hay otras tiendas que se actualizan a la última / mejor ASAP (generalmente con un montón de soporte corporativo de PRO MS) . Así que es difícil de decir. Pero, definitivamente, LINQ y Entity Framework (e incluso nHibernate) salieron bien después de que la mayoría de los otros lenguajes tuvieran ORMS. MS MVC salió mucho después de DJango, Struts, Catalyst, etc ... Así que se quedarán atrás en muchos de los descubrimientos más recientes y más importantes.

El problema no es tanto la capacitación del desarrollador. La mayoría de los desarrolladores pueden detectar C # en un abrir y cerrar de ojos si han estado expuestos a otro C como lenguaje orientado a objetos. Descarté mi primera aplicación .NET en menos de una semana en mi primer trabajo (era VB.NET pero el tiempo no se usaba en aprender VB.NET sino en el marco .NET, ciclo de vida de la página de los formularios web de asp.net). etc ..). El problema es el factor "divertido". Muchos desarrolladores disfrutan de Python / PHP / Ruby mucho más que C # o Java (bueno, más Python / Ruby que PHP). Algunos de ellos pueden irse. Además, los marcos / bibliotecas adicionales del otro idioma lo hacen más productivo que C # directo más allá de la productividad adicional de un lenguaje de scripting.

    
respondido por el Cervo 13.10.2011 - 17:17

Lea otras preguntas en las etiquetas