Subdirección de las Tecnologías de la Información y Comunicaciones
Área de Gobernanza y Calidad
Cumplimiento Normativo
Cumplimiento Normativo
Las normas expuestas son de obligado cumplimiento. La STIC podrá estudiar los casos excepcionales los cuales serán gestionados a través de los responsables del proyecto correspondiente y autorizados por el Área de Gobernanza de la STIC. Asimismo cualquier aspecto no recogido en estas normas deberá regirse en primera instancia por las guías técnicas correspondientes al esquema nacional de seguridad y esquema nacional de interoperabilidad según correspondencia y en su defecto a los marcos normativos y de desarrollo software establecidos por la Junta de Andalucía, debiendo ser puesto de manifiesto ante la STIC.
La STIC se reserva el derecho a la modificación de la norma sin previo aviso, tras lo cual, notificará del cambio a los actores implicados para su adopción inmediata según la planificación de cada proyecto.
En el caso de que algún actor considere conveniente y/o necesario el incumplimiento de alguna de las normas y/o recomendaciones, deberá aportar previamente la correspondiente justificación fehaciente documentada de la solución alternativa propuesta, así como toda aquella documentación que le sea requerida por la STIC para proceder a su validación técnica.
Contacto Arquitectura: l-arquitectura.stic@juntadeandalucia.es
Histórico de cambios
Los cambios en la normativa vendrán acompañados de un registro de las modificaciones. De este modo se podrá realizar un seguimiento y consultar su evolución, ordenándose de mas recientes a menos recientes.
1. Introducción
El uso de una arquitectura de referencia ofrece un modo de aplicar las mejores prácticas favoreciendo ámbitos como la reutilización, la interoperabilidad, rendimiento, mantenibilidad y seguridad en el diseño de soluciones software. Es por ello que se ha diseñado un modelo de arquitectura tecnológica de referencia para el desarrollo software como marco común para nuevos sistemas de información corporativos en el Servicio Andaluz de Salud, así como nuevos desarrollos sobre los sistemas existentes.
Esta arquitectura de referencia se desarrollará a partir de un conjunto de normas y guías de desarrollo en constante evolución y que seguirán un ciclo de vida iterativo e incremental con actualizaciones periódicas destacando, en el caso de normas, la identificación de pautas de obligado cumplimiento.
2. Ámbito de aplicación
Esta arquitectura de referencia será de aplicación obligatoria(*) en los siguientes casos:
- Desarrollo de nuevos sistemas de información corporativos.
- Refactorización de sistemas de información existentes.
- Evolución de sistemas de información que requieran la implementación de nuevos procesos o funcionalidades y que requiera de desarrollo en funciones "core" del sistema.
Se recomienda su aplicación:
- Sistemas comerciales que permitan una arquitectura tecnológica flexible y alineada con este modelo de referencia.
- Desarrollos locales con previsión de escalar a sistemas corporativos.
- Cualquier desarrollo para implementar nuevos procesos sobre los sistemas de información existentes.
Se recomienda analizar en detalle con la unidad de Arquitectura de la STIC y particularizarla para los siguientes casos:
- Sistemas analíticos o que gestionen grandes volúmenes de datos (**).
(*) Cualquier propuesta que difiera de esta arquitectura deberá ser aprobada por el Área de Gobernanza de la STIC, previa solicitud y justificación en su caso.
(**) En proceso de elaboración de una arquitectura de referencia para sistemas analíticos y big data.
3. Ciclo de vida de la arquitectura de referencia
Los cambios normativos dentro de la arquitectura de referencia seguirán el siguiente ciclo de vida:
- Pre-release: Periodo durante el cual la normativa se hace pública aunque no es necesario adherirse inmediatamente. En este periodo aún puede sufrir pequeñas correcciones.
- Adopción: Periodo durante el cual la normativa inicia un periodo de tiempo flexible para su aplicación de forma obligatoria al ámbito en el cual está destinado.
- Activa: Periodo durante el cual es obligatorio su cumplimiento para el ámbito en el cual está destinado.
- Retiro: Periodo durante el cual dejará de aplicarse en el ámbito al cual está destinado en sustitución de nuevas versiones o normas.
4. Descripción de la Arquitectura Tecnológica de referencia para el desarrollo software.
4.1 Modelo conceptual
La arquitectura de referencia está estructurada en bloques de servicios que agrupa tecnologías de referencia y modelos de implementación concretos que, a modo resumido, se muestran en el siguiente diagrama:
Loading...
Ilustración 1. Organización de la arquitectura tecnológica de referencia para el desarrollo software.
| Bloque de servicios | Descripción |
|---|---|
| Servicios de presentación | Este bloque de servicios aglutina los servicios de interfaz de usuario y su interacción con el sistema. |
| Servicios de entrega | Este bloque contiene los servicios que permiten la entrega de contenidos o mediación de acceso a ellos como pueden ser API Gateway, proxy o service mesh. |
| Servicios de interoperabilidad | Este bloque contiene los servicios de orquestación y coordinación de servicios entre diferentes aplicaciones o productos. Entre estos servicios destaca las capacidades de ESB y paso de mensajes entre aplicaciones. |
| Servicios de backend | Este bloque contiene los servicios que aplican reglas/lógica de negocio e intermedian en el acceso a datos en sus diferentes formas (bases de datos, ficheros, servicios web, etc.). |
| Servicios de persistencia | Este bloque aglutina servicios de almacenamiento persistente de la información, ya sea en sistemas de ficheros, bases de datos, u otros medios duraderos, así como persistencia temporal de la información como sistemas de cache (Memory data-grid). |
| Servicios de construcción y despliegue | Este bloque aglutina servicios de construcción y despliegue de aplicaciones (CI/CD). |
| Servicios de seguridad | Este bloque contiene servicios relativos a la seguridad de las aplicaciones como la autenticación, la autorización o la auditoría. |
| Servicio de observabilidad y trazabilidad | Este bloque contiene todos los servicios para la observabilidad y trazabilidad de la infraestructura y de la aplicación |
Cada uno de estos bloques de servicios tomarán como referencia de implementación las siguientes tecnologías o frameworks. Las versiones indicadas se entenderán como versiones mínimas, admitiéndose actualizaciones superiores.
| Bloque de servicios | Tecnologías o frameworks de referencia | |
|---|---|---|
Servicios Presentación        | Web | Tablet/Móvil |
|
| |
Servicios de Entrega
| ||
Servicio de interoperabilidad
|
* Para mayor detalle consultar la normativa de interoperabilidad | |
Servicios de Backend
| JAVA | .NET |
| ||
Servicios de persistencia
|
| |
Servicios de construcción y despliegue
| CI → Entorno de entrega continua donde se gestiona la construcción, ejecución de test, análisis de calidad y el empaquetado de la aplicación. La herramienta utilizada es Jenkins:2.289.1 Calidad → Herramienta para evaluar la calidad del software Sonarqube:7.9 Despliegue en contenedores → Herramienta para la gestión de configuración y despliegues de la aplicación basada en contenedores Helm:3.x Repositorio de Artefactos → Herramienta donde se almacena y controla el versionado de los artefactos Nexus:3.16.x | |
Servicios de seguridad
| Proveedor de identidad (IdP) compatible con OpenId 2.x. Estándar de Seguridad → JWT Framework de firma para la comunicación segura entre módulos → JOSE | |
Servicios de observabilidad y trazabilidad
| ||
Loading...
Ilustración 2. Organización del stack tecnológico de referencia para el desarrollo software.
Loading...
Ilustración 3. Flujo de entrega del software
4.2 Arquitectura de despliegue para contenedores
Loading...
Ilustración 4. Arquitectura de despliegue para contenedores
4.3 Diagrama lógico
Loading...
Ilustración 5. Arquitectura lógica
5. Desarrollo normativo de la arquitectura de referencia tecnológica para el desarrollo de software
| Normativa | Descripción | Versión Activa | Fecha de activa | Versión Pre-Release | Fecha de Pre-release |
|---|---|---|---|---|---|
Clientes JAXRS - FHIR RESTFULL | Normas y recomendaciones sobre como crear servicios y clientes REST orientados a protocolo. | N/A | N/A | 1.0 |
|
6. Guías de desarrollo
| Normativa | Descripción | Versión Activa | Fecha de activa | Versión Pre-Release | Fecha de Pre-release |
|---|---|---|---|---|---|
| Desarrollo de instaladores en entornos k8s con helm | Esta guía cubre las necesidades de generación de plantillas helm, necesarias para articular las operaciones de instalación de las soluciones basadas en contenedores. | 1.0 |
| - | - |
| Directrices de implementación enfocadas en la calidad. | Está guía proporciona una serie de pautas para el diseño y el desarrollo que facilitan la mantenibilidad, la legibilidad y el cambio del código. | 1.0 |
| ||
| Implementación para arquitecturas limpias | Esta guía pretende impulsar los diseños de las aplicaciones que están basadas en Arquitecturas Limpias y Domain Centric que permitirán un diseño orientado al negocio y un desarrollo que facilite el cambio. | 1.0 |
|
Vista general
Herramientas de contenido
- Impreso por Atlassian Confluence 8.7.2