Actualmente existen un número elevado de desarrollos en construcción y planificados que fueron diseñados con anterioridad al nuevo modelo global. Estos desarrollos realizarán una transición progresiva al nuevo enfoque de acuerdo con los criterios de modernización que tendrán en cuenta la relación coste-beneficio de dicha transición, considerando aspectos como la mejora en la seguridad, mejora en la mantenibilidad y la reducción de la obsolescencia tecnológica, entre otros. Para ello se identifican dos arquitecturas de referencia que soporta esta casuística:
La arquitectura monolítica es actualmente la más utilizada en la Junta de Andalucía, representando un porcentaje muy elevado de los sistemas que actualmente se encuentran en producción.
Debido a la diversidad tecnológica existente, no se detallará en este documento una pila tecnológica o conjunto de tecnologías asociadas a esta arquitectura, ya que existirán diversos sabores en función de los sistemas software construidos con esta arquitectura.
Necesidad
Dar una solución de arquitectura para incluir dentro del modelo global de soluciones tecnológicas y de la arquitectura global de contexto las aplicaciones y sistemas ya existentes dentro de la Junta de Andalucía que deben beneficiarse de los aspectos asociados al modelo global (reglas y pautas, activos, ...).
Permitir la construcción y despliegue de aplicaciones y sistemas software en los que los servicios de presentación, backend y datos se encuentran en el mismo empaquetado físico. Usualmente no harán uso del resto de servicios identificados en la arquitectura global de contexto, pues se trata de una arquitectura de transición al nuevo modelo.
Como norma general, se indicará solo para sistemas o aplicaciones existentes en fase de mantenimiento evolutivo, y no presentan problemas de rendimiento, problemas de volumetría, ...
No está recomendada para nuevas aplicaciones o sistemas.
Características principales
- Arquitectura monolítica para el despliegue de aplicaciones “tradicionales”.
- FrontEnd y Backend pueden coexistir en el mismo empaquetado.
- No necesariamente debe existir una división de servicios de backend por funcionalidad.
- Pueden exponerse APIs internas de consumo.
- Pueden consumirse y enviarse eventos a través de un broker de mensajería.
- Pueden consumirse servicios de interoperabilidad para realizar integraciones con otros sistemas de la organización o sistemas de terceros.
Relaciones
- Consumida por:
- Arquitectura de APIs.
- Arquitectura de interoperabilidad.
- Arquitectura de microservicios.
- Arquitectura de funciones.
- Accede a:
- Arquitectura de microservicios.
- Arquitectura de funciones.
- Arquitectura de interoperabilidad.
- Arquitectura de eventos.
- Arquitectura de datos.