¿Qué consideraciones deben darse a favor y en contra de los sitios "super"?

Mi empresa está considerando consolidar todas sus aplicaciones y sitios de nivel 1 (es decir, producción de alta gama) en una base de código que lo abarque todo.

La teoría es que sus permisos, diseño y funcionalidad general se pueden homogeneizar y administrar de manera centralizada.

No tengo preocupaciones acerca de este enfoque, ya que las estructuras de datos que sustentan cada aplicación son muy diferentes, las reglas de negocios son complejas y únicas para cada aplicación y las bases de código generales para las aplicaciones existentes son extremadamente dispares y muy descuidadas.

EDITAR :

El entorno actual consta de tres sitios ASP.Net 1.1 que apenas han visto un verdadero amor desde la primera vez que se escribieron (debido principalmente a la ausencia de desarrolladores experimentados en la empresa) y una aplicación MVC2 que también era un sitio ASP.Net 1.1 antes de ser escrito. actualizado el año pasado. Escribimos exclusivamente en C #.

La compañía es bastante pequeña, con aproximadamente 50 empleados; tres de los cuales son desarrolladores reales. La administración (incluso la administración de TI) no tiene ninguna experiencia o experiencia en TI que no sea la administración de proyectos de proyectos de TI (y, por lo tanto, algunos conocimientos sobre terminología e impactos comerciales).

Las aplicaciones son principalmente servicios en línea para respaldar los productos vendidos por la empresa. La compañía no vende ningún software directamente.

Por lo tanto, para expresar toda esta situación en una pregunta razonablemente específica y responsable: ¿Cuáles son algunas razones convincentes a favor y en contra de tratar de agrupar todos sus sistemas en una solución global dada las condiciones actuales (es decir, base de código antigua, sistemas y reglas comerciales complejos) )?

Mala idea

Esta reacción se basa en los siguientes supuestos:

1. Se están homogeneizando muchas aplicaciones bastante dispares
2. Hay muchos equipos trabajando en las diferentes aplicaciones.
3. No existe un arquitecto de software respetado y con autoridad que gestione activamente las aplicaciones.

¿Qué pasará si sigues adelante?

Lo más probable es que haya un esfuerzo consolidado inicial para unir todo bajo un único enfoque de diseño. Esto mostrará el enorme esfuerzo requerido para hacer que todo funcione igual y puede quedar enlatado como inviable.

Si se presiona, se requerirá algún tipo de repositorio centralizado que contenga datos de configuración (por ejemplo, acceso de seguridad, niveles de registro, etc.), en ese momento alguien señalará lo obvio y dirá

"Oye, ¿por qué no simplemente adaptamos este enfoque de configuración externo a las aplicaciones antiguas, será mucho más rápido?"

y un momento después alguien más se relacionará con

"Y, dado que estamos refactorizando de todos modos, ¿por qué no solo aplicamos un estándar de diseño para cada uno de los dominios de aplicación?

hasta que finalmente

"Ah, y hay un montón de código común aquí, por qué no reunir algunas bibliotecas fácilmente compartidas. Probablemente necesitemos algún tipo de compilación de integración ejecutada a intervalos regulares, por ejemplo, todas las noches".

En ese momento, todos suspiran aliviados de que no se haya construido un enorme monolito.

Hemos estado trabajando en esto en mi empresa. Creo que es posible y hay beneficios obvios (los mencionó), sin embargo, este será probablemente un proyecto de 5 a 7 años como mínimo absoluto, y requiere básicamente que todo se reescriba. Si puedes obtener la aprobación de algo así, entonces diría que lo hagas. Si no, prepárate para una marcha de pesadilla de la muerte.

Google lo hace, por lo que ciertamente es posible .

Ese enlace, por cierto, es una presentación interesante de un Google sobre cómo manejan su base de código, integración continua, pruebas, etc.

Sin un compromiso igualmente fuerte con las herramientas, sin embargo, como lo ha hecho Google, es probable que te encuentres en un mundo de dolor.

La pregunta clave aquí es ¿por qué ? ¿Por qué la alta gerencia quiere hacer esto? ¿Qué ahorro, apalancamiento u otra ventaja esperan obtener?

Si puede abordar una cantidad suficiente de esos problemas de manera tal que logre sus objetivos, puede evitar la base de código único que le concierne, al mismo tiempo que les brinda el mismo resultado efectivo.

Hemos pasado por un proceso similar. Teníamos un producto que existe desde hace un tiempo. El año pasado presentamos otro producto que es 95% igual al primero, con un 5% de diferencias a veces sutiles pero significativas, con un equipo separado que desarrollará y mantendrá esas diferencias.

Cuando comenzamos a trabajar en el nuevo producto, el antiguo equipo siguió haciendo cambios que nos afectaron negativamente en ese 5%, porque no entendían el nuevo producto. Así que bifurcamos completamente ese 5% del código, lo que nos permitió terminar el primer lanzamiento a tiempo.

Luego, comenzó más trabajo de mantenimiento, y descubrimos que frecuentemente hacíamos cambios casi idénticos en un código casi idéntico. El antiguo equipo también tiene una mejor comprensión del nuevo producto ahora, por lo que estamos reintegrando gradualmente lo que bifurcamos y encontrando formas arquitectónicas más eficientes para expresar las diferencias.

Entonces, cuando dice que las estructuras de datos son diferentes y las bases de código generales son dispares, la pregunta que haría es si tienen que ser así o así es como evolucionaron debido a la conveniencia del momento. Obviamente, debe tener en cuenta las diferentes reglas y requisitos comerciales, pero la clave es aislar esas diferencias en un módulo lo más pequeño posible. Si a menudo se encuentra implementando exactamente la misma característica para varios clientes de maneras ligeramente diferentes para diferentes bases de código, entonces la consolidación realmente puede ayudar, y sospecho que ese es el caso o la administración probablemente no lo propondría.

Lo más probable es que no pueda consolidar numerosas aplicaciones en la misma base de código porque eso requerirá bastante esfuerzo y para los programas viejos y descuidados esto podría ser mucho más trabajo de lo esperado inicialmente.

Dicho esto, no hay nada de malo en tener todas sus aplicaciones en el mismo repositorio de código , donde cada aplicación tiene un área separada. Esto le permite, por ejemplo, tener cualquier documentación en línea generada para toda la base de código en una vista única y consistente, que generalmente es algo bueno, ya que desea la mayor visibilidad posible.

Quienes decidan esto, deben considerar por qué POR QUÉ quieren hacerlo y considerar cuánto trabajo quieren dedicar a lograrlo.

Si hay una sola cosa que hace que el desarrollo empresarial sea tan ineficiente y costoso, es la ilusión de que es posible hacer un sistema único que haga todo. Si tuviera un único propietario de producto que comprenda todos los detalles del sistema y pueda tomar todas las decisiones sin necesidad de una semana de reuniones, podría funcionar, pero nunca he visto que eso suceda.

En general, estará mejor si lo trata más como un desarrollo para Internet: solo cree su propia aplicación, admitiendo que en la práctica no tiene control de nada fuera de su propio código. Puede obtener casi toda la consistencia que probablemente desee con OAuth y una API simple para la configuración del usuario y un poco de CSS compartido.

Esto es bastante similar a la intención original de SOA, pero si lo llamas así, terminarás con un tipo diferente de sistema grande y apenas funcional que intenta hacer todo.

Mi primer pensamiento es que esto sería un PITA total para lanzamientos.

La división en partes manejables de funcionalidad es mucho más sensata, aunque solo sea para evitar todas las capas de administración y aprobación.

Desglosar cosas comunes en componentes / servicios y estandarizar de esa manera sería mucho más fácil en mi humilde opinión.

Puede abordar esto de manera diferente, utilizando una tecnología de integración como Deliverance para tema de todas sus aplicaciones web de manera similar. Básicamente, cada aplicación aún está separada; Deliverance usa reglas XSLT para calzar su salida en una plantilla HTML estática que diseñe. Esto permite aplicar un tema HTML / CSS estático relativamente simple a un conjunto completo de aplicaciones con un mínimo de problemas.