Arquitectura de Advance

La arquitectura de Advance parte de una idea simple: la operación debe poder seguirse de extremo a extremo.

Un contrato define servicios, frecuencias, niveles de servicio y responsabilidades. Esa información se relaciona con sitios, edificios, espacios, sistemas y activos. A partir de esa base, Advance transforma las obligaciones operacionales en demanda calendarizada, calcula la capacidad requerida, identifica brechas, organiza la cobertura y conecta la planificación con la ejecución real.

La secuencia central puede expresarse así:

Contrato → infraestructura → demanda → capacidad → planificación → ejecución → evidencia → control

Esta continuidad permite que una actividad no exista como un registro aislado. Cada orden, rutina, asignación o intervención conserva relación con el contexto que le dio origen y con la evidencia que confirma su ejecución.

La arquitectura busca reducir la fragmentación habitual entre sistemas comerciales, planillas de planificación, aplicaciones de terreno y herramientas de reportería. Cada componente mantiene su función, pero opera dentro de un modelo común de información y gobierno.

El núcleo de Advance se organiza en trece dominios funcionales que cubren la operación de extremo a extremo.

Estos dominios incluyen la plataforma y el tenancy, la gobernanza, los clientes y contratos, la infraestructura y los activos, las personas y proveedores, la demanda recurrente, la planificación y cobertura, la elasticidad GIG, la ejecución operacional, la evidencia y trazabilidad, las señales operacionales, los KPI y SLA, y la capa de asistencia y aprendizaje.

Esta organización permite separar responsabilidades sin perder continuidad. La planificación puede evolucionar sin confundirse con la ejecución; la evidencia puede mantener sus propias reglas sin quedar desconectada de las órdenes de trabajo; y la analítica puede consumir información operacional sin convertirse en el registro maestro del sistema.

Cada dominio posee límites definidos, relaciones conocidas con los demás y reglas que pueden validarse de manera independiente. De esta forma, Advance evita convertirse en una aplicación monolítica donde cualquier cambio afecta toda la plataforma.

La certificación de estos dominios es un mecanismo técnico interno basado en evidencia de implementación. No corresponde a una certificación externa como ISO 27001 o SOC 2. Su objetivo es comprobar que la plataforma ejecuta, dentro de un alcance definido, lo que declara funcionalmente.

La arquitectura productiva de Advance está definida sobre el ecosistema Microsoft.

Microsoft Entra ID constituye la base de identidad y acceso. La autenticación se transforma en permisos asociados al usuario, su organización, su rol y el tenant al que pertenece.

Azure Static Web Apps entrega las superficies web de Advance y GIG, mientras Azure Functions soporta la capa de servicios y las API operacionales. Esta separación permite mantener una experiencia web ágil y una lógica de negocio centralizada, gobernada y reutilizable.

La persistencia se diseña sobre servicios de datos administrados de Microsoft Azure, seleccionados según el tipo de carga. La información transaccional requiere consistencia e integridad; la evidencia necesita almacenamiento seguro de archivos; las señales operacionales pueden requerir mayor elasticidad; y la analítica debe consumir información sin comprometer el registro operacional.

La observabilidad productiva se apoya en Azure Monitor y Application Insights, permitiendo relacionar solicitudes, errores, procesos y transiciones operacionales.

La integración con Microsoft 365 conecta Advance con el entorno empresarial en el que las organizaciones ya trabajan, incluyendo identidad, colaboración, comunicaciones y automatización.

Advance fue concebido para integrarse a ese ecosistema sin transformarse en una capa externa difícil de gobernar. La arquitectura busca aprovechar identidad empresarial, servicios administrados, observabilidad y capacidades de integración dentro de una misma plataforma tecnológica.

Advance está concebido para operar con múltiples organizaciones dentro de una misma plataforma, manteniendo separación lógica y operacional entre ellas.

El tenant no es solo un campo visible en la interfaz. Forma parte del contexto de identidad, autorización, consulta, persistencia, auditoría y ejecución.

Cada solicitud protegida debe resolverse dentro de un tenant válido. Los datos, relaciones y acciones deben mantenerse dentro de ese límite, evitando accesos o asociaciones entre organizaciones que no correspondan.

La administración de plataforma se mantiene separada de la operación de cada tenant. Esto permite configurar, habilitar y supervisar organizaciones sin convertir la capa administrativa en un acceso irrestricto o invisible.

Este enfoque permite que Advance crezca hacia múltiples clientes sin perder trazabilidad, control ni aislamiento. El diseño multi-tenant no se agrega al final como una adaptación comercial, sino que forma parte de la arquitectura desde su base.

Una de las decisiones arquitectónicas más importantes de Advance consiste en proteger las reglas críticas durante la ejecución del sistema.

La validación del tenant, la autorización de usuarios, las transiciones de estado, la integridad de la información y la vinculación de la evidencia no dependen únicamente del comportamiento de la interfaz. Forman parte del propio runtime de la plataforma.

Esto permite que las mismas reglas se mantengan consistentes independientemente de si una acción proviene de Advance Web, de GIG, de una integración o de un agente de inteligencia artificial.

Advance también incorpora idempotencia en procesos repetibles, prevención de duplicados, validación de relaciones y rechazo explícito de entradas inválidas. El objetivo es evitar que una operación aparentemente exitosa oculte inconsistencias en los datos o en el flujo de trabajo.

La plataforma debe distinguir entre un valor real, una ausencia de datos, una configuración incompleta y un error de ejecución. Esta diferencia es especialmente importante en planificación, cobertura, KPI y SLA, donde un cero incorrecto puede producir una decisión operacional equivocada.

Advance funciona como el espacio principal de planificación, coordinación y control. GIG lleva la ejecución hacia técnicos, auxiliares, supervisores, proveedores y otros actores en terreno.

GIG no es una aplicación aislada del negocio. Es el canal operacional que conecta la demanda y la planificación con las personas que ejecutan el trabajo.

Su función es transformar el plan operativo en disponibilidad laboral real. Para ello relaciona frecuencia, calendario, horas requeridas, dotación, turnos, perfiles y cobertura.

Cuando la capacidad interna no resulta suficiente, GIG permite identificar la brecha y activar alternativas de refuerzo, redistribución o cobertura adicional.

Advance y GIG comparten identidad, datos, reglas y trazabilidad. Las asignaciones, estados, checklists, tiempos y evidencias generadas en terreno permanecen vinculadas al contrato, servicio, sitio, activo o actividad que les dio origen.

Esto permite recorrer una cadena completa desde la necesidad inicial hasta la evidencia de cumplimiento, sin crear un silo independiente de ejecución.

Copilot incorpora una capa de asistencia contextual sobre Advance.

Su arquitectura distingue entre consultar información, interpretar el contexto, preparar una recomendación y ejecutar una acción. No todos los agentes deben tener acceso a los mismos niveles.

Un agente puede leer información autorizada, resumir el estado de una operación o proponer una acción sin necesariamente ejecutarla. Las acciones con impacto requieren permisos explícitos y, cuando corresponde, confirmación humana.

Los agentes deben respetar los mismos límites de usuario, rol y tenant que el resto de la plataforma. Una acción asistida por inteligencia artificial no puede obtener privilegios adicionales por ejecutarse en segundo plano.

La trazabilidad también se extiende a esta capa. Las interacciones relevantes pueden registrar la solicitud, el usuario, el tenant, la herramienta utilizada, el resultado y la aprobación asociada.

De esta forma, Copilot no se incorpora como una capa paralela o independiente, sino como una capacidad integrada al modelo de gobierno de Advance.

Advance aplica una estrategia de seguridad por capas.

Microsoft Entra ID protege la identidad empresarial. La autorización combina rol, tenant y contexto operacional. Las API validan permisos y reglas antes de ejecutar acciones. Los datos mantienen separación entre organizaciones. Los secretos y configuraciones sensibles se administran fuera del código.

Staging y producción permanecen separados en identidad, configuración, datos y despliegue. Una validación realizada en staging no se interpreta automáticamente como evidencia productiva.

La trazabilidad conecta el contexto contractual con la ejecución real. Una operación puede recorrerse desde el contrato y el servicio hasta la planificación, la asignación, el trabajo realizado, la evidencia y los indicadores asociados.

Esta capacidad permite entender no solo qué ocurrió, sino también por qué ocurrió, quién intervino y cuál fue el resultado.

La evidencia no se considera un archivo suelto. Debe conservar relación con una orden de trabajo, un dispatch, una asignación GIG u otro contexto operacional válido.

La evolución de Advance se apoya en control de versiones, pruebas automatizadas, integración continua, entornos separados y evidencia de release.

Los cambios se validan según su impacto. Las modificaciones que afectan identidad, datos, tenancy, API o producción requieren controles mayores que un ajuste visual o documental.

Staging se utiliza para integración, validación, certificación y demostraciones controladas. Producción corresponde al entorno real y mantiene configuración, identidad, datos y autorización independientes.

La promoción entre ambos entornos requiere validaciones técnicas, smoke tests y autorización explícita. La paridad entre staging y producción debe comprobarse; no se presume.

Este modelo permite que la plataforma evolucione sin perder control sobre decisiones críticas, dependencias entre dominios y condiciones de operación.

Advance cuenta con trece dominios funcionales certificados internamente dentro de su alcance definido y se encuentra preparado para demostraciones controladas.

La plataforma continúa evolucionando hacia una operación productiva Microsoft completamente repetible, observable y escalable. Este proceso incluye la consolidación de la plataforma de datos, la observabilidad, el onboarding de nuevos tenants, el aislamiento productivo y los procedimientos operacionales.

La arquitectura se gobierna mediante evidencia técnica y límites explícitos. Esto permite avanzar sin confundir una capacidad demostrable con una promesa productiva aún no validada.

El objetivo no es presentar Advance como una plataforma terminada de forma absoluta, sino como un sistema con una base técnica sólida, una arquitectura definida y un proceso de evolución controlado.

Advance no fue diseñado únicamente para digitalizar órdenes de trabajo.

Su propósito es conectar contratos, infraestructura, personas, planificación, ejecución y evidencia dentro de una arquitectura operacional común.

Sobre una base Microsoft-native, multi-tenant y trazable, Advance permite que Wacner y sus clientes construyan operaciones más visibles, gobernadas y capaces de evolucionar sin perder control.