Guía de modernización de aplicaciones Oracle Forms/Reports

Propósito y alcance

Esta guía establece el criterio corporativo para modernizar aplicaciones existentes en Oracle Forms en la Junta de Andalucía, evitando decisiones caso a caso y asegurando un enfoque homogéneo entre organismos, equipos y proveedores.

Se integra en el proceso de modernización promovido por la Agencia Digital de Andalucía. A partir del inventario y la clasificación estratégica TIME, la guía facilita seleccionar la acción 7R y el escenario tecnológico más adecuado. El resultado debe estar alineado con las arquitecturas de referencia, la Arquitectura Global de Contexto y las estrategias globales aplicables (Administración Digital, Portales, Backoffice o modernización técnica generalista).

La modernización de Oracle Forms suele presentar dos riesgos recurrentes: actualización mínima para aplicar correcciones de versión nueva (y perpetuar dependencia y deuda técnica) o plantear transformaciones y modernizaciones desde cero sin un criterio común.

Esta guía define cuándo aplica cada alternativa (actualización de Forms, reconstrucción en APEX, re-arquitectura, sustitución o retirada) y qué implica cada una en alcance, esfuerzo y gobierno.

Está dirigida a:

• Direcciones y jefaturas de proyecto, para tomar decisiones trazables, justificar inversiones, priorizar y planificar por oleadas.
• Responsables técnicos, arquitectura y equipos de desarrollo, para disponer de escenarios destino claros, pasos de ejecución y controles mínimos de calidad, seguridad y operación.

Alcance y criterios de aplicación

Esta guía es aplicable en la toma de decisiones y a la estrategia de modernización sobre una aplicación o sistema desarrollado en su mayoría en Oracle Forms y, además, ejecutarla con control (plazos, riesgos, calidad, seguridad y operación).

No pretende ser un manual de producto ni un recetario técnico de Oracle Forms, sino un marco común para que directores de proyecto y equipos técnicos puedan adoptar una decisión consistente, repetible y alineada con el modelo corporativo.

En esta guía, una aplicación Oracle Forms es aquella cuya interfaz principal (o una parte relevante del uso diario) está construida sobre Oracle Forms, incluyendo los componentes típicos asociados: formularios, librerías, menús, automatismos, lógica embebida y su despliegue habitual en entorno Oracle.

También entran dentro del perímetro los componentes que habitualmente acompañan a Forms y condicionan la decisión: la base de datos Oracle y su lógica PL/SQL, las dependencias con otros sistemas, los mecanismos de autenticación y autorización, y las integraciones que realiza la aplicación.

Dentro del perímetro de una aplicación Oracle Forms se incluyen explícitamente los informes y documentos generados mediante Oracle Reports (u otros motores de reporting asociados al entorno Forms). En muchas aplicaciones, Oracle Reports es el mecanismo por el cual se producen documentos con validez administrativa, listados operativos, exportaciones de datos e informes de gestión.

En resumen y detallando un caso práctico: si los usuarios acceden a la aplicación a través de Forms y ahí está concentrada parte de la lógica de negocio o del proceso, esta guía es de aplicación.

NOTA : Existe otro documento para establecer la política de uso de Oracle APEX dentro de la Junta de Andalucía, del cual se hablará en esta guía al ser una de las opciones recomendadas:

• Esta guía trata sobre Oracle APEX como posibilidad táctica de modernización para aplicaciones ya existentes a modernizar, si están construida con Oracle Forms.

Concretamente, se corresponde con el apartado de uso permitido para modernización de aplicaciones existentes construidas en Oracle Forms.

• Para cualquier otro escenario, debes revisar el contenido de la política anteriormente citada.

Esta guía de modernización no afecta a aplicaciones nuevas. Para este caso, por favor consulta la política de uso de Oracle APEX.

Cómo usar esta guía

Esta guía es una herramienta práctica, no un documento teórico. Siguiendo la secuencia de tres pasos que se describe a continuación, la decisión de modernización queda respaldada por evidencias y la ejecución se gobierna con entregables claros y puntos de control.

Paso 1: Diagnóstico inicial

Antes de elegir tecnología, hay que conocer la aplicación. El primer paso es reunir un diagnóstico inicial centrado en cuatro elementos:

• Valor y criticidad: a quién da servicio, impacto si falla, ciclos de cierre o campañas, volumen de usuarios y dependencia organizativa.
• Estado técnico: versión de Oracle Forms, nivel de deuda técnica, acoplamientos, complejidad del código y calidad de la documentación.
• Dependencias e integraciones: sistemas con los que intercambia información, forma de integración (directa a BD, ficheros, servicios), y riesgos de continuidad.
• Evolución prevista: si se espera crecimiento funcional, cambios normativos, nuevas integraciones o exigencias de experiencia de usuario.

Con este diagnóstico se confirma la clasificación TIME de la aplicación (Tolerar, Invertir, Migrar o Eliminar). Sin esta clasificación, no se avanza a la selección de escenario.

Nota: En los casos en que la clasificación TIME formal dependa de un proceso o un equipo externo cuya respuesta no sea inmediata, el equipo de proyecto podrá establecer una clasificación TIME provisional basada en el diagnóstico inicial disponible, documentando los supuestos y las evidencias que la sustentan. Esta clasificación provisional permite avanzar con el paso 2 (selección de escenario) sin bloquear el proyecto, pero deberá ser validada formalmente antes de iniciar la fase de construcción. Si la clasificación definitiva difiere de la provisional, deberá revisarse el escenario seleccionado.

Esfuerzo orientativo del diagnóstico inicial

El esfuerzo depende del tamaño y documentación disponible de la aplicación. Como referencia*:

• Aplicación pequeña (menos de 150 formularios, reports y/o procedimientos almacenados, documentación aceptable): entre 3 y 5 jornadas de trabajo.
• Aplicación mediana (hasta 900 formularios, reports y/o procedimientos almacenados, documentación parcial): entre 2 y 3 semanas.
• Aplicación grande o crítica (hasta 1800 formularios, reports y/o procedimientos almacenados, documentación escasa o inexistente): entre 3 y 4 semanas, pudiendo requerir apoyo de la Oficina de Arquitectura y del facilitador de inventariado automático cuando esté disponible.
• Grandes sistemas, sistemas críticos o sistemas corporativos (más de 1800 formularios, reports y/o procedimientos almacenados: entre 4 y 6 semanas, pudiendo requerir apoyo de la Oficina de Arquitectura y del facilitador de inventariado automático cuando esté disponible.

(*) Se ha considerado unir el número de formularios, reports y procedimientos almacenados en la aplicación para tener una base de código comparable para poder asociarla al tallaje de la aplicación.

Estos rangos incluyen el levantamiento de información, la validación con responsables funcionales y técnicos, y la elaboración de la ficha de aplicación. Si el diagnóstico supera las 8 semanas, probablemente la aplicación es demasiado grande para tratarla como una unidad y conviene descomponerla en módulos o áreas funcionales antes de decidir.

Consulta el apartado INVENTARIO Y DIAGNÓSTICO DE UNA APLICACIÓN ORACLE FORMS para obtener más información.

Paso 2: Elegir escenario aplicable

Con la clasificación TIME confirmada y el diagnóstico inicial realizado, debe seleccionarse el escenario de modernización adecuado. La lógica completa del árbol de decisión, los criterios de selección y la interpretación de TIME y 7R aplicadas a Oracle Forms se desarrollan en la sección "Marco de decisión".

El resultado de este paso debe quedar cerrado en una decisión breve y trazable: TIME + acción 7R + escenario seleccionado, acompañada de dos o tres argumentos verificables y, sobre todo, de límites claros: por qué aplica y por qué no aplican las alternativas descartadas.

Prueba de concepto para escenarios con incertidumbre alta

Cuando el diagnóstico no permita cerrar con confianza la elección entre dos escenarios de construcción (habitualmente S2 vs. S3, pero también otras combinaciones que impliquen desarrollo), o cuando el equipo no tenga experiencia previa con la tecnología destino se recomienda realizar una prueba de concepto acotada antes de comprometer el plan completo. Esta prueba debe:

• Seleccionar un módulo representativo de complejidad media (ni el más sencillo ni el más complejo).
• Implementarlo en la tecnología candidata con las directrices de esta guía (separación de capas, APIs, seguridad, observabilidad).
• Medir esfuerzo real, dificultades encontradas y calidad del resultado.
• Durar entre 2 y 4 semanas, con un equipo reducido.

El resultado de la prueba de concepto se incorpora como evidencia al plan de modernización y puede confirmar o modificar el escenario seleccionado.

Consulta el apartado Marco de decisión para obtener más información.

Paso 3: Ejecutar con gobierno (entregables y controles)

La ejecución se estructura con entregables mínimos y puntos de control diseñados para evitar las desviaciones más habituales: cambios de alcance no gobernados, soluciones híbridas sin criterio, o carencias de seguridad y operación que aparecen tarde.

Como criterio general:

• Si el cambio es acotado (por ejemplo, continuidad controlada), el foco está en reducir riesgo y asegurar operación.
• Si hay reconstrucción o re-arquitectura, el foco está en planificar por oleadas, definir contratos (APIs/eventos), y asegurar desde el inicio ciberseguridad, observabilidad y automatización de despliegue.

El resultado es tangible: un plan de modernización (con o sin oleadas), una arquitectura objetivo acorde al escenario y las evidencias necesarias para pasar a producción con garantías.

Consulta los apartados CALIDAD, SEGURIDAD Y OPERACIÓN y MIGRACIÓN Y PUESTA EN PRODUCCIÓN para obtener más información.

Alineamiento corporativo

Esta sección describe cómo encaja la modernización de Oracle Forms en el modelo corporativo de la Junta de Andalucía: estrategias globales, principios de arquitectura y capacidades que cualquier solución modernizada debe cumplir.

Modernizar Oracle Forms no es un ejercicio aislado de actualizar pantallas de Forms a otra tecnología más actual. Para que la inversión sea sostenible y gobernable, la propuesta debe encajar en el enfoque corporativo de modernización, en las estrategias globales vigentes y en el modelo de Arquitectura Global de Contexto, utilizando las arquitecturas de referencia publicadas como patrón común entre organismos, equipos y proveedores.

Enfoque de modernización (TIME + 7R)

El marco corporativo de modernización se articula en dos planos: TIME (estratégico: Tolerar, Invertir, Migrar, Eliminar) y 7R (táctico: la acción de modernización concreta). Esta guía adopta ambos como estructura de decisión obligatoria. La interpretación detallada de TIME y 7R aplicada a Oracle Forms se desarrolla en la sección "Marco de decisión", que es la referencia canónica para la toma de decisiones.

Encaje con estrategias globales de modernización

Además del enfoque TIME/7R, la modernización debe alinearse con una estrategia global de modernización. Estas estrategias agrupan aplicaciones por su función principal dentro de la organización para aplicar enfoques comunes, reutilizar activos y asegurar consistencia. La guía contempla cuatro estrategias globales:

EGM-AD — Administración Digital. Aplica cuando la aplicación implementa o participa en la tramitación administrativa o en funciones directamente asociadas a ella: registro, firma electrónica, notificación, gestión de expedientes, archivo o interoperabilidad con otras administraciones. La modernización en esta estrategia se orienta a reutilizar plataformas corporativas y a desmontar o sustituir progresivamente lo que esté duplicado.

EGM-PO — Portales. Aplica cuando la aplicación es un frontal dirigido a ciudadanos o un portal institucional. El foco está en accesibilidad, experiencia de usuario, coherencia de diseño y adopción del ecosistema corporativo de presentación. Por sus características, no debería nunca ocurrir en aplicaciones Oracle Forms.

EGM-BO — Backoffice. Aplica cuando la aplicación es de gestión interna orientada al empleado público: tramitación de procesos internos, gestión de recursos, expedientes no vinculados a tramitación administrativa, reporting operativo o herramientas de trabajo diario.

El objetivo es la modularización, la integración por APIs, la automatización de procesos y la reducción de duplicidades funcionales. Suele derivar en refactorización o re-arquitectura hacia servicios, o bien la utilización de activos de la Junta de Andalucía que puedan cubrir las necesidades existentes en algunos sistemas o módulos funcionales del sistema.

EGM-GE — Generalista. Aplica cuando la aplicación es transversal o heredada y no encaja claramente en ninguna de las tres anteriores. Suelen ser herramientas técnicas, utilidades de soporte, sistemas de integración o aplicaciones cuyo propósito original se ha desdibujado con el tiempo. El foco es resolver obsolescencia y acoplamientos, alineando la solución con las arquitecturas de referencia.

Principios de arquitectura y capacidades transversales

La Arquitectura Global de Contexto establece un modelo por capas y capacidades transversales que esta guía adopta como criterio de obligado cumplimiento cuando la modernización va más allá de la continuidad técnica:

• Separación por capas: la presentación debe consumir servicios mediante APIs gobernadas; la capa de APIs actúa como punto unificado de publicación, aplicando políticas de seguridad, acceso y observabilidad; los servicios backend implementan dominios con responsabilidad única; y las integraciones externas o heterogéneas se canalizan mediante servicios de interoperabilidad.
• API-First y contratos: las APIs se diseñan primero y se especifican con OpenAPI (v3 o superior). La guía asume un modelo de publicación gobernada (API Gateway/Management) y contempla patrones como BFF cuando se necesiten APIs adaptadas por canal.
• Servicios desacoplados y evolución: para aplicaciones estratégicas, el destino recomendado es la arquitectura de microservicios (servicios independientes, desplegables de forma autónoma, preferentemente en contenedores), combinando comunicación síncrona (APIs) y asíncrona (eventos) cuando sea necesario para reducir acoplamiento.
• Arquitectura orientada a eventos (EDA): cuando el proceso requiera desacoplo, reactividad o integración flexible, se promueve el uso de eventos y mensajería como mecanismo transversal entre capas, evitando dependencias rígidas entre sistemas.
• Seguridad desde el diseño: la modernización debe incorporar controles consistentes de identidad y acceso, protección de comunicaciones, gestión segura de secretos y trazabilidad, alineados con el cumplimiento normativo (ENS y RGPD).
• Observabilidad por defecto: no se considera acabado un sistema que no proporcione métricas, logs y trazas útiles para operación, diagnóstico y mejora continua. La instrumentación debe planificarse desde el inicio, no como tarea posterior.
• DevSecOps como condición de entrega: la guía exige que la ejecución se apoye en automatización (build, pruebas, análisis de calidad/seguridad y despliegue), con evidencias objetivas para gobernar el paso a producción.

Este alineamiento corporativo es el que permite que, independientemente del escenario elegido (reconstrucción a APEX, re-arquitectura, sustitución o continuidad controlada), el resultado sea coherente, gobernable y mantenible dentro del modelo tecnológico de la Junta de Andalucía.

Las especificaciones técnicas de cada principio (estándares, patrones, herramientas y configuraciones) se detallan en los Anexos II, III y IV.

Inventario y diagnóstico de una aplicación Oracle Forms

Esta sección define qué información debe reunirse sobre la aplicación antes de tomar cualquier decisión de modernización: inventario de componentes, diagnóstico técnico, análisis funcional y clasificación previa.

Antes de decidir un escenario de modernización hay que conocer el perímetro real de la aplicación. Sin este conocimiento, el riesgo es elegir una estrategia incorrecta, sufrir desviaciones por alcance no analizado o encontrar nuevas dependencias técnicas que nadie había identificado.

Checklist de inventario

El inventario debe poder resumirse en una ficha de aplicación y, si aplica, un anexo técnico que recoja como mínimo:

A. Identificación y contexto

• Datos básicos: Nombre de la aplicación, organismo responsable, propietario funcional y responsable técnico.
• Datos de negocio: Propósito, procesos que soporta y colectivos de usuarios (internos/externos).
• Datos de operación: Criticidad operativa (horarios, campañas, cierres, impacto ante caída).
• Datos técnicos: Ver siguientes puntos (B, C, D, E).

B. Activos Oracle Forms

• Número de módulos/forms, menús, librerías y componentes reutilizados.
• Número de reports.
• Inventario de pantallas y transacciones clave (el top 10-20 que concentran el uso real).
• Dependencias internas (módulos compartidos, librerías comunes, versiones).

B. Activos Oracle Reports

• Número de informes (ficheros RDF), versiones y estado de mantenimiento.
• Clasificación funcional de cada informe según su uso:
  • Documentos con validez administrativa: resoluciones, notificaciones, certificados, diligencias, actas. Suelen tener formato regulado, requisitos de firma y obligación de archivo.
  • Listados operativos: relaciones de entidades, listados de datos y agrupaciones, extractos de datos para trabajo diario. Suelen consultarse en pantalla o imprimirse.
  • Informes de gestión y reporting: cuadros de mando, estadísticas, informes periódicos para dirección.
  • Exportaciones de datos: generación de ficheros (Excel, CSV, PDF) para intercambio con otros sistemas o para trabajo fuera de la aplicación.
• Punto del proceso en el que se invoca cada informe (qué pantalla, qué acción del usuario, qué proceso batch lo dispara).
• Dependencias técnicas: tablas y vistas que consulta, parámetros que recibe, paquetes PL/SQL que invoca, formatos de salida (PDF, HTML, Excel, impresora).
• Complejidad del informe: informes simples (listado tabular), informes con agrupaciones y subtotales, informes matriciales, informes con sub-informes, informes con gráficos o imágenes dinámicas.
• Volumen y frecuencia: informes que se generan miles de veces al día vs. informes mensuales; informes individuales vs. generación masiva (lotes de notificaciones, por ejemplo).
• Requisitos especiales: marca de agua, firma electrónica, código de verificación, numeración oficial, formato específico obligatorio por normativa, ...

C. Datos y lógica

• Esquemas Oracle implicados, tablas principales y volúmenes aproximados.
• Ubicación de la lógica de negocio: triggers, librerías Forms, PL/SQL (packages, procedures, jobs).
• Dependencias de base de datos: DB links, sinónimos, vistas críticas, colas, etc.
• Identificación de operaciones transaccionales y compensaciones.

D. Integraciones

• Sistemas con los que intercambia información y cómo lo hace (BD directa, ficheros, servicios, mensajería).
• Contratos existentes (si hay APIs, especificaciones, formatos, SLAs).
• Flujos críticos y puntos de fallo (qué se rompe y a quién afecta).

E. Operación y mantenimiento

• Entornos (DEV/INT/PRE/PRO), topología, versiones, y forma de despliegue.
• Incidencias frecuentes, rendimiento, ventanas de mantenimiento, monitorización disponible.
• Proveedor/contrato de soporte, costes recurrentes y nivel de dependencia del proveedor.

Si alguno de estos elementos no está disponible, el equipo de proyecto debe realizar un análisis inicial que permita completar el inventario mínimo antes de avanzar.

Diagnóstico técnico

El diagnóstico técnico busca identificar riesgo, complejidad y dependencias que condicionan el escenario, revisándose principalmente los siguientes puntos:

• Obsolescencia y soporte: versiones, compatibilidad, dependencias de cliente, restricciones de infraestructura, dependencias/librerías de las que no se dispone código fuente.
• Acoplamiento a la base de datos: acceso directo desde Forms, lógica crítica en PL/SQL sin separación por capas.
• Complejidad y mantenibilidad: tamaño del código, duplicidades, reutilización real, patrones de código obsoleto en triggers/librerías.
• Integraciones frágiles: intercambio por ficheros sin control, accesos directos a esquemas de terceros, dependencias no documentadas.
• Calidad de entrega: ausencia de automatización (build/despliegue), inexistencia de pruebas repetibles, entornos difíciles de reproducir.
• Capacidades transversales: trazabilidad, auditoría, gestión de errores, y nivel real de observabilidad (qué se puede diagnosticar hoy y qué no).

Señales típicas de riesgo alto (se distinguen de las características habituales de cualquier aplicación Forms, que por sí solas no constituyen riesgo diferencial):

• Lógica de negocio crítica dispersa en triggers de Forms y en triggers de base de datos simultáneamente, sin una capa de paquetes que unifique las reglas (la dependencia de PL/SQL por sí sola no es señal de riesgo si está modularizada en paquetes).
• Integraciones directas a tablas de esquemas de otros sistemas (no confundir con el acceso a tablas propias, que es normal en Forms).
• Ausencia total de documentación funcional y técnica combinada con rotación del equipo original (la falta de documentación sola es frecuente; el riesgo real es que nadie vivo conozca el sistema).
• Despliegues manuales sin posibilidad de reproducción ni reversión en un tiempo controlado.
• Componentes cuyo código fuente no está disponible (librerías FMB/PLL de terceros, OLBs sin fuente).
• Informes Oracle Reports que generan documentos con validez administrativa o listados o documentos críticos y complejos de generar.
• Generación masiva de documentos (lotes de cientos o miles de informes) integrada en procesos batch nocturnos. El motor de reporting destino debe soportar este volumen sin degradar los tiempos del proceso.

Diagnóstico funcional y de negocio (valor, estabilidad y evolución)

La modernización debe responder al negocio, no solo a la tecnología. Por ello, el diagnóstico debe incluir:

• Uso real: transacciones más frecuentes, número de usuarios, picos, estacionalidad.
• Problemas actuales: tiempos, errores recurrentes, formación compleja, usabilidad, dependencia de perfiles muy especializados.
• Evolución prevista: cambios normativos, nuevos canales, necesidad de integración con plataformas corporativas o con terceros.
• SLA y continuidad: tolerancia a cortes, ventanas aceptables, requisitos de disponibilidad.
• Riesgo de cambio: impacto organizativo, dependencias de procedimientos y capacitación necesaria.

Con esto se determina si estamos ante una aplicación estable (candidata a continuidad controlada o reconstrucción sencilla) o ante una aplicación que puede exigir re-arquitectura y un plan por oleadas.

Clasificación y priorización

Con el inventario y el diagnóstico completados, el equipo elabora una pre-selección que sirve como entrada para la siguiente fase:

• Clasificación TIME confirmada (Tolerar / Invertir / Migrar / Eliminar).
• Priorización por una regla simple y transparente: valor + urgencia (riesgo/obsolescencia) + esfuerzo.
• Agrupación por oleadas cuando haya dependencias (por módulos, por procesos o por dominios funcionales).
• Recomendación preliminar: escenario probable y principales condicionantes (por ejemplo: “APEX viable si se estabilizan integraciones” o “re-arquitectura necesaria por evolución e integraciones críticas”).

El objetivo es fijar una base común para decidir: qué se moderniza primero, con qué enfoque y asumiendo qué riesgos.

Marco de decisión

Esta sección contiene la lógica de decisión completa: cómo aplicar la clasificación TIME a una aplicación Oracle Forms, qué acción 7R corresponde a cada situación, los cinco escenarios de modernización disponibles y el árbol de decisión para seleccionar el adecuado.

La decisión de modernización no debe basarse en preferencias tecnológicas ni en experiencias con aplicaciones similares. El enfoque corporativo busca lo contrario: convertir la clasificación estratégica (TIME) en una acción ejecutable (7R) dentro de un escenario de modernización coherente con las estrategias globales y las arquitecturas de referencia.

Proceso de modernización

Dos ideas traccionan este apartado:

• Esta evaluación no es solo técnica ni funcional; es una decisión estratégica y arquitectónica, con impacto en sostenibilidad, costes y capacidad de evolución.
• Se priorizan opciones que transformen el modelo actual, estén alineadas con patrones/estándares corporativos y aprovechen activos y facilitadores reutilizables.

Nota: Durante el proceso de modernización de una aplicación Oracle Forms, la oficina de arquitectura estará disponible para apoyar al equipo de proyecto o a la iniciativa si se le hace participe en este proceso. Además, dispone actualmente de ciertos facilitadores que pueden ayudar a algunas etapas, y otros en los que se está trabajando para automatizar parte del proceso de modernización.

TIME aplicado a aplicaciones Oracle Forms

La clasificación TIME se asigna a la aplicación con independencia de su tecnología. Lo que se evalúa es su impacto y su valor para la organización, no si está construida en Forms o en cualquier otra plataforma.

Que una aplicación esté construida en Oracle Forms no dice nada sobre su valor: puede ser crítica para la organización y merecer una inversión importante, o puede tener un uso residual porque otros sistemas ya cubren su función.

TIME permite fijar el marco antes de debatir tecnologías:

• Tolerar: la aplicación sigue siendo útil, pero no se moderniza activamente.
  En Oracle Forms suele implicar mantener con actuaciones mínimas y controladas (correcciones, continuidad operativa), aceptando limitaciones y riesgos, y evitando inversiones estructurales.
• Invertir: la aplicación es estratégica o importante y merece inversión para asegurar su futuro.
  En Oracle Forms suele conducir a escenarios de reconstrucción o re-arquitectura, porque el objetivo ya no es aguantar, sino ganar mantenibilidad, integración estándar y capacidad de evolución.

Nota: A efectos de esta guía, se considera aplicación estratégica aquella que cumple al menos dos de los siguientes criterios:

(a) da soporte a un proceso crítico para el organismo cuya interrupción tiene impacto directo en el servicio al ciudadano o en obligaciones legales;

(b) tiene más de 100 usuarios activos o da servicio a múltiples unidades organizativas;

(c) requiere integración activa con tres o más sistemas;

(d) se prevén cambios funcionales o normativos relevantes en los próximos 24 meses;

(e) es pieza clave en una cadena de valor que involucra a otros organismos o administraciones.

• Migrar: la aplicación es valiosa, pero debe moverse a un modelo/plataforma objetivo por obsolescencia o restricciones del entorno.
  En Oracle Forms suele traducirse en salir del modelo cliente-servidor hacia un destino web y desacoplado (APEX o arquitecturas de referencia), o en actuaciones puente estrictamente justificadas si hay condicionantes de calendario.
• Eliminar: la aplicación no aporta valor suficiente, está duplicada o existe alternativa corporativa.
  En Oracle Forms el foco es retirar con orden (archivo, trazabilidad, transición funcional si aplica) y sin generar sistemas obsoletos sin uso claro.

El enfoque TIME responde a preguntas estratégicas orientadas a evaluar la necesidad de disponer de esa aplicación, con qué ambición y qué decisión estratégica se adopta. La tecnología destino se decide después, y esta estrategia seleccionada será un dato de entrada importante.

La guía exige que toda decisión se cierre con una fórmula concreta: TIME + 7R + escenario. Sin esta concreción, la decisión queda abierta a interpretaciones.

Estrategias globales de modernización aplicadas a Oracle Forms

Cómo identificar la estrategia global de una aplicación

La clasificación se basa en la función principal que cumple la aplicación, no en su tecnología ni en el organismo al que pertenece. Las siguientes preguntas permiten identificarla:

¿La aplicación participa en tramitación administrativa o en funciones core de Administración Digital? Si la aplicación gestiona expedientes administrativos dirigidos al ciudadano, o realiza funciones de registro, firma, notificación, archivo o interoperabilidad con otras administraciones, la estrategia es Administración Digital. La clave es que el proceso tiene efectos administrativos hacia el exterior de la organización.

Si la respuesta es no:

¿La aplicación es un frontal dirigido a ciudadanos o un portal institucional? Si la aplicación publica información, servicios o trámites accesibles desde internet para ciudadanos, empresas o entidades externas, o bien renderiza algún formulario o utilidad que sea destinatario la ciudadanía, entonces la estrategia es Portales.

Si la respuesta es no:

¿La aplicación es de gestión interna orientada al empleado público? Si la aplicación da soporte a procesos internos del organismo (gestión de personal, control presupuestario, expedientes internos, inventarios, herramientas de trabajo diario, reporting operativo), la estrategia es Backoffice. La clave es que los usuarios principales son empleados públicos y el proceso no tiene efectos administrativos directos hacia el ciudadano.

Si la respuesta es no, o si la aplicación no encaja claramente en ninguna de las anteriores:

Estrategia Generalista. Se recomienda consultar con la Oficina de Arquitectura antes de tomar la decisión, ya que la clasificación correcta puede requerir un análisis más detallado del propósito y el contexto de la aplicación.

Casos frecuentes de duda

Aplicación que tramita expedientes internos (no administrativos). Por ejemplo, un sistema de gestión de incidencias internas o de control de inventario. Aunque gestiona "expedientes", no son expedientes administrativos con efectos hacia el ciudadano. La estrategia es Backoffice, no Administración Digital.

Aplicación que tiene un frontal para de administración digital para ciudadanos con tramitación y un backoffice para empleados. Si ambas partes son relevantes, puede tratarse como dos componentes con estrategias distintas: Administración digital para el frontal y tramitación y Backoffice para el backoffice. En este caso, cada componente puede seguir un escenario de modernización diferente.

Aplicación que además genera reporting interno. La función principal de la aplicación determina la estrategia: Administración Digital, Portales, Backoffice. El reporting es un componente separado que se resuelve dentro de esa estrategia, no debe ser una razón para en otro apartado, y ese módulo de reporting se podrá implementar con un escenario complementario al de la aplicación principal.

Según el análisis del inventario de aplicaciones existentes, la mayoría de las aplicaciones construidas en Oracle Forms se clasifican dentro de las estrategias de Administración Digital y Backoffice.

7R aplicado a Oracle Forms

Con la clasificación TIME definida, se asigna a la aplicación (o a cada uno de sus módulos, si procede) una acción táctica de modernización.

Las acciones 7R ayudan a traducir TIME a una decisión operativa. En Oracle Forms, su interpretación debe ser clara:

Retire (retirar):

Retirar con garantías (archivo, migración mínima de datos si procede, cierre de integraciones).

• Aplica cuando: funcionalidad duplicada, bajo valor, alternativa disponible, coste/riesgo injustificable.
• No aplica cuando: es crítica y no existe sustitución real (en ese caso, transición controlada).

Ver Escenario S0: Retirar o archivar

Retain (mantener):

Se mantiene la aplicación Oracle Forms tal cual, con mantenimiento mínimo y aceptación explícita de riesgos. Útil cuando TIME=Tolerar, pero debe ser una decisión consciente, no por inercia.

• Aplica cuando: urgencia por obsolescencia, mínima intervención, poca evolución prevista, necesidad de ganar tiempo.
• No aplica cuando: se requieren una integración moderna, multicanalidad o una evolución frecuente.

Ver Escenario S1: Continuidad controlada

Rehost (mover sin cambios):

“Lift & shift” de infraestructura. En Forms suele aportar poco valor si no se acompaña de un plan de evolución; se justifica solo por necesidades operativas o de entorno.

Replatform (mejorar estructura sin cambiar funcionalidad):

Por ejemplo, actualizar Forms (p. ej. a Forms 14) o ajustar su plataforma de ejecución como medida de continuidad. Es una opción puente, no un destino estratégico.

Refactor / Rebuild:

En Oracle Forms suele implicar reducir acoplamiento, extraer lógica, ordenar dependencias y preparar el terreno (por ejemplo, encapsular reglas en servicios o contratos). Puede ser paso previo a una re-arquitectura.

En este caso concreto, se incluye la opción de Rebuild como caso específico para la reconstrucción funcional en APEX para disponer de una solución web con alta productividad, especialmente adecuada para aplicaciones de gestión interna orientadas a datos.

• Aplica cuando: aplicación de gestión interna y centrada en el dato, con procesos relativamente estables, necesidad de velocidad de entrega y encaje razonable en ecosistema Oracle*.

(*) El organismo dispone de licenciamiento Oracle Database vigente, el equipo tiene competencias en PL/SQL y/o APEX (o existe plan de capacitación viable), la infraestructura Oracle está operativa y soportada, y la complejidad de experiencia de usuario es moderada (formularios, consultas, listados, reporting; no requiere interacciones complejas de arrastrar y soltar, editores gráficos o comportamiento de aplicación de escritorio).

• No aplica cuando: UX compleja, desacople fuerte por dominios, alta exigencia de independencia tecnológica o escalado por equipos.

Ver Escenario S2: Reconstrucción APEX

Rearchitect (rediseñar arquitectura):

Abandonar el modelo Forms como núcleo y evolucionar a una solución desacoplada (frontend moderno + APIs + servicios), alineada con arquitecturas de referencia.

• Aplica cuando: aplicación estratégica, alto ritmo de cambio, integraciones relevantes, necesidad de desacoplo (APIs/eventos), y objetivo de sostenibilidad a largo plazo.
• No aplica cuando: no hay viabilidad de inversión/plazos (en ese caso, se define transición por oleadas o medida puente).

Ver Escenario S3: Destino a arquitecturas de referencia

Repurchase/Relocate (sustituir):

Reemplazar por solución corporativa o estándar (cuando existe una plataforma que cubre el proceso con ventaja).

• Aplica cuando: existe plataforma/solución que cubre el proceso con ventaja clara (coste, riesgo, cumplimiento, evolución).
• No aplica cuando: el diferencial funcional es alto o la adaptación convertiría el producto en un desarrollo a medida encubierto.

Ver Escenario S4: Sustitución por activo corporativo

Estrategia transversal: Modernización por oleadas (Patrón estrangulamiento - Strangler)

Cuando se opta por reconstruir o re-arquitecturar una aplicación, es habitual que el cambio no pueda hacerse de una sola vez. En estos casos, la modernización se ejecuta por oleadas: en cada oleada se migra una parte acotada de la funcionalidad al sistema nuevo mientras el resto sigue operando en Forms, hasta completar la transición."

• Aplica cuando: el sistema es grande/crítico, hay que mantener servicio y se requiere convivencia temporal.
• No aplica cuando: el perímetro es pequeño y el cambio completo es abordable sin riesgo.

Este marco permite que la decisión sea simple, trazable y ejecutable, y sobre todo consistente entre proyectos: no depende de quién evalúa la aplicación, sino de criterios comunes y verificables.

Árbol de decisión

La decisión del escenario de modernización aplicable para una aplicación Oracle Forms debe realizarse siguiendo una secuencia simple:

1. Validar entrada: identificar y poseer un inventario mínimo completo y tener una clasificación TIME confirmada por responsables técnicos y funcionales.
   Si faltan datos o documentación, no se decide a alto nivel: primero debe completarse la información.
2. Identificar la estrategia global que aplica: Administración Digital / Portales / Backoffice / generalista.
   Esto evita modernizar a medida algo que debería integrarse o sustituirse por plataforma corporativa, sobre todo en los casos de Administración Digital.

En este caso, para la estrategia global de Administración Digital y Backoffice, es muy probable que pueda aplicarse una sustitución de todo o parte del sistema original Oracle Forms. La parte que no pueda sustituirse será evaluada de forma independiente, pudiendo tenerse para el sistema completo Sustitución + Rearquitectura, por ejemplo.

3. Seleccionar escenario del catálogo que encaja con: tecnología origen (Forms), arquitectura actual, riesgos, y destino corporativo recomendado.
4. Asignar 7R y confirmar alineamiento:
   coherencia con arquitecturas de referencia, soluciones tecnológicas disponibles y restricciones (ciclo de vida, ventanas de cambio, contratos, etc.).
5. Documentar la decisión y el plan: opción elegida, alternativas descartadas, y si aplica, plan por oleadas con dependencias, riesgos y controles.

Relación entre estrategia global y escenarios de modernización

La estrategia global no determina automáticamente el escenario, pero lo condiciona. La siguiente tabla muestra qué escenarios son habituales, posibles o no recomendados para cada estrategia global:

(1) En Administración Digital, la modernización suele requerir integración con plataformas corporativas (registro, firma, notificación) y desacoplamiento por servicios, lo que encaja mejor con S3 o S4 que con S2. APEX puede considerarse solo si el alcance funcional muy específico, no está cubierto por las soluciones corporativas y las integraciones se resuelven completamente mediante APIs.

(2) En Portales, la experiencia de usuario, la accesibilidad y la coherencia con el ecosistema corporativo de presentación suelen requerir un frontend desacoplado, lo que hace que S3 sea la opción natural. APEX no está diseñado para frontales ciudadanos.

Cómo usar esta tabla:

La tabla no sustituye al árbol de decisión, sino que lo complementa. Su función es doble:

Primero, como filtro previo: si la intersección entre la estrategia global y un escenario dice "No recomendado", ese escenario necesita una justificación sólida para ser seleccionado. Si dice "No habitual", el equipo debe verificar que las condiciones de su caso concreto lo justifican.

Segundo, como orientación: si la intersección dice "Habitual", el escenario es el camino más frecuente para esa estrategia y probablemente el más alineado con los activos y patrones corporativos disponibles.

Después de consultar esta tabla, se recorre el árbol de decisión con las preguntas rápidas para confirmar el escenario concreto.

Resumen de escenarios de modernización:

La modernización por oleadas puede combinarse con S2, S3 o S4 cuando la aplicación es grande o crítica y no admite un cambio completo de una sola vez.

Como reglas rápidas para Oracle Forms, el árbol suele resolverse con estas preguntas:

• ¿Se puede retirar o sustituir por plataforma corporativa? → Retire / Sustitución por activo corporativo
• ¿Necesito continuidad inmediata y el sistema no va a evolucionar? → Replatform (Oracle Forms actualizado como puente)
• ¿Es backoffice de gestión interna, orientado a datos, y prima la rapidez? → Rebuild a APEX
• ¿Es estratégico, con evolución e integraciones relevantes? → Rearchitect (arquitecturas de referencia)
• ¿Dispone el organismo/proyecto de capacidad real (equipo, competencias, presupuesto y plazo) para ejecutar el escenario seleccionado? Si la respuesta es no, debe aplicarse la regla de prevalencia nº 3 descrita a continuación y documentar explícitamente la brecha y el plan para resolverla.

Regla de prevalencia cuando varios escenarios compiten

Es frecuente que una aplicación encaje parcialmente en más de un escenario (por ejemplo, es backoffice orientado a datos, pero también tiene integraciones relevantes). En ese caso, deben aplicarse las siguientes reglas de prevalencia:

1. Regla nº1: Si la aplicación cumple los criterios de aplicación estratégica (ver definición en el apartado 6.1), prevalece Rearchitect sobre Rebuild (APEX), salvo que se demuestre que las integraciones pueden resolverse mediante APIs sin afectar al modelo APEX.
2. Regla nº2: Si existe plataforma corporativa o activo que cubre el proceso con ventaja demostrable, prevalece S4 Sustitución sobre cualquier otro escenario de construcción.
3. Regla nº3: Si no hay capacidad real de ejecución para el escenario técnicamente óptimo (presupuesto, competencias del equipo, plazos), debe documentarse la brecha y plantear una de estas alternativas:
   1. S1 como puente con fecha objetivo para el escenario definitivo;
   2. un plan de capacitación y adquisición de recursos que permita abordar el escenario óptimo en un plazo definido;
   3. una combinación por oleadas donde los módulos más sencillos se abordan primero con el escenario viable y los complejos se aplazan con criterio explícito.
4. Regla nº4: Si la aplicación tiene módulos que encajan en escenarios distintos (por ejemplo, módulos CRUD puros candidatos a S2 y módulos con integraciones complejas candidatos a S3), debe plantearse una modernización por oleadas con escenarios mixtos, documentando el escenario asignado a cada módulo o dominio y la estrategia de convivencia entre ambos destinos.

Calidad, seguridad y operación

Esta sección establece los requisitos mínimos que debe cumplir cualquier solución modernizada antes de entrar en producción: requisitos no funcionales, controles de seguridad, capacidad de diagnóstico y operación, y automatización de pruebas y despliegue.

El riesgo de una modernización no está solo en construir la solución nueva, sino en ponerla en producción y operarla con garantías. Esta sección define lo mínimo exigible: requisitos no funcionales claros, seguridad integrada desde el diseño y capacidad de diagnóstico suficiente para operar el servicio sin depender de actuaciones reactivas.

Requisitos no funcionales mínimos

Antes de desarrollar la solución modernizada, los requisitos no funcionales deben estar acordados explícitamente. Cuando aparecen tarde, suelen introducir sobrecostes y retrasos:

• Disponibilidad y continuidad: ventanas de servicio, tolerancia a caída, RTO/RPO cuando aplique, necesidades de operación en periodos críticos.
• Rendimiento: tiempos de respuesta objetivo en operaciones clave, concurrencia esperada, volúmenes, picos y estacionalidad.
• Escalabilidad: si el crecimiento se resuelve con escalado vertical, horizontal o segmentación funcional.
• Trazabilidad y auditoría: qué operaciones deben quedar registradas, con qué nivel de detalle y retención.
• Mantenibilidad: estándares de código, documentación mínima, facilidad para desplegar y revertir.
• Compatibilidad y usabilidad: requisitos de canal, accesibilidad cuando corresponda y consistencia de experiencia de usuario.
• Interoperabilidad: condiciones de integración (contratos, formatos, versionado, SLAs).

Cada requisito debe traducirse en un criterio de aceptación medible. Lo que no se puede medir, no se puede gobernar.

Controles de seguridad por defecto

La ciberseguridad no puede tratarse como una revisión final, debe estar integrada inicialmente dentro del plan de modernización. La guía fija controles por defecto que deben estar presentes en cualquier escenario que implique cambios significativos (APEX, re-arquitectura, sustitución, e incluso continuidad controlada cuando afecte a plataforma):

• Identidad y acceso: autenticación y autorización coherentes con el modelo corporativo; control de privilegios por rol; segregación de funciones cuando aplique.
• Protección de comunicaciones: cifrado en tránsito, gestión correcta de certificados y configuración segura de endpoints.
• Gestión de secretos: prohibido el uso de credenciales en código o en ficheros sin control; uso de mecanismos corporativos de custodia y rotación.
• Seguridad en APIs: control de acceso, limitación, validación de entrada/salida, y políticas comunes de seguridad aplicadas en el punto de publicación.
• Bastionado de plataforma: configuración segura de los entornos de ejecución (servidores, contenedores u otros componentes de infraestructura), eliminando servicios, puertos y funcionalidades innecesarias para reducir los puntos vulnerables ante posibles ataques."
• Registro y auditoría de seguridad: trazas suficientes para investigar incidentes, con retención y acceso controlado.
• Seguridad en el ciclo de vida: análisis estático, análisis de dependencias, control de vulnerabilidades y evidencias en la cadena CI/CD.

Un riesgo frecuente en Oracle Forms es arrastrar prácticas inseguras al sistema nuevo: accesos directos, credenciales compartidas, trazas insuficientes. La modernización debe corregir estas debilidades, no trasladarlas.

Observabilidad mínima (logs, métricas, trazas, tableros y alertas)

Operar un sistema de forma eficiente requiere poder diagnosticar qué ocurre en cualquier momento, no solo saber si está encendido. Como mínimo, la solución modernizada debe proporcionar:

• Registros de actividad por operación y por flujo de trabajo, que permitan seguir el recorrido de una operación de principio a fin, con niveles de detalle adecuados y sin exponer información sensible.
• Indicadores de rendimiento que midan los tiempos de respuesta, la proporción de errores y el volumen de operaciones, tanto a nivel técnico como a nivel de negocio (por ejemplo, expedientes tramitados, resoluciones generadas).
• Seguimiento de flujos completos que permita identificar en qué punto de la cadena se produce una degradación o un fallo, especialmente cuando la operación involucra a varios servicios."
• Cuadros de mando y alertas para la operación diaria, con umbrales acordados que disparen avisos cuando algo requiera intervención, evitando alertas que no lleven a ninguna acción.

La guía considera la observabilidad como criterio indispensable para el despliegue en producción. Si no existe, el sistema no está preparado para explotarse con eficiencia.

Pruebas y automatización

La modernización debe traer un cambio cultural: de despliegues manuales y validaciones informales a automatización y evidencias. Como mínimo:

• Pruebas unitarias sobre lógica de negocio y componentes clave.
• Pruebas de integración de APIs, integraciones y flujos principales.
• Pruebas de regresión: asegurar que la modernización no rompe procesos críticos; imprescindible si hay convivencias por oleadas.
• Pruebas de rendimiento en operaciones críticas cuando el servicio tenga volumen o ventanas ajustadas.
• Automatización de la cadena de entrega (CI/CD): que la construcción del sistema, los análisis de calidad, las validaciones de seguridad y el despliegue en cada entorno sean procesos automatizados y reproducibles, no manuales."
• Gestión de configuración por entorno: que los parámetros y credenciales de cada entorno (desarrollo, preproducción, producción) estén separados del código de la aplicación y se gestionen con trazabilidad de quién cambia qué y cuándo.

El objetivo final es claro: poder desplegar con confianza, revertir si es necesario y demostrar con evidencias que el sistema cumple lo esperado en seguridad, rendimiento y operación.

Migración y puesta en producción

Esta sección describe cómo llevar la solución modernizada a producción con garantías: estrategia de datos, plan de transición, gestión del cambio con los usuarios, capacitación de equipos, lista de comprobación previa al arranque y estabilización posterior.

La modernización no termina cuando la nueva aplicación funciona en preproducción. Termina cuando entra en producción sin pérdida de continuidad, con capacidad real de operación y con un plan claro para retirar Forms.

Este punto describe cómo planificar la transición, cómo preparar a los usuarios y qué comprobar antes y después del paso a producción.

Estrategia de datos y migración

En aplicaciones Oracle Forms con años o décadas de operación, la gestión de datos puede ser el riesgo de mayor impacto en la modernización. Antes de definir el plan de transición, debe existir una estrategia de datos que contemple:

• Inventario de datos: identificar esquemas, tablas principales, volúmenes, calidad de datos y dependencias entre entidades. Determinar qué datos son operativos (necesarios en el sistema destino), cuáles son históricos (necesitan archivo, pero no migración activa) y cuáles pueden purgarse.
• Limpieza y saneamiento: definir reglas de limpieza antes de la migración (registros huérfanos, duplicados, datos inconsistentes, campos obsoletos). Migrar datos sucios es trasladar problemas al sistema nuevo.
• Estrategia de migración: decidir si la migración es completa (big bang de datos), incremental (por oleadas sincronizadas con la migración funcional) o selectiva (solo datos activos, con archivo del resto). Para cada opción, definir el mecanismo técnico (ETL, scripts, herramientas de migración, CDC).
• Coherencia durante la convivencia: si Forms y el sistema destino coexisten, definir cómo se mantiene la coherencia de datos (sistema maestro, sincronización, reglas de doble escritura, reconciliación periódica). Este es habitualmente el punto de mayor riesgo.
• Validación y reconciliación: definir controles que verifiquen que los datos migrados son correctos y completos (conteos, sumas de control, validaciones funcionales con usuarios clave).
• Rollback de datos: si el plan de vuelta atrás se activa, definir cómo se revierten los datos al estado anterior de forma fiable.

Plan de transición (convivencia, cut-over y rollback)

La transición debe diseñarse desde el inicio del proyecto, especialmente en modernizaciones por oleadas. La guía recomienda fijar, como mínimo, estos elementos:

• Estrategia de transición:
  • Big bang (cambio completo) solo si el perímetro es pequeño y el riesgo está controlado.
  • Por oleadas (Strangler) cuando la aplicación es grande, crítica o con integraciones complejas.
  • Convivencia temporal cuando Forms y el nuevo canal deben coexistir durante un periodo.
• Modelo de convivencia: definir con claridad qué parte se ejecuta en el legado y qué parte en la solución nueva, evitando solapes funcionales que generen confusión o duplicidad.
• Plan de corte: ventana de cambio, actividades minuto a minuto, responsables, verificación funcional y técnica, y criterios para declarar éxito.
• Plan de vuelta atrás (rollback): condiciones objetivas para activar reversión, procedimiento probado y tiempos máximos asumibles. No basta con pensar si algo falla volvemos: debe estar preparado y ensayado.

El principio es sencillo: un corte a producción es seguro cuando está diseñado para funcionar bien y para poder revertirse con la misma claridad.

Gestión del cambio

En Forms, el cambio suele ser relevante para el usuario final: interfaz, hábitos de trabajo y, a veces, pasos de proceso. Para evitar rechazo o caída de productividad:

• Identificar colectivos y casos de uso críticos: quién usa qué, con qué frecuencia y en qué momentos (cierres, campañas, periodos sensibles).
• Plan de comunicación: qué cambia, qué no cambia, cuándo cambia y dónde pedir ayuda.
• Formación orientada a tareas: formación práctica por perfiles y procesos, no por pantallas.
• Soporte reforzado en el arranque: canal de incidencias, tiempos de respuesta, responsables funcionales y técnicos, y un mecanismo rápido de priorización.
• Gestión de permisos y roles: evitar que el paso a producción se bloquee por autorizaciones incompletas o roles mal definidos.

Una puesta en producción técnicamente correcta puede fracasar si el usuario no puede trabajar con normalidad el primer día.

Capacitación de equipos técnicos

La modernización de Oracle Forms implica un cambio tecnológico significativo para los equipos de desarrollo y operación. No debe asumirse que un equipo con experiencia en Forms y PL/SQL puede abordar directamente una re-arquitectura con SPA, microservicios o incluso APEX sin un plan de capacitación previo.

Como parte del plan de modernización, debe evaluarse:

• Brecha de competencias: identificar qué conocimientos requiere el escenario destino (por ejemplo, desarrollo frontend con frameworks SPA, diseño de APIs REST, patrones de microservicios, prácticas DevSecOps, desarrollo APEX) y qué competencias tiene actualmente el equipo.
• Plan de formación: definir acciones concretas de capacitación (formación reglada, talleres prácticos, acompañamiento por equipos con experiencia) con anterioridad suficiente al inicio de la fase de construcción.
• Estrategia de acompañamiento: en los primeros proyectos de modernización de un organismo, considerar la participación de perfiles con experiencia en la tecnología destino (internos o externos) que actúen como referentes técnicos durante la ejecución.

Si la brecha de competencias es crítica y no puede resolverse en un plazo razonable, este factor debe considerarse en la selección del escenario (ver regla de prevalencia nº 3 del árbol de decisión).

Lista de comprobación para el paso a producción

Antes del paso a producción, debe existir una lista de comprobación común, breve pero exigente. Como mínimo:

Funcional

• Flujos críticos validados con usuarios clave (incluyendo casos límite).
• Criterios de aceptación cumplidos y evidencias registradas.
• Procedimiento operativo conocido (qué hacer ante errores frecuentes).

Integración y datos

• Integraciones verificadas extremo a extremo (no solo verificar la respuesta del servicio).
• Migración o sincronización ejecutada/validada según el plan.
• Controles de coherencia y reconciliación definidos.

Seguridad

• Autenticación/autorizaciones verificadas por roles.
• Secretos gestionados correctamente (sin credenciales en código/configuración expuesta).
• Registro de auditoría y trazabilidad disponibles y probados.

Operación

• Observabilidad activa (logs, métricas, alertas) y tableros disponibles.
• Procedimientos operativos mínimos documentados: guías paso a paso que cubran las operaciones esenciales del sistema, incluyendo cómo arrancarlo y detenerlo, cómo actuar ante las incidencias más frecuentes, cómo ampliar su capacidad cuando sea necesario y cómo recuperarlo en caso de fallo.
• Procedimiento de despliegue y rollback probado (al menos en preproducción).

Rendimiento

• Validación de rendimiento en operaciones críticas cuando aplique (picos, lotes, cierres).

Post-producción: estabilización y mejora continua

Tras el paso a producción, el objetivo es estabilizar y cerrar la transición con garantías:

• Periodo de estabilización planificado (días/semanas según criticidad), con seguimiento diario de métricas y de incidencias.
• Priorización de incidencias por impacto y criticidad, con capacidad de respuesta rápida.
• Revisión de observabilidad: ajustar alertas, completar trazabilidad y mejorar tableros según lo que se aprende en producción.
• Cierre de convivencias: retirar piezas de Forms que ya no aportan valor, eliminar integraciones temporales y reducir complejidad.
• Lecciones aprendidas: capturar decisiones y mejoras para la siguiente oleada o para otros proyectos Forms.

La modernización es un éxito cuando el sistema nuevo se opera con normalidad, Forms se retira de forma controlada y el servicio queda preparado para evolucionar sin volver a un modelo frágil.

Anexos:

Nota sobre el carácter de los anexos: Los Anexos I a IV de esta guía tienen carácter normativo y de obligado cumplimiento, no meramente informativo. Contienen los escenarios de modernización, las directrices técnicas comunes y las directrices específicas por tecnología destino que deben aplicarse en cualquier proyecto de modernización de Oracle Forms en la Junta de Andalucía.

Anexo I: Escenarios de modernización para Oracle Forms

Este capítulo recoge los escenarios recomendados para Oracle Forms con un formato homogéneo, pensado para decidir rápido y ejecutar sin ambigüedades. Cada escenario se expresa como una ficha de datos concisos: qué es, cuándo aplica, cuándo no, destino objetivo, pasos mínimos, entregables y riesgos habituales.
En todos los casos, si la modernización supera una actuación puramente de continuidad, el destino debe alinearse con el modelo por capas (presentación–APIs–servicios–datos) y con las capacidades transversales (seguridad, observabilidad y DevSecOps).

Escenario S0 — Retirar o Archivar (7R: Retire)

Qué es 
Cierre ordenado de la aplicación (o de parte de ella), garantizando continuidad funcional por sustitución, archivo y trazabilidad.

Cuándo aplica

• TIME orienta a Eliminar, o la aplicación está duplicada, infrautilizada o sustituida de facto.
• Existe alternativa corporativa o se puede absorber el proceso en otra solución con impacto asumible.
• El riesgo/coste de mantener Forms ya no se justifica.

Cuándo no aplica

• Es crítica y no hay sustitución real ni plan de transición (en ese caso, se debe plantear retirada por fases).

Destino objetivo

• Servicio retirado con datos archivados, integraciones desmontadas y trazabilidad conservada.

Pasos mínimos

1. Identificar sustitución/absorción funcional.
2. Plan de retirada (usuarios, ventanas, dependencias).
3. Archivo y cierre de integraciones.
4. Desactivación técnica y control de accesos.
5. Verificar obligaciones de retención legal y normativa de los datos gestionados por la aplicación antes de proceder al archivo o purga.

Entregables

• Informe de retirada, plan de transición, checklist de cierre y evidencias de archivo.

Riesgos típicos

• Funcionalidad oculta no inventariada; se mitiga con inventario y validación con usuarios clave.
• Incumplimiento de obligaciones de retención documental si no se verifica la normativa aplicable antes del archivo.

Escenario S1 — Continuidad controlada (7R: Retain)

Qué es 
Actuación de contención para reducir obsolescencia y riesgo operativo con el menor impacto posible (por ejemplo, actualización de Forms, ajustes de plataforma y refactorizaciones acotadas). No es un destino, es una estrategia puente que claramente mejora el estado actual, pero debe realizarse una actuación adicional en el medio plazo.

Cuándo aplica

• Urgencia por fin de soporte, vulnerabilidades o incompatibilidades.
• El sistema es estable y se prevé poca evolución a corto/medio plazo.
• No hay ventana realista para una reconstrucción o re-arquitectura inmediata.

Cuándo no aplica

• La aplicación es estratégica o requiere evolución frecuente, integración moderna o multicanalidad.
• Se pretende reducir dependencia estructural de Forms (ahí este escenario solo compra tiempo).

Destino objetivo

• Forms estabilizado y soportable, con un plan explícito de siguiente paso (reconstrucción a APEX / re-arquitectura / sustitución).

Pasos mínimos

1. Actualización y compatibilidad de entorno.
2. Refactorizaciones puntuales para reducir fragilidad (errores, dependencias).
3. Controles básicos de seguridad y operación.

Entregables

• Plan de continuidad (qué se cambia y qué no), evidencias de compatibilidad, checklist de operación.
• Fecha objetivo y criterios de salida documentados para la transición al escenario definitivo.

Riesgos típicos

• Convertir la solución puente en destino permanente; se mitiga fijando fecha objetivo y criterios de salida.

Escenario S2 — Reconstrucción a Oracle APEX (7R: Refactor / Rebuild)

Qué es 
Reconstrucción funcional en APEX para disponer de una solución web con alta productividad, especialmente adecuada para aplicaciones de gestión interna orientadas a datos.

Cuándo aplica

• Tipología Backoffice (escenario global modernización Back Office) o generalista (escenario global modernización generalista) con foco en formularios, consultas, expedientes internos, reporting operativo.
• Puede aplicar únicamente a algunos módulos funcionales o componentes del sistema. Otros pueden aplicar el escenario 3 o 4.
• Se busca velocidad de entrega y un modelo de evolución ágil.
• El encaje en ecosistema Oracle es aceptable y la complejidad de UX es moderada.
• El número de reports de la aplicación actual es elevada y costosa de implementar en otras soluciones.
• Puede combinarse con S3 (re-arquitectura), S4 (sustitución) o con ambos en la misma aplicación para facilitar un módulo de reports cuando exista un número de reports muy elevados o de complejidad alta.

Cuándo no aplica

• Experiencia de usuario muy específica, orientado al ciudadano o publicación en internet, multicanalidad compleja o necesidad fuerte de frontend desacoplado.
• Estrategia exige desacoplo profundo por dominios y escalado por equipos independientes (mejor S3).
• Integraciones críticas sin contratos claros (antes hay que “apificar”).

Destino objetivo

• UI en APEX consumiendo servicios externos mediante APIs (y/o eventos cuando aplique).

Pasos mínimos

1. Definir fronteras funcionales y pantallas prioritarias.
2. Estabilizar contratos de integración (APIs/eventos).
3. Construcción APEX por módulos, con pruebas y despliegue automatizado.
4. Transición por oleadas (si hay convivencia con Forms).

Entregables

• Arquitectura objetivo, catálogo de pantallas/módulos, contratos de integración, plan de transición y evidencias de seguridad/operación.

Riesgos típicos

• Consideración de dependencia tecnológica: La elección de APEX refuerza la vinculación al stack Oracle (base de datos y plataforma). Esta dependencia es aceptable cuando el organismo ya dispone de licenciamiento Oracle vigente y la aplicación no tiene requisitos de independencia tecnológica a medio plazo. Si la estrategia del organismo contempla diversificación tecnológica o reducción de dependencia de un único proveedor, este factor debe ponderarse en la decisión y documentarse como riesgo aceptado.

Escenario S3 — Re-arquitectura a arquitecturas de referencia (7R: Rearchitect)

Qué es

Transformación hacia una arquitectura desacoplada: presentación moderna (SPA o microfrontends), APIs como contrato, servicios/microservicios en backend y criterios corporativos de interoperabilidad, seguridad y observabilidad.

Cuándo aplica

• Aplicación estratégica (TIME = Invertir/Migrar), alta evolución o necesidad clara de desacoplo.
• Integraciones relevantes, necesidad de reutilización de servicios y escalado por dominios.
• Requisitos exigentes de operación (trazabilidad, disponibilidad, auditoría).
• Puede aplicar únicamente a algunos módulos funcionales o componentes del sistema. Otros pueden aplicar el escenario 2 o 4.

Cuándo no aplica

• Alcance pequeño y estable donde APEX o sustitución cubre el objetivo con menor coste.
• No existe capacidad de ejecución por fases y el riesgo de “big bang” es inasumible (en ese caso, S3 + oleadas).

Destino objetivo

• Frontend (SPA/microfrontends) + API-First + servicios backend (microservicios cuando proceda) + datos gestionados con patrón de transición.
• Uso de APIs y, cuando sea necesario, integración asíncrona (EDA) para desacoplar.
• Servicios de reporting de código abierto haciendo uso de motores tipo JasperReports, Apache POI, iText, OpenPDF, Apache FOP, LibreOffice, etc.

Pasos mínimos

1. Definir dominios y contratos (OpenAPI y eventos si aplica).
2. Extraer capacidades clave de Forms/PLSQL hacia servicios.
3. Sustituir pantallas por módulos, priorizando valor y riesgo.
4. Operacionalizar: CI/CD, seguridad, observabilidad desde el inicio.

Entregables

• Arquitectura objetivo por capas, catálogo de APIs, modelo de dominios, plan por oleadas, evidencias de pruebas/seguridad/observabilidad.

Riesgos típicos

• Subestimar la lógica en PL/SQL; se mitiga con inventario de reglas y estrategia explícita de extracción/encapsulado.

Escenario S4 — Sustitución por activo corporativo (7R: Repurchase/Relocate)

Qué es 
Sustitución por una solución corporativa o estándar que cubra el proceso con ventaja clara en coste, riesgo y sostenibilidad.

Cuándo aplica

• Existe plataforma corporativa o producto que cubre el caso de uso con buen encaje (habitual en ámbitos de Administración Digital – escenario global de modernización Administración Digital).
• La aplicación aporta poco diferencial propio y el problema es más de proceso que de software a medida.
• Puede aplicar únicamente a algunos módulos funcionales o componentes del sistema. Otros pueden aplicar el escenario 2 o 3.

Cuándo no aplica

• Diferencial funcional alto que obligaría a personalizaciones profundas (termina siendo desarrollo a medida encubierto).
• Integraciones y datos tan particulares que invalidan el beneficio.

Destino objetivo

• Solución estándar/corporativa integrada con el ecosistema mediante APIs/eventos y con transición controlada de datos/procesos.

Pasos mínimos

1. Confirmar encaje funcional y de integración.
2. Diseñar transición y convivencia (si aplica).
3. Migrar datos mínimos necesarios y retirar Forms.

Entregables

• Análisis de encaje, plan de transición, acuerdos de integración y checklist de retirada.

Riesgos típicos

• Infraestimar gestión del cambio y adopción; se mitiga con plan de formación y soporte.

Estrategia transversal — Modernización por oleadas (Strangler)

Qué es 
Patrón de transición para modernizar sin apagón: se van sustituyendo partes de Forms de forma incremental, manteniendo el servicio y controlando el riesgo.

Cuándo aplica

• Sistema grande/crítico, sin ventana para big bang.
• Necesidad de liberar valor pronto (primeras oleadas) mientras se reduce el riesgo estructural.

Cómo se aplica

• Puede combinarse con S2 (reconstrucción a APEX), con S3 (re-arquitectura), con S4 (sustitución) o con ambos en la misma aplicación cuando distintos módulos o dominios tengan perfiles diferentes.
• La clave es fijar oleadas con criterio: por módulos funcionales, por procesos, por dominios o por riesgo técnico.
• En el caso de escenarios mixtos (S2 + S3 + S4), debe definirse desde el inicio la estrategia de integración entre los componentes APEX y los componentes re-arquitecturados (normalmente mediante APIs), evitando que la convivencia genere acoplamientos no gobernados entre ambos destinos.

Entregables

• Mapa de oleadas, criterio de priorización, estrategia de convivencia, plan de corte/rollback y métricas de seguimiento.

Riesgos típicos

• Convivencia indefinida y duplicidades, que puede mitigarse con fechas objetivo, controles de retirada y control estricto de integraciones.

Anexo II: Directrices comunes

Inventario técnico real de Oracle Forms

Antes de plantear la estrategia de modernización, el equipo de proyecto debe cerrar un inventario mínimo de artefactos y dependencias. En Forms, el perímetro suele ser mayor de lo que parece:

• Artefactos Forms: módulos de formulario (FMB), menús (MMB), librerías (PLL), object libraries (OLB), program units y triggers relevantes.
• Triggers que suelen concentrar lógica: validaciones por item/registro, lógica previa y posterior a consultas, inserciones/actualizaciones/borrados, y triggers de commit/rollback.
  En términos funcionales: reglas de negocio, controles, cálculos y atajos que no aparecen en documentación técnica o funcional.
• Uso de built-ins y llamadas al sistema: ejecución de programas externos, apertura de URLs/documentos, exportaciones, generación de ficheros, automatización de Office/OLE, etc.
  Esto suele convertirse en integraciones nuevas (o en cambios de proceso).
• Dependencia de Oracle Reports / salidas impresas: qué se imprime, en qué punto del proceso y con qué formato.
• Dependencias BD: paquetes PL/SQL, triggers de BD, jobs (DBMS_SCHEDULER/DBMS_JOB), colas, DB links, vistas críticas, secuencias.
• Integraciones: intercambio por ficheros, tablas compartidas, accesos directos a esquemas de terceros.

Salida recomendada: un mapa de componentes (Forms + BD + integraciones) y un listado de riesgos (componentes no migrables, dependencias externas, lógica oculta).

NOTA : La Oficina de Arquitectura está trabajando en un facilitador para los proyectos para posibilitar este inventariado automático, y poder realizar este inventario técnico de forma autónoma una vez se disponga de acceso al código fuente y acceso a BD de la aplicación Oracle Forms.

Matriz de pantallas: Forms → pantalla destino (APEX o SPA) con criterio

La modernización no empieza por construir. Empieza por decidir qué pasa con cada pantalla/flujo.

Para cada Form (o conjunto de Forms), conviene levantar una matriz con estas columnas:

• Pantalla/Form + transacción principal (alta/consulta/modificación/cierre…)
• Complejidad de UI (simple CRUD / interacción avanzada / mucha validación / navegación compleja)
• Dependencias (tablas, paquetes PL/SQL, reports, integraciones)
• Regla de negocio asociada (qué se valida/calcula/autoriza)
• Criticidad y uso (frecuencia, picos, momentos críticos)
• Destino propuesto: APEX Page / SPA Route (y si aplica, microfrontend)
• Servicios/APIs que debe consumir (contrato)
• Riesgos y prerrequisitos (p. ej., “necesita API antes de migrar”)

Esto permite planificar oleadas con sentido: primero pantallas de alto valor y bajo riesgo, y dejar lo difícil (integraciones, cierres, procesos críticos) con preparación previa.

Descomposición de lógica: separar UI, negocio, persistencia e integración

Este es uno de los pasos fundamentales para garantizar la correcta modernización de la solución independientemente de la estrategia de modernización. En Oracle Forms suele haber lógica repartida entre:

• triggers Forms (UI y validación)
• paquetes PL/SQL (reglas y persistencia)
• triggers y procesos de BD (auditoría, reglas, automatismos)
• integraciones (ficheros, DB links, llamadas externas)

Para ordenar esto y facilitar el salto a otras tecnologías, se requiere imponer una separación mínima:

• Lógica de presentación (UI): navegación, habilitar/deshabilitar campos, mensajes, comportamiento de pantalla.
  Destino: APEX o SPA (no debe vivir en PL/SQL salvo utilidades puntuales).
• Lógica de negocio (dominio): reglas, validaciones, cálculos, transiciones de estado, permisos funcionales.
  Destino: idealmente en servicios (si vas a SPA/microservicios) o en paquetes de dominio (si vas a APEX y quieres mantener parte en BD).
• Lógica de persistencia: SQL, CRUD, consultas, mapeos, optimización, control de concurrencia.
  Destino: repositorios/DAO (servicios) o paquetes “repository” en BD.
• Lógica de integración: llamadas a otros sistemas, ficheros, mensajería, conectores.
  Destino: capa de interoperabilidad/adaptadores, no mezclada con dominio.

Regla práctica que evita muchos problemas:

El dominio de negocio decide; la persistencia guarda; la integración conecta; la UI presenta; el control transaccional no va escondido en triggers.

Estrategia de transacciones y concurrencia

Forms trabaja con un modelo de sesión (stateful) y transacción que no se traslada de forma directa a aplicaciones web. Antes de comenzar con la modernización, debe detallarse en el diseño y dejar claro los siguientes puntos:

• Qué operaciones eran una transacción en Forms (incluye pantallas múltiples, commits implícitos, triggers de commit).
• Cómo se gestiona el bloqueo/concurrencia (bloqueo pesimista, validaciones al guardar, etc.).
• Qué reglas dependían del estado de pantalla (variables globales, record groups, etc.).

En el destino, conviene fijar un criterio único que tenga sentido y minimice la complejidad:

• En APIs/servicios, una operación será una transacción (con idempotencia cuando aplique).
• Si hay procesos largos o con varios pasos, plantear orquestación (y si es necesario, patrón Saga/eventos).

Principio API First: Primero contrato, luego pantalla

Para cualquier tipo de estrategia de modernización, se requiere definir y diseñar correctamente los contratos de información y operaciones con cierta disciplina para minimizar esfuerzo, retrabajo y riesgos:

• Definir APIs versionadas como contrato y publicarlas bajo el modelo corporativo de gobierno (patrones como API Gateway y, si aplica, BFF). La arquitectura de referencia de APIs contempla principios como detectabilidad, reutilización y versionado, además de componentes de gestión (publicación, analítica, tráfico, portal, caché y observabilidad).
• Si hay integración asíncrona, aplicar patrones EDA (productores/consumidores, broker, registro de esquemas y mecanismos como DLQ, CDC u Outbox cuando proceda).

Anexo III: Directrices específicas Oracle Forms a APEX

Uso de APEX como canal

El grado de exigencia en la separación de capas dentro de APEX debe ser proporcional al escenario y a la evolución prevista de la aplicación:

• Aplicaciones con reconstrucción a Oracle APEX sin evolución prevista hacia Re-arquitectura: se acepta que las páginas APEX invoquen paquetes PL/SQL de dominio como contrato intermedio (paquetes que encapsulan reglas y acceso a datos). No se exige API REST como requisito previo, pero sí se exige que no haya SQL ni lógica de negocio directamente en los procesos de página.
• Aplicaciones con reconstrucción a Oracle APEX con posibilidad de evolución futura a Re-arquitectura o con integraciones relevantes: se exige diseño API-First desde el inicio. Las páginas APEX deben consumir APIs REST, y la lógica de negocio debe residir en servicios accesibles mediante dichas APIs. Esto reduce la velocidad de entrega inicial, pero protege la inversión ante una futura re-arquitectura.

En ambos casos, las integraciones con sistemas externos nunca deben resolverse desde la página APEX, sino canalizarse a través de la capa de integración correspondiente.

Decidir grado de reutilización y reescritura

Por cada uno de los elementos Forms de la aplicación existente es necesario decidir qué parte del código se puede reutilizar, y qué va a ser necesario reescribir en APEX:

• Validaciones de campo simples → suelen ir bien a APEX (con apoyo de servicios para reglas críticas).
• Reglas complejas y transiciones de estado → mejor sacarlas a servicio o paquete de dominio.
• Integraciones (ficheros, DB links, llamadas externas) → nunca en página; debe canalizarse por capa de integración.
• Impresión/reporting → definir destino (APEX reports, motor de reporting externo de la aplicación, motor de reporting corporativo, etc.) y el punto exacto del proceso donde se invoca.

Seguridad y autorización

APEX facilita autenticación, pero el punto crítico es la autorización:

• Integración en la medida de lo posible con las plataformas y activos corporativos: SSOWeb y GUIA.
• Definir roles/permisos equivalentes a Forms y aplicarlos con esquemas de autorización consistentes.
• Evitar seguridad a nivel de pantalla: el backend debe reforzar permisos.

Gobierno DevSecOps

Oracle APEX no puede quedarse fuera de las actuales prácticas y gobierno DevSecOps en la Junta de Andalucía. Debe exigirse a las modernizaciones que tengan como destino Oracle APEX:

• Versionado de código completo en repositorio oficial Junta de Andalucía.
• Existencia y uso de un pipeline de despliegue por entornos.
• Configuración separada y evidencias (pruebas, seguridad, observabilidad).

Anexo IV: Directrices específicas Oracle Forms a SPA/microservicios

En el caso de haberse seleccionado como estrategia de modernización de la aplicación una re-arquitectura con tecnología SPA y Microservicios, se exponen las siguientes directrices para aplicarse en el proceso:

Definición de dominios y subdominios

Antes de comenzar con la construcción de cualquier componente (ni frontend ni backend), es imprescindible definir los dominios de negocio, sus límites y los mecanismos de relación entre ellos. En Oracle Forms, la lógica de negocio suele estar organizada por pantallas o por tablas de base de datos, no por dominios funcionales. Esta diferencia de enfoque es la primera brecha que debe resolverse.

Directrices:

• Identificar los dominios de negocio a partir de los procesos que soporta la aplicación, no a partir de la estructura de tablas ni de la organización de formularios Forms. Un dominio agrupa las capacidades y reglas que pertenecen a un mismo contexto funcional (por ejemplo, "Expedientes", "Pagos", "Notificaciones", "Usuarios y permisos").
• Para cada dominio, definir su catálogo de capacidades: qué operaciones ofrece, qué datos gestiona y qué eventos produce o consume. Este catálogo es la base para el diseño posterior de APIs y servicios.
• Identificar las dependencias entre dominios y clasificarlas: dependencia de datos (un dominio necesita información de otro), dependencia de proceso (un dominio desencadena una acción en otro) o dependencia temporal (un dominio debe esperar a que otro complete una operación).
• Aplicar el patrón de descomposición por subdominio (decompose by subdomain) de la arquitectura de referencia de microservicios, distinguiendo entre subdominios core (ventaja diferencial), de soporte (necesarios pero no diferenciales) y genéricos (candidatos a solución estándar o compartida).
• Documentar los límites de cada dominio de forma explícita y validarlos con los responsables funcionales antes de avanzar al diseño técnico. Un error en la definición de dominios se propaga a toda la arquitectura y es costoso de corregir.

Relación con el inventario Forms: La matriz de pantallas del Anexo II y la descomposición de lógica proporcionan la entrada principal para este ejercicio. Las pantallas y los paquetes PL/SQL suelen agrupar lógica de varios dominios; el objetivo aquí es desacoplarla conceptualmente antes de hacerlo técnicamente.

Diseño de APIs y contratos antes de construir

La re-arquitectura desde Oracle Forms debe seguir un enfoque API-First: los contratos de los servicios se diseñan, revisan y acuerdan antes de construir frontend o backend. Esto rompe la dinámica habitual de Forms, donde la pantalla y la base de datos se construían simultáneamente sin un contrato explícito entre ambas.

Directrices:

• Especificar cada API con OpenAPI v3 o superior, incluyendo modelos de datos, operaciones, códigos de respuesta, validaciones y ejemplos. La especificación debe ser suficiente para que un equipo de frontend y un equipo de backend puedan trabajar en paralelo con un contrato común.
• Versionar las APIs desde el inicio. Definir la estrategia de versionado (por URL, por cabecera o por contenido) y las reglas de compatibilidad hacia atrás. Evitar cambios que rompan contratos existentes sin un proceso controlado de deprecación.
• Publicar las APIs bajo el modelo corporativo de gobierno (API Manager), aplicando políticas comunes de seguridad, control de acceso, limitación de tráfico y observabilidad en el punto de publicación.
• Cuando existan distintos canales o clientes con necesidades diferentes (por ejemplo, una SPA de escritorio y una futura aplicación móvil), valorar el uso del patrón BFF (Backend For Frontend) para adaptar las respuestas por canal sin modificar los servicios de dominio.
• Para integraciones asíncronas entre dominios, definir los contratos de eventos con la misma disciplina que las APIs REST: esquema del evento, versionado, semántica (evento de dominio, comando, notificación) y canal de publicación. Utilizar un registro de esquemas cuando el volumen de eventos lo justifique.

Error frecuente en modernizaciones Forms: Diseñar las APIs como un reflejo directo de las tablas de base de datos (una API por tabla). Esto produce APIs incoherentes que trasladan el acoplamiento a datos del modelo Forms al modelo nuevo. Las APIs deben modelar operaciones de negocio, no operaciones CRUD sobre tablas.

Microservicios solo cuando sea necesario

La re-arquitectura no tiene porque implicar obligatoriamente microservicios. La decisión entre una arquitectura de microservicios y un backend modular (monolito modular) debe basarse en necesidades reales, no en tendencias tecnológicas.

Directrices:

• Adoptar microservicios cuando exista al menos una de estas necesidades reales: despliegue independiente por dominio o equipo, escalado diferenciado por servicio, o requisitos de aislamiento de fallos entre dominios críticos.
• Si no se dan esas condiciones, un servicio backend modular (con separación interna por dominios, APIs bien definidas y capacidad de evolucionar hacia microservicios en el futuro) ofrece menor complejidad operativa con beneficios similares en mantenibilidad y separación de responsabilidades.
• Si se adopta microservicios, asumir el paquete completo de infraestructura y operación que la arquitectura de referencia establece: descubrimiento de servicios, balanceo de carga, configuración centralizada, gestión de secretos, resiliencia (circuit breaker, retry, timeout, fallback), y colector de observabilidad (trazas, métricas y logs).
• No mezclar servicios con granularidades muy diferentes sin justificación. Un microservicio que gestiona un dominio completo con decenas de entidades y otro que solo expone una operación auxiliar generan desequilibrios de mantenimiento y operación.
• Documentar explícitamente la decisión (microservicios o modular) y los criterios que la sustentan, como parte del plan de modernización.

Criterio práctico para aplicaciones Forms: Si la aplicación Forms original es de un tamaño contenido, utilizada por un solo equipo y cubre un proceso de negocio cohesionado, el backend modular suele ser la opción más sensata. Si la aplicación es grande, con múltiples equipos de mantenimiento, dominios claramente independientes y necesidad de evolucionar a ritmos distintos, microservicios aporta un valor real.

Estrategia de extracción de lógica desde PL/SQL

En Oracle Forms, una parte significativa (a veces mayoritaria) de la lógica de negocio reside en paquetes PL/SQL, triggers de base de datos y triggers de formulario. La extracción de esta lógica hacia servicios es una de las actividades de mayor riesgo y esfuerzo en la re-arquitectura. No puede improvisarse.

Directrices:

• Clasificar toda la lógica PL/SQL identificada en el inventario según su destino:
  • lógica de dominio (reglas de negocio, validaciones, cálculos, transiciones de estado) que debe migrar a servicios backend;
  • lógica de persistencia (consultas, CRUD, optimizaciones) que permanece en la capa de acceso a datos del servicio;
  • lógica de integración (llamadas a otros sistemas, ficheros, colas) que se canaliza por adaptadores;
  • y lógica de presentación (comportamiento de pantalla) que se reescribe en el frontend.
• Priorizar la extracción por valor y riesgo: comenzar por los paquetes PL/SQL que concentran las reglas de negocio más críticas y que más bloquean la modernización del frontend. Dejar para fases posteriores la lógica auxiliar o estable que puede mantenerse temporalmente en la base de datos con un adaptador.
• Cuando la extracción completa no sea viable en una oleada, encapsular la lógica PL/SQL existente detrás de una API REST temporal (un "wrapper" que expone el paquete como servicio). Esto permite al frontend consumir contratos modernos mientras se planifica la reescritura. Debe tratarse como medida transitoria con fecha de caducidad, no como solución permanente.
• Identificar y documentar las dependencias entre paquetes PL/SQL antes de extraer. En Forms es frecuente que un paquete invoque directamente a otros (cadenas de llamadas), y romper una de esas cadenas sin entender el grafo completo puede producir errores difíciles de diagnosticar.
• Los triggers de base de datos (INSERT/UPDATE/DELETE triggers) merecen atención especial: suelen contener lógica de auditoría, validaciones cruzadas o propagación de datos que no es visible desde el formulario. Debe decidirse explícitamente si esa lógica se traslada al servicio, se mantiene en la base de datos o se sustituye por un mecanismo de eventos.

Frontend: SPA, microfrontends y criterio de decisión

La sustitución de los formularios Oracle Forms por un frontend web moderno debe responder a criterios operativos y de equipo, no solo estéticos.

Directrices:

• Adoptar SPA (Single Page Application) como opción por defecto cuando la aplicación es mantenida por un solo equipo, el producto tiene una identidad funcional cohesionada y no hay necesidad de despliegue independiente por módulo de interfaz.
• Adoptar microfrontends solo cuando se justifique por equipos múltiples que necesitan desplegar de forma independiente, o cuando módulos funcionales claramente diferenciados deben evolucionar a ritmos distintos. Si se opta por microfrontends, asumir los componentes que la arquitectura de referencia establece: Application Shell, mecanismo de comunicación entre módulos (Event Bus o similar), librerías compartidas de diseño (design system) y observabilidad integrada.
• Independientemente de la elección (SPA o microfrontends), el frontend debe consumir exclusivamente APIs publicadas. No se permiten accesos directos a base de datos, invocaciones a PL/SQL desde el cliente ni dependencias de componentes del servidor que no pasen por un contrato de API.
• Utilizar el sistema de diseño de la Junta de Andalucía y la guía de componentes visuales compartida desde el inicio. En las modernizaciones por oleadas, la coexistencia de pantallas Forms y pantallas nuevas puede producir una experiencia de usuario fragmentada si no hay coherencia visual.
• Planificar la migración de pantallas por oleadas siguiendo la matriz del Anexo II: primero pantallas de alto valor de negocio y baja complejidad técnica, para generar adopción temprana; después, pantallas complejas con integraciones críticas, que requieren que los servicios backend ya estén disponibles.

Aspecto frecuentemente olvidado en migraciones Forms: Los atajos de teclado y los flujos de navegación rápida que los usuarios de Forms dominan tras años de uso. La nueva interfaz debe contemplar la eficiencia operativa del usuario experto, no solo la accesibilidad del usuario novel. Ignorar esto es una causa frecuente de rechazo en el arranque.

Reports

La sustitución de los reports, listados y documentos generados en la aplicación con Oracle Reports puede convertirse en un problema dependiendo del número y complejidad de los reports a migrar.

• Separar la generación de documentos de la lógica de negocio. En Oracle Forms/Reports, es frecuente que el informe contenga lógica de negocio (cálculos, filtros, reglas de formato condicional) además de la mera presentación de datos. La modernización debe separar estas responsabilidades: la lógica de negocio pertenece al servicio; el motor de reporting solo se ocupa de formatear y generar el documento a partir de datos que recibe.
• Definir el motor de reporting antes de construir. La elección del motor de reporting destino condiciona cómo se diseñan los servicios que alimentan los informes, qué formatos de plantilla se usan y cómo se integra la generación de documentos en el flujo de la aplicación. No debe dejarse para el final:
  • Adoptar soluciones, librerías o motores de código abierto que permitan generar reports, listados o documentos en servicios de backend. Esta solución tiene sentido para un número contenido de reports, que tengan una complejidad media y cuyo coste de desarrollo sea asumible por el proyecto.
  • Plantear extraer todos los reports a un módulo o componente específico, que sea solucionado con otro escenario (por ejemplo, S2 reconstrucción a APEX) que permita agilizar la generación de un número muy elevado de reports o con complejidad muy alta.
• Tratar la generación de documentos como un servicio. En la arquitectura modernizada, la generación de informes y documentos debería exponerse como un servicio más, invocable mediante API, con su propio contrato (datos de entrada, formato de salida, parámetros de configuración). Esto permite reutilizarlo desde cualquier canal y desacoplarlo del frontend.

Datos: propiedad, sincronización y gestión del legado

Oracle Forms trabaja típicamente con un esquema de base de datos compartido al que acceden todos los formularios, y a menudo también otros sistemas mediante DB links o accesos directos. La re-arquitectura debe romper este acoplamiento, pero hacerlo de golpe puede ser inviable.

Directrices:

• Definir la propiedad de datos por dominio o servicio: cada servicio es responsable de sus datos y es el único que puede leerlos y escribirlos directamente. Los demás servicios acceden a esos datos a través de la API del servicio propietario, nunca mediante acceso directo a sus tablas.
• Cuando sea necesario sincronizar datos entre servicios, utilizar mecanismos de eventos (CDC, patrón Outbox) en lugar de compartir base de datos. El patrón Outbox garantiza consistencia entre la operación de negocio y la publicación del evento dentro de la misma transacción.
• Donde haya legado fuerte (esquemas compartidos con otros sistemas que no se modernizan simultáneamente), aplicar una capa anti-corrupción (anti-corruption layer) que traduzca entre el modelo de datos heredado y el modelo del dominio nuevo. Esto evita que las decisiones de diseño del legado contaminen la arquitectura nueva.
• En la fase de convivencia (Forms y nuevo sistema coexistiendo), definir con claridad cuál es el sistema maestro para cada entidad de datos y cuál es la dirección de sincronización. La doble escritura (ambos sistemas escriben los mismos datos) es el patrón de mayor riesgo y debe evitarse siempre que sea posible; si es inevitable, debe implementarse con mecanismos de reconciliación y alertas de inconsistencia.
• Planificar la migración de datos conforme a la sección "Estrategia de datos y migración" del cuerpo de la guía, con especial atención a: limpieza previa de datos heredados, validación de integridad tras la migración y pruebas de reconciliación con usuarios clave.

Gestión de transacciones en un entorno distribuido

Oracle Forms trabaja con un modelo de transacción que no se traslada directamente a una arquitectura de servicios: sesiones con estado (stateful), commits implícitos, bloqueos pesimistas y transacciones que abarcan múltiples pantallas. La re-arquitectura debe redefinir el modelo transaccional con criterios claros.

Directrices:

• Como regla general, cada operación de API debe ser una transacción completa y autónoma. El servicio recibe una petición, ejecuta la lógica y confirma o revierte la transacción antes de responder. No se mantiene estado de transacción entre llamadas.
• Diseñar las operaciones como idempotentes cuando sea posible: repetir la misma petición debe producir el mismo resultado sin efectos secundarios no deseados. Esto es fundamental para gestionar reintentos en caso de fallos de red o timeouts.
• Cuando un proceso de negocio requiere coordinación entre varios servicios (lo que en Forms era una transacción larga que abarcaba varias pantallas o pasos), utilizar el patrón Saga: una secuencia de transacciones locales en las que cada servicio ejecuta su parte y, si algún paso falla, se ejecutan acciones de compensación para revertir los pasos anteriores.
• Sustituir los bloqueos pesimistas de Forms (que bloqueaban registros al abrirlos en pantalla) por validaciones optimistas en el servicio: el servicio verifica que los datos no han sido modificados por otro usuario entre la lectura y la escritura, y si lo han sido, notifica el conflicto en lugar de bloquear.
• Documentar explícitamente en el diseño de cada servicio cuál es la frontera transaccional, qué garantías de consistencia se ofrecen y cómo se gestionan los conflictos. En Forms esta información estaba implícita en los triggers de commit; en la nueva arquitectura debe ser explícita.

Riesgo frecuente en migraciones Forms: Intentar replicar el comportamiento transaccional exacto de Forms (sesión con estado, bloqueos, commits de múltiples tablas en una sola operación) en una arquitectura de servicios. Esto produce servicios con estado, acoplamiento temporal y cuellos de botella. El modelo transaccional debe rediseñarse, no trasladarse.

Seguridad en arquitecturas distribuidas

La re-arquitectura introduce una superficie de ataque mayor que un monolito Forms: más endpoints, más comunicaciones entre servicios, más componentes que gestionar. Los controles generales de la sección "Calidad, seguridad y operación" de la guía son de obligado cumplimiento; las directrices siguientes son específicas para este escenario.

Directrices:

• Implementar autenticación y autorización centralizadas, integradas con las plataformas corporativas (SSOWeb, GUIA). El token de identidad del usuario debe propagarse a través de toda la cadena de servicios para mantener la trazabilidad del actor en cada operación.
• Proteger la comunicación entre servicios con mTLS (mutual TLS) o mecanismos equivalentes que garanticen autenticación mutua y cifrado. El tráfico entre servicios no debe circular en claro, incluso dentro de la misma red.
• Aplicar el principio de mínimo privilegio en la comunicación entre servicios: cada servicio solo debe poder invocar las APIs de otros servicios que necesita, con los permisos estrictamente necesarios. Utilizar políticas de red, service mesh o configuración de API Gateway para imponer estas restricciones.
• Gestionar los secretos (credenciales, claves de API, certificados) mediante mecanismos corporativos de custodia, con rotación automática y sin almacenamiento en código, ficheros de configuración o imágenes de contenedor. Cada entorno (desarrollo, preproducción, producción) debe tener sus propios secretos, nunca compartidos.
• Validar las entradas en cada servicio de forma independiente, incluso para las llamadas entre servicios internos. No asumir que la petición es segura por provenir de otro servicio del mismo sistema; un fallo de seguridad en un servicio no debe propagarse a los demás.
• Registrar eventos de seguridad (autenticaciones, autorizaciones denegadas, accesos a datos sensibles, modificaciones de configuración) con trazabilidad suficiente para investigación de incidentes, conforme a los requisitos del ENS.

Estrategia de pruebas para arquitecturas distribuidas

La re-arquitectura a servicios requiere una estrategia de pruebas adaptada a la naturaleza distribuida del sistema. Las pruebas que eran suficientes en un monolito Forms (validación manual de pantalla más pruebas sobre base de datos) no cubren los escenarios de fallo de una arquitectura con múltiples servicios comunicándose por red.

Directrices:

• Contract testing: verificar que los contratos de API entre servicios se respetan en ambos lados (productor y consumidor). El productor garantiza que no rompe el contrato publicado; el consumidor garantiza que sus expectativas son compatibles con el contrato real. Este tipo de prueba es especialmente importante en modernizaciones por oleadas, donde los contratos evolucionan mientras el sistema está en producción.
• Pruebas de integración entre servicios: validar los flujos que involucran múltiples servicios en un entorno integrado, con especial atención a la gestión de errores, reintentos y timeouts. Debe probarse no solo el caso exitoso ("happy path"), sino los escenarios de fallo parcial: qué ocurre cuando un servicio intermedio no responde, cuando la respuesta llega fuera de tiempo o cuando el mensaje se pierde.
• Pruebas end-to-end: cubrir los flujos de usuario completos sobre el sistema desplegado, priorizando los procesos críticos de negocio. Estas pruebas son las más costosas de mantener; por ello, deben limitarse a los flujos de mayor valor y riesgo, no aspirar a cubrir toda la funcionalidad.
• Pruebas de resiliencia: verificar el comportamiento del sistema ante fallos parciales (caída de un servicio, latencia elevada, pérdida de mensajes, saturación de una cola) para asegurar que los patrones de resiliencia (circuit breaker, retry, fallback) funcionan correctamente. Estas pruebas pueden ser manuales en las primeras oleadas, pero deben automatizarse progresivamente.
• Pruebas de regresión funcional: en modernizaciones por oleadas donde Forms y el sistema nuevo conviven, las pruebas de regresión son imprescindibles para detectar roturas en los puntos de integración entre ambos mundos. Definir un conjunto de casos de regresión automatizados sobre los flujos que cruzan la frontera legado-nuevo.
• Pruebas de rendimiento: ejecutar pruebas de carga sobre los flujos críticos con volúmenes realistas antes de cada paso a producción. En Forms, el rendimiento dependía principalmente de la base de datos y de la red cliente-servidor; en la nueva arquitectura, depende además de la latencia entre servicios, la serialización/deserialización y la capacidad de los brokers de mensajería.

Observabilidad en arquitecturas distribuidas

La observabilidad en una arquitectura de servicios va más allá de los requisitos generales de la guía. En un monolito Forms, un problema se diagnosticaba mirando la base de datos y el log del servidor de aplicaciones. En una arquitectura distribuida, un problema puede originarse en cualquier servicio, en la red entre servicios, en el broker de mensajería o en un timeout que desencadena un efecto cascada. Sin observabilidad adecuada, el tiempo de diagnóstico se multiplica.

Directrices:

• Correlación de trazas distribuidas: cada petición de usuario debe llevar un identificador de correlación (trace ID) que se propague a todos los servicios implicados en el flujo, tanto en comunicaciones síncronas (APIs) como asíncronas (eventos). Esto permite reconstruir el recorrido completo de una operación y localizar dónde se produce la degradación o el fallo.
• Métricas por servicio: cada servicio debe exponer métricas individuales (latencia por operación, tasa de error, throughput, uso de recursos) en un formato estándar consumible por el sistema de monitorización corporativo. Estas métricas deben alimentar tableros a dos niveles: tablero técnico por servicio (para el equipo de operaciones) y tablero de flujos de negocio (para el equipo funcional y de dirección).
• Agregación centralizada de logs: los logs de todos los servicios deben consolidarse en un sistema centralizado que permita búsqueda, filtrado y correlación por trace ID, por servicio, por nivel de severidad y por ventana temporal. Los logs deben estar estructurados (formato JSON o equivalente) y no deben exponer datos personales ni sensibles.
• Alertas con contexto: las alertas deben identificar el servicio afectado, el flujo de negocio impactado y la severidad estimada, no solo el síntoma técnico (por ejemplo, "error 500 en servicio X"). Definir umbrales de alerta proporcionados a la criticidad del servicio para evitar ruido. Las alertas sin acción definida no son alertas; son ruido.
• Health checks y readiness: cada servicio debe exponer endpoints de salud (health check) y de disponibilidad (readiness) que permitan al orquestador de contenedores o al balanceador detectar automáticamente cuándo un servicio no está operativo y actuar en consecuencia (reinicio, desvío de tráfico).

Infraestructura, despliegue y DevSecOps

La re-arquitectura no se completa en el código; el modelo de despliegue y operación es tan importante como el diseño de los servicios. En Oracle Forms, el despliegue era un proceso manual sobre un servidor de aplicaciones compartido. En la nueva arquitectura, cada servicio puede desplegarse de forma independiente, lo que exige automatización y disciplina.

Directrices:

• Cada servicio debe tener su propio pipeline de CI/CD que incluya, como mínimo: compilación, ejecución de pruebas unitarias y de contrato, análisis estático de código, análisis de vulnerabilidades en dependencias, construcción de artefacto desplegable (imagen de contenedor cuando proceda) y despliegue automatizado por entornos (desarrollo, preproducción, producción).
• Externalizar toda la configuración específica de entorno (URLs de otros servicios, credenciales, parámetros de negocio configurables) fuera del artefacto desplegable. La misma imagen de contenedor debe poder desplegarse en cualquier entorno cambiando únicamente la configuración externa.
• Utilizar contenedores como unidad de despliegue estándar para los servicios backend, salvo justificación técnica documentada. Los contenedores deben construirse sobre imágenes base corporativas o verificadas, con actualizaciones periódicas de seguridad.
• Definir la estrategia de despliegue por servicio: despliegue azul-verde (blue-green), canary release o rolling update, según la criticidad del servicio y la tolerancia al riesgo. En todos los casos, debe existir un procedimiento de rollback automatizado y probado.
• Implementar feature flags para funcionalidades que se despliegan de forma progresiva o que necesitan activarse o desactivarse sin redespliegue. Esto es especialmente útil durante la convivencia por oleadas, cuando una funcionalidad debe estar disponible solo para ciertos usuarios o entornos.
• La cadena de CI/CD debe generar evidencias objetivas (informes de pruebas, análisis de seguridad, métricas de cobertura, resultados de análisis estático) que alimenten los gates de gobernanza definidos en el cuerpo de la guía. Sin estas evidencias, el gate de paso a producción no se supera.

Gestión de la convivencia con Oracle Forms durante la transición

En la mayoría de re-arquitecturas de aplicaciones Forms de tamaño medio o grande, habrá un periodo de convivencia en el que parte de la aplicación sigue funcionando en Forms y parte ya opera en la nueva arquitectura. Este periodo es el de mayor riesgo operativo y requiere directrices específicas.

Directrices:

• Definir desde el inicio un mapa de convivencia que muestre, para cada oleada, qué funcionalidades operan en Forms y cuáles en el sistema nuevo. Este mapa debe actualizarse en cada oleada y estar disponible para los equipos de operación y soporte.
• Implementar un mecanismo de enrutamiento (reverse proxy, API gateway o similar) que dirija al usuario a la interfaz correcta (Forms o SPA) según la funcionalidad que esté utilizando. La transición debe ser lo más transparente posible para el usuario.
• Durante la convivencia, la base de datos de Forms suele seguir siendo el punto de integración de facto. Debe definirse explícitamente qué servicios nuevos pueden acceder temporalmente a las tablas de Forms (con adaptador y capa anti-corrupción), qué tablas se migran a la propiedad de los nuevos servicios y en qué oleada se produce el corte.
• Establecer pruebas de regresión específicas para los puntos de integración entre Forms y el sistema nuevo. Cada oleada que modifica estos puntos debe ejecutar estas pruebas como condición para el despliegue.
• Fijar fechas objetivo de cierre de convivencia por módulo o dominio. La convivencia indefinida genera costes dobles de mantenimiento, complejidad operativa y confusión en los usuarios. Cada módulo que sigue en Forms tras su fecha objetivo debe justificarse formalmente.
• Planificar la retirada progresiva de Forms conforme a las directrices del escenario S0 (Retire), incluyendo archivo de datos, cierre de integraciones y desactivación de accesos.

Glosario

• TIME: Marco de clasificación estratégica del enfoque corporativo de modernización de la Junta de Andalucía. Permite evaluar cada aplicación del inventario en función de su valor para la organización y su estado técnico, asignándola a una de las cuatro categorías: Tolerar (mantener sin inversión activa), Invertir (destinar recursos para asegurar su futuro), Migrar (mover a un modelo o plataforma objetivo) o Eliminar (retirar de forma ordenada).
• 7R (Retire, Retain, Rehost, Replatform, Refactor/Rebuild, Rearchitect, Repurchase/Relocate): Conjunto de siete acciones tácticas de modernización que concretan la clasificación TIME en una decisión ejecutable. Cada acción define un nivel de intervención distinto, desde la retirada de la aplicación hasta su rediseño arquitectónico completo. En el contexto de esta guía, las acciones 7R se asocian a los escenarios de modernización S0 a S4.
• SPA (Single Page Application): Patrón de desarrollo de aplicaciones web en el que el navegador carga una única página y actualiza su contenido de forma dinámica mediante llamadas a APIs, sin recargar la página completa. Ofrece una experiencia de usuario fluida y permite desacoplar completamente el frontend del backend. Ejemplos de frameworks habituales para SPA son Angular, React y Vue.
• BFF (Backend For Frontend): Patrón arquitectónico en el que se crea un servicio backend específico para cada tipo de cliente o canal (web, móvil, etc.). El BFF actúa como intermediario entre el frontend y los servicios de negocio, adaptando las respuestas al formato y las necesidades de cada canal sin modificar los servicios subyacentes.
• EDA (Event-Driven Architecture): Arquitectura orientada a eventos. Modelo de diseño en el que los componentes del sistema se comunican mediante la emisión y el consumo de eventos a través de un broker de mensajería, en lugar de hacerlo mediante llamadas directas entre servicios. Favorece el desacoplamiento, la reactividad y la integración flexible entre sistemas.
• CDC (Change Data Capture): Técnica que detecta y captura los cambios realizados en una base de datos (inserciones, actualizaciones, borrados) y los propaga como eventos a otros sistemas. Permite sincronizar datos entre servicios o sistemas sin recurrir a consultas directas ni a integraciones acopladas a la base de datos origen.
• CQRS (Command Query Responsibility Segregation): Patrón de diseño que separa las operaciones de lectura (queries) de las operaciones de escritura (commands) en modelos de datos distintos. Permite optimizar cada modelo de forma independiente y es especialmente útil en sistemas con alta concurrencia o con requisitos de rendimiento asimétricos entre lectura y escritura.
• DLQ (Dead Letter Queue): Cola de mensajes fallidos. Mecanismo utilizado en sistemas de mensajería y arquitecturas orientadas a eventos para almacenar los mensajes que no han podido ser procesados correctamente tras un número definido de reintentos. Permite diagnosticar errores, reprocesar mensajes y evitar la pérdida de información en flujos asíncronos.
• Outbox (patrón Transactional Outbox): Patrón de integración que garantiza la consistencia entre una operación de base de datos y la publicación de un evento. En lugar de publicar el evento directamente, la operación escribe el evento en una tabla auxiliar ("outbox") dentro de la misma transacción de base de datos, y un proceso independiente se encarga de leer esa tabla y publicar los eventos en el broker. Evita la pérdida de eventos ante fallos parciales.
• Strangler (patrón Strangler Fig / estrangulamiento): Patrón de modernización progresiva que permite sustituir un sistema legado de forma incremental. Las funcionalidades se migran una a una al nuevo sistema mientras el legado sigue operativo; el tráfico se redirige gradualmente hasta que el sistema antiguo queda sin uso y puede retirarse. Toma su nombre de la higuera estranguladora, que crece alrededor de un árbol existente hasta reemplazarlo.
• ENS (Esquema Nacional de Seguridad): Marco normativo español (regulado por el Real Decreto 311/2022) que establece los principios, requisitos y medidas de seguridad que deben aplicar las administraciones públicas y sus proveedores tecnológicos para proteger la información y los servicios electrónicos. Es de obligado cumplimiento para los sistemas de la Junta de Andalucía.
• RGPD (Reglamento General de Protección de Datos): Reglamento (UE) 2016/679 del Parlamento Europeo y del Consejo que regula el tratamiento de datos personales en la Unión Europea. Establece obligaciones sobre recogida, almacenamiento, uso y eliminación de datos personales, así como los derechos de los ciudadanos sobre su información. Es de aplicación directa en España.
• RTO (Recovery Time Objective): Tiempo máximo aceptable que puede transcurrir desde que se produce una interrupción del servicio hasta que el sistema vuelve a estar operativo. Define el objetivo de tiempo de recuperación y es un parámetro clave para dimensionar la infraestructura, los procedimientos de contingencia y los planes de continuidad.
• RPO (Recovery Point Objective): Cantidad máxima de datos (medida en tiempo) que la organización puede permitirse perder en caso de interrupción. Por ejemplo, un RPO de una hora significa que el sistema debe poder recuperarse a un estado que no tenga más de una hora de antigüedad. Determina la frecuencia de copias de seguridad y la estrategia de replicación.
• mTLS (mutual Transport Layer Security): Variante del protocolo TLS en la que tanto el cliente como el servidor se autentican mutuamente mediante certificados digitales, no solo el servidor como en TLS estándar. Se utiliza en comunicaciones entre servicios (especialmente en arquitecturas de microservicios) para garantizar que ambos extremos son legítimos y que el tráfico está cifrado.
• OLB (Object Library): Tipo de archivo de Oracle Forms (.olb) que almacena objetos reutilizables (bloques, elementos, ventanas, alertas, etc.) que pueden compartirse entre múltiples formularios. Permite estandarizar componentes visuales y de comportamiento en una aplicación Forms.
• FMB (Form Module Binary): Archivo fuente de un formulario de Oracle Forms (.fmb). Contiene la definición completa de un formulario: bloques de datos, elementos de pantalla, triggers, program units, propiedades visuales y lógica asociada. Es el artefacto principal de desarrollo en Oracle Forms y se compila para generar el ejecutable (.fmx).
• PLL (PL/SQL Library): Biblioteca de código PL/SQL reutilizable en Oracle Forms (.pll). Contiene funciones, procedimientos y paquetes que pueden ser invocados desde múltiples formularios o menús. Permite centralizar lógica común (validaciones, utilidades, reglas de negocio compartidas) evitando duplicación de código entre módulos.
• MMB (Menu Module Binary): Archivo fuente de un módulo de menú de Oracle Forms (.mmb). Define la estructura de menús de la aplicación (barras, menús desplegables, elementos y sus acciones asociadas). Se compila para generar el ejecutable (.mmx) y suele compartirse entre varios formularios de una misma aplicación.