Noray - Revisión Arquitectónica ISV Dynamics 365 Sales (Hotelería)

El punto de partida

Un equipo de dos desarrolladores con alto nivel técnico pero sin experiencia previa en Power Platform llevaba más de tres meses construyendo un CRM hotelero sobre Dynamics 365 Sales. Habían avanzado con agilidad: 56 tablas, más de 60 plugins, lógica de negocio compleja. Pero todo crecía en una única solución monolítica, sin criterios claros para elegir entre plugin, Power Automate o JavaScript, sin pipeline de entrega, y sin visión de los límites que la plataforma Microsoft impone a escala.

El equipo reconocía que necesitaba una mirada externa. No para frenar, sino para asegurarse de que lo construido aguantara el peso de producción real.

Lo que aporté

1. Un marco de decisión que el equipo no tenía

Antes de las sesiones, la elección de tecnología era instintiva: si algo requería lógica, se hacía por plugin porque era lo que dominaban. En la primera sesión establecimos juntos un criterio claro y jerarquizado: JavaScript solo para lógica de interfaz de usuario, Power Automate para procesos asíncronos y de larga duración, y plugin únicamente cuando la ejecución síncrona o la complejidad lo justifican. Al final de la sesión, uno de los desarrolladores lo recitó de vuelta sin consultarlo. Eso es cuando sabes que ha calado.

2. Una distinción arquitectónica crítica que nadie había formalizado

Los sistemas externos del sector hotelero — PMS, motores de reservas, OTAs — no generan contactos. Generan leads. El contacto nace internamente, cuando el equipo comercial cualifica ese lead. Una distinción aparentemente menor que tiene impacto directo en el diseño de integraciones, en la deduplicación de perfiles y en la integridad de un programa de fidelización de puntos. Nadie en el equipo lo había formulado de forma explícita hasta que lo pusimos sobre la mesa.

3. Detección de riesgos reales ante los límites de la plataforma

Analicé los 51 plugins del ensamblado, identificando cuatro con riesgo alto frente a los Service Protection Limits de Dataverse: plugins que consultan todas las transacciones de un socio, que se disparan en batch durante check-outs masivos, o que encadenan 8-10 operaciones por llamada. En un despliegue multi-hotel con carga real, esos plugins son bombas de relojería. El equipo no era consciente del riesgo porque no lo había necesitado enfrentar todavía.

4. Un repositorio de CI/CD funcional, no un concepto

El equipo sabía que debía tener un pipeline de entrega. No sabía por dónde empezar. En la segunda sesión entregué un repositorio con GitHub Actions operativo: exportación e importación de soluciones automatizada con pack/unpack, tests unitarios con FakeXrmEasy, tests de interfaz con Playwright, y despliegue automatizado entre entornos. No un ejemplo didáctico: un punto de arranque real que podían clonar y adaptar ese mismo día.

5. La separación de assemblies por tabla

Una recomendación que desde fuera parece obvia, pero que desde dentro no lo es cuando has construido durante meses sin ese criterio. Al verla, uno de los desarrolladores respondió: "se nos abrieron los ojos, cómo no se nos ocurrió antes." Un problema de colisiones entre los dos desarrolladores, resuelto con una decisión estructural simple.

El resultado

Al finalizar las sesiones, el equipo contaba con criterios de decisión propios para las elecciones técnicas cotidianas, una hoja de ruta priorizada para las siguientes fases, y confianza en que la arquitectura que estaban construyendo tenía los cimientos adecuados para escalar a producción y superar la validación de AppSource.

La clave no fue señalar lo que estaba mal. Fue ayudarles a construir el criterio para hacerlo bien por sí mismos a partir de ese momento.

Mi reflexión sobre esto

"El mayor valor de incorporar una revisión arquitectónica externa en una fase temprana no es encontrar errores: es ayudar al equipo a tomar decisiones con información completa. En un proyecto ISV sobre Dynamics 365, las decisiones de los primeros meses —nombres lógicos de entidades, estructura de soluciones, modelo de seguridad— son prácticamente irreversibles. Hacerlas bien desde el principio es la mejor inversión que puede hacer el equipo."