Para IT y responsables de IT

Lo que se le pide validar

Alguien del lado de negocio ha visto la página principal de IdeaBuild y quiere avanzar. Esta página es para quienes tienen que decir si es seguro, si encaja y qué le costará a IT operarlo. Sin marketing. Todo lo que hay aquí enlaza a una nota técnica más profunda.

Qué es

Una base de aplicaciones abierta y contenerizada (.NET 10, React 18, PostgreSQL 16, Keycloak 24, Redis 7, Docker) más dos servicios de entrega: ingeniería de aplicaciones a medida acelerada con IA, y migración incremental desde Oracle APEX, OutSystems y runtimes similares.

Qué no es

No es una plataforma low-code, no es un SaaS, no es un runtime con licencia. Usted recibe código fuente, esquemas y runbooks, desplegados en su infraestructura o en la nube soberana que elija.

Qué tiene que comprobar

Modelo de seguridad, residencia de datos, integración de identidad, riesgo de migración, operabilidad y qué pasa el día dos. Cada punto tiene una sección más abajo y una línea en la lista de control del final.

Dos servicios sobre una base abierta

Servicio 1

Entrega de aplicaciones acelerada con IA

Sus expertos de dominio describen cómo funciona el negocio. Nuestros ingenieros usan IA para sintetizar servicios C# y componentes React sobre la base preconstruida, verificados contra más de 1.200 tests automatizados de backend y más de 100 suites end-to-end antes de que nada llegue a sus manos.

Servicio 2

Migración de sistemas legados

Las reglas de negocio enterradas en paquetes PL/SQL, regiones APEX o runtimes OutSystems se extraen a servicios C# limpios y pantallas React, y se conmutan módulo a módulo con el sistema legado funcionando en paralelo hasta demostrar la paridad.

La base

La parte que no vuelve a construir

Ambos servicios parten de la misma pila auditada: gateway Nginx, identidad con Keycloak, bases de datos transaccional y de auditoría segregadas, APIs .NET modulares, SPAs React, telemetría completa.

.NET 10 · React 18 · PostgreSQL 16 · Keycloak 24 · Redis 7 · Docker

La IA escribe código dentro de controles que usted puede inspeccionar

La primera pregunta que hace IT: cómo evitan que el modelo invente reglas o vea nuestros datos. La respuesta es estructural, no una política.

IA dentro de controles

El conocimiento de dominio entra por la izquierda. La síntesis con IA está dentro de un marco amarillo de cuatro controles: especificaciones ejecutables, tests que deben pasar, módulos preconstruidos y auditados, sin datos de producción. Por la derecha sale C# y React verificado. Saberexperto Síntesis IA Specs ejecutables de sus expertos 1.200+ tests deben pasar Módulos hechos y auditados No usa datos reales ValidadoC# + React El modelo nunca ve credenciales, filas de producción ni secretos

Cumplimiento determinista de reglas

La salida de la IA está limitada por especificaciones ejecutables escritas con sus expertos de dominio. Las reglas de negocio se verifican con tests, no confiando en el modelo. Sin deriva de lógica ni reglas alucinadas en producción.

Exposición de datos cero

Las bases de datos de producción, las credenciales y las reglas propietarias nunca se envían a modelos externos ni se usan para entrenamiento. La síntesis trabaja sobre esquemas y especificaciones, no sobre sus datos.

Bloques ya probados

RBAC, auditoría, grids de datos, pipelines de documentos, i18n y parametrización se ensamblan a partir de módulos que ya traen sus propias suites de tests.

Ciclo de vida

Semana 1: arquitectura y blueprint de dominio con sus expertos. Semanas 2 a 4: síntesis y verificación aceleradas con IA. Semana 5: despliegue contenerizado en su entorno con telemetría, runbooks y traspaso. Marco de entrega de aplicaciones con IA

Doce capacidades que no tiene que construir

01

Identidad y acceso (IAM)

Keycloak 24, OIDC/OAuth2 con PKCE, segundo factor TOTP, control de sesiones, auditoría de accesos de administración.

02

RBAC en el servidor

Cada endpoint evalúa claims y políticas en el servidor. Ocultar elementos de la UI nunca es la frontera de seguridad.

03

Auditoría inmutable

Estado JSON previo y posterior a cada mutación, usuario, IP y marca de tiempo, enviados vía Redis Streams a una base de datos de auditoría dedicada.

04

Grids de datos de alto volumen

Ordenación, paginación y filtrado en servidor sobre millones de filas, vistas guardadas, exportación XLSX.

05

Búsqueda en lenguaje natural

Texto libre convertido en filtros de columna validados, limitados por los permisos del usuario y las reglas de índices.

06

Motor de reglas y alertas

Condiciones configurables, notificaciones por email, disparadores de eventos, historial de ejecución.

07

Parametrización centralizada

Ajustes, políticas, credenciales de terceros y zonas horarias gestionados desde el backoffice, cifrados con AES-256, recarga en caliente.

08

Pipeline de documentos

Subidas vinculadas a entidades, validación MIME, detección de zip bombs y macros, renderizado PDF vía Gotenberg.

09

Temas de marca blanca

Logos, tipografía y colores por tenant en tiempo de ejecución, sin redesplegar.

10

i18n multilingüe

Un único catálogo para las vistas React y los mensajes de validación .NET.

11

Observabilidad

Prometheus, Grafana, Loki/Promtail, Seq con IDs de correlación.

12

Fachada MCP de auditoría

Servidor Model Context Protocol de solo lectura para análisis de incidentes asistido por IA, sin credenciales de base de datos.

Siete capas, todas contenerizadas, todas suyas

Todo corre bajo Docker Compose en sus hosts o en una nube soberana. Ningún componente requiere licencia. Descripción completa de las capas en la metodología de migración.

Las siete capas

Pila por capas. El ingress Nginx es la única superficie pública. Bajo una línea discontinua marcada como red interna: frontends React y Keycloak, cinco servicios .NET, y después PostgreSQL main, PostgreSQL audit y Redis. Una banda de telemetría recorre el lado derecho. Internet público Capa 1 · Nginx ingress TLS, rate limits, CSP/HSTS, bloquea puertos admin única entrada pública Red interna de Docker. Nada de aquí abajo publica puertos. Capa 5 · Frontends React 18 Portal público · Panel operativo · Backoffice Capa 3 · Keycloak 24 OIDC, PKCE, TOTP Capa 4 · Servicios .NET 10 api-auth · api-private · api-backoffice · api-audit · api-diag PostgreSQL main datos de negocio PostgreSQL audit aislada, solo inserción Redis 7 caché, sesiones, streams Capa 2 · Datos y caché Capas 6 a 7 Telemetría Prometheus Grafana Seq Loki Todo lo interior a la línea discontinua solo es accesible desde otros contenedores.
CapaFunción
1 · NginxÚnico punto de entrada público. Terminación TLS, limitación de tasa, cabeceras CSP/HSTS, bloquea los puertos de administración y diagnóstico.
2 · Datospostgres-main para las entidades de negocio; postgres-audit aislada para el histórico de cumplimiento; Redis para caché, sesiones y streams de eventos de auditoría.
3 · IdentidadKeycloak 24. OAuth2/PKCE, JWT firmados, TOTP obligatorio; consola de administración solo en red privada.
4 · Serviciosapi-auth, api-private, api-backoffice, api-audit, api-diag
5 · FrontendsReact 18 + Vite. Portal público, panel operativo, backoffice; biblioteca de componentes compartida.
6 a 7 · TelemetríaMétricas Prometheus de los exporters de Nginx, Postgres y Redis; Grafana; logs estructurados en Seq; logs de contenedores con Loki/Promtail.

Qué le pasa a una petición

Una petición, de principio a fin

El navegador obtiene un token de Keycloak, llama a través de Nginx a un servicio .NET que comprueba RBAC y lee y escribe en PostgreSQL main. Cada mutación emite un evento a Redis Streams que el servicio de auditoría almacena en PostgreSQL audit, donde los servicios de aplicación no pueden escribir. 1 · ClienteHTTPS, PKCE 2 · NginxTLS, rate limiting 3 · Servicio .NETValida JWT + RBAC 4 · PostgreSQL mainsolo red interna KeycloakJWT firmado 5 · evento de cambio Redis Streamsusuario, antes/después 6 · PostgreSQL auditconsumido por api-audit apps: solo lectura Cada escritura deja un registro antes/después en un almacén que la app no puede alterar.
  1. 1El navegador se autentica en Keycloak por HTTPS usando PKCE y recibe un JWT firmado.
  2. 2Cada llamada a la API entra por Nginx, que termina TLS, aplica límites de tasa y cabeceras de seguridad, y rechaza cualquier cosa dirigida a puertos internos.
  3. 3El servicio .NET de destino valida la firma del token y evalúa las políticas RBAC en el servidor antes de tocar datos.
  4. 4Las lecturas y escrituras van a postgres-main únicamente por la red interna de Docker.
  5. 5Cada mutación publica un evento (usuario, IP, marca de tiempo, estado anterior y nuevo) en Redis Streams.
  6. 6api-audit consume el stream y lo persiste en postgres-audit, una instancia separada en la que los servicios de aplicación no pueden escribir directamente.

Zero-trust por construcción

Autorización en el servidor, siempre

Los claims se evalúan por endpoint. Los botones ocultos son una decisión de UX, nunca el control. Esto cierra la clase de problemas BOLA y de manipulación de parámetros habitual en plataformas departamentales.

Dos bases de datos, no una

El histórico de auditoría vive en una instancia PostgreSQL separada. Los privilegios elevados sobre la base de datos transaccional no alcanzan el registro de auditoría.

Segundo factor obligatorio

TOTP (RFC 6238) en Keycloak, obligatorio para los realms administrativos.

Una sola puerta de entrada

Nginx es la única superficie publicada. Las bases de datos, Redis, la administración de Keycloak, los diagnósticos y los sockets MCP son inalcanzables desde fuera.

Verificado en cada arranque

Tres comprobaciones automáticas detienen el despliegue si se incumplen: no-published-ports, production-blocks-tools, attachments-volume-not-served. Las subidas nunca residen en una ruta pública; las descargas se sirven a través de APIs autenticadas.

La IA nunca ve producción

No se envían datos de producción, credenciales ni reglas a modelos externos. Nota técnica sobre OIDC y RBAC en Keycloak

Conectar con lo que ya tiene en marcha

Identidad
Los directorios existentes se federan en Keycloak sin forzar el restablecimiento de contraseñas. El SSO permite a los usuarios moverse entre pantallas legadas y nuevas en una misma sesión.
APIs
Cada capacidad se expone mediante endpoints REST documentados en los servicios .NET. La integración con ERP, CRM o plataformas de datos pasa por ellos, con el mismo RBAC.
Sincronización de datos durante la migración
Change Data Capture vía Redis Streams o Kafka mantiene la base de datos legada y PostgreSQL replicadas con latencia inferior al segundo y doble escritura en ambos sentidos.
Documentos y exportaciones
Office/HTML a PDF vía Gotenberg, exportación XLSX desde cualquier grid, subidas vinculadas a entidades de negocio.
Notificaciones
Email y disparadores de eventos desde el motor de reglas.

Dónde viven sus datos y quién puede tocarlos

Residencia
En su hardware o en la región de nube soberana que elija. IdeaBuild no aloja nada.
Aislamiento
Los servicios acceden a las bases de datos solo por la red interna de Docker. No se publica ningún puerto de base de datos.
Auditoría
Cada cambio es recuperable como estado antes/después, con actor y origen, en un almacén que la aplicación no puede sobrescribir.
Propiedad
Esquemas, migraciones y datos son suyos desde el primer día; no hay un paso de exportación al final del contrato.
Modelos externos
No se entrenan con sus datos de producción ni se consultan con ellos.

Cinco fases, sin big bang

Cada fase tiene un punto de vuelta atrás. El sistema legado nunca se apaga antes de que el sustituto se haya demostrado en producción. Metodología de migración de legado · Informe sobre la trampa del low-code

Strangler Fig: el legado se reduce, lo nuevo crece

Cinco columnas de P1 a P5. En cada una, un bloque gris de legado se reduce y un bloque amarillo nuevo crece. La doble escritura con CDC abarca las fases dos a cuatro. Cada fase tiene una marca de reversión. En la fase cinco el legado es cero y la licencia termina. Legado Nuevo dual-write / CDC reversiónreversiónreversiónreversión sin licencia P1 Análisis P2 Replicación P3 Identidad P4 Servicios P5 Traspaso
  1. P1

    Descubrimiento automatizado de esquemas y reglas

    El análisis estático de DDL, triggers, secuencias y paquetes PL/SQL produce un mapa de la lógica enterrada y un arnés de tests ejecutable antes de cambiar una línea de código.

  2. P2

    Replicación en paralelo y doble escritura

    PostgreSQL 16 aprovisionado junto a la base de datos legada; CDC mantiene ambas sincronizadas sin deriva.

  3. P3

    Federación de identidad

    Los usuarios existentes aterrizan en Keycloak; SSO entre pantallas antiguas y nuevas.

  4. P4

    Extracción modular de servicios

    Los procedimientos y flujos ligados a pantallas se convierten en servicios C# con RBAC en servidor y auditoría, verificados contra el arnés.

  5. P5

    Traspaso de pantallas y baja de la licencia

    Las pantallas pasan a React de una en una; cuando la telemetría muestra paridad, se cortan las conexiones legadas y la licencia propietaria termina.

Qué necesitamos de su parte

Infraestructura
Hosts Linux con Docker (on-prem o nube) con capacidad para PostgreSQL ×2, Redis, Keycloak, los servicios API y los frontends. El dimensionamiento se acuerda en la evaluación.
Red
Un ingress público para Nginx; red interna para todo lo demás; SMTP de salida para notificaciones.
Acceso para el análisis inicial
Acceso de lectura a esquemas y código legados (DDL, paquetes, exportaciones OutSystems) y a la fuente de identidad para la federación.
Personas
Expertos de dominio para la semana de blueprint (unas horas cada uno); un responsable de IT para entornos y accesos; un contacto de seguridad para la revisión.
Tiempo
Cinco semanas para una aplicación nueva sobre la base. La duración de una migración depende del número de pantallas y reglas halladas en la fase 1 y se estima tras el análisis inicial.

Quién hace qué

Cuadrícula de seis áreas por tres partes: Negocio, IT, IdeaBuild. Las celdas amarillas significan responsable, las celdas con borde significan consultado, las negras significan entrega. ÁREA NEGOCIO IT IDEABUILD Reglas de negocio y prioridades Dueño Consultado Capta, valida Entornos y alojamiento Dueño Define, instala Fuente de identidad y SSO Dueño Integra Revisión de seguridad y firma Dueño Prueba, corrige Código, tests, runbooks Recibe Entrega Operación día dos Dueño Forma, apoya Dueño Consultado / recibe Entrega No participa

Oracle APEX vs OutSystems vs base abierta

DimensiónOracle APEXOutSystemsBase IdeaBuild
Dependencia de runtimeMotor Oracle Database (PL/SQL)Runtime compilado propietario.NET 10 y PostgreSQL de código abierto
LicenciamientoCores de CPU de BD / créditos cloudPor usuario + por nivel de aplicaciónSin licencias; autoalojado
TalentoEspecialistas nicho en PL/SQL y APEXDesarrolladores certificados en la plataformaMercado de C#, React y SQL
FlexibilidadUI ligada a objetos de base de datosLímites duros en lógica compleja a medidaServicios modulares, sin techo
Propiedad del códigoSolo exportación de metadatosCódigo ofuscado al desvincularseRepositorios Git limpios y documentados
AuditoríaAñadidos a medidaAñadidos a medidaAlmacén de estado antes/después integrado

Diez cosas que IT debe comprobar antes de decir que sí

  1. 01¿Se aplica la autorización en el servidor en cada endpoint?Seguridad
  2. 02¿Puede alguien con privilegios de base de datos alterar el registro de auditoría?Seguridad
  3. 03¿Dónde viven los datos y quién los aloja?Datos
  4. 04¿Se integra con nuestro proveedor de identidad sin restablecer contraseñas?Integración
  5. 05¿Se envía algún dato de producción a un modelo de IA externo?Entrega con IA
  6. 06¿Qué queda expuesto a internet?Arquitectura
  7. 07¿Podemos volver atrás en cada fase de la migración?Migración
  8. 08¿Qué recibimos en el traspaso y puede mantenerlo nuestro equipo?Responsabilidades
  9. 09¿Cuánto cuesta operarlo el día dos?Matriz
  10. 10¿Podemos verlo funcionando antes de comprometernos?Consola en vivo
Sesión técnica

Reserve una sesión técnica de arquitectura

Traiga a su responsable de seguridad y a quien tenga a su cargo el sistema legado. Recorremos la arquitectura, abrimos los repositorios y respondemos a la lista de control línea por línea.

NDA mutuo antes de cualquier reunión inicial