Bienvenido a BC Scout Path, empezamos con el primer articulo de Power Platform!
Si os encanta trastear tanto como a mí en Power Platform seguramente habréis explorado y creado planes✍️ (con menor o mayor éxito en los resultados🫣), pero debemos de darle una pensada a lo que esto implica mas allá de ver agentes pasandose la patata caliente de uno a otro.
Si lo miramos desde una perspectiva puramente arquitectónica🔬, Create a plan no es una feature “bonita con IA”. Es un mecanismo de modelado asistido 📐 por especificación dentro de Microsoft Power Platform. Y eso cambia el punto de entrada del diseño🤯.
🧠 Qué es realmente a nivel técnico
Create a plan es un artefacto estructurado que:
- Recoge una descripción funcional en lenguaje natural
- La transforma en un modelo conceptual de solución
- Genera componentes dentro del entorno (environment)
El output no es solo documentación.
Es infraestructura lógica inicial desplegable:
- Tablas en Microsoft Dataverse
- Apps en Microsoft Power Apps
- Flujos en Microsoft Power Automate
- Relaciones y estructura base
Desde el punto de vista arquitectónico, es un generador de baseline solution architecture.
🤖 Arquitectura Multi-Agente en Power Platform
Impacto de un handoff secuencial:
Requirements → Process → Data → Solution
Si definimos una solución usando 4 agentes especializados y hacemos que trabajen en secuencia, no estamos “usando IA” ni improvisando con "Vibe Coding".
Estamos diseñando un pipeline de arquitectura asistida.
Este enfoque es especialmente interesante dentro de Microsoft Power Platform cuando queremos acercarnos a un modelo más determinista y gobernado.
🧩 El Modelo de Handoff Secuencial
Orden de ejecución:
- 📝 Requirements Agent
- 🔄 Process Agent
- 🗂️ Data Agent
- 🏗️ Solution Agent
Cada agente:
- Recibe el output estructurado del anterior
- Valida su dominio
- Enriquece el modelo
- Pasa artefactos definidos al siguiente
No es conversación libre.
Es transferencia de artefactos estructurados.
📝 1️⃣ Requirements Agent
Impacto arquitectónico
Su función es transformar lenguaje natural en:
- Actores (roles de usuario)
- Casos de uso (User stories)
- Reglas de negocio
- Restricciones
🔎 Impacto positivo
- Reduce ambigüedad inicial
- Fuerza explicitación de reglas
- Genera base trazable
⚠️ Riesgo
Si el plan no está bien definido:
- Puede generar requisitos vagos
- No detecta contradicciones
- No prioriza correctamente
👉 Aquí se define el alcance real del sistema.
🔄 2️⃣ Process Agent
Traduce requisitos a flujo operativo
Toma:
- Actores
- User stories
- Restricciones
Y construye:
- Flujos de negocio
- Flujos de aprobación
- Diagramas de proceso
🔎 Impacto positivo
- Estandariza y documenta patrones de proceso
- Reduce automatizaciones improvisadas
- Alinea con mejores prácticas
⚠️ Riesgo
- Sobre-automatización
- Ignorar límites de conectores
- No considerar licenciamiento
👉 Aquí se define la lógica operativa del sistema.
🗂️ 3️⃣ Data Agent
Traduce procesos a modelo relacional
Toma:
- Actores
- User stories
- Restricciones
Y define:
- Tablas
- Relaciones 1:N / N:N
- Ownership
- Campos calculados
- Normalización
🔎 Impacto positivo
- Evita diseño UI-first
- Reduce deuda técnica
- Mejora escalabilidad
- Facilita ALM
⚠️ Riesgo
- Sobre-normalización
- No modelar volumen esperado
- Ignorar estrategia de seguridad
👉 Aquí se define la columna vertebral estructural.
🏗️ 4️⃣ Solution Agent
Orquesta implementación técnica
Recibe:
- Modelo de datos
- Flujos de negocio
- Requisitos funcionales
Y decide:
- Tipo de app (model-driven vs canvas)
- Automatizaciones.
- Componentes reutilizables
- Naming conventions
- Solution layering
- Dependencias premium
Impacta en:
Microsoft Power Apps
Microsoft Power Automate
🔎 Impacto positivo
- Coherencia estructural
- Alineación con arquitectura
- Estandarización técnica
⚠️ Riesgo
- No validar estrategia ALM
- No tener en consideración roles y seguridad
- No prever integración futura y futura escalabilidad
👉 Aquí se define la materialización técnica final.
🧩 Impacto en arquitectura empresarial
Antes teníamos que nadar en este lago antes de entregar algo:
- Workshops funcionales
- Whiteboard
- Modelado manual
- Prototipo posterior
Ahora nos metemos en la siguiente piscina:
- Especificación inicial generada en minutos
- Ajuste sobre modelo existente
- Iteración rápida
- Validación temprana
Esto reduce el time-to-architecture draft significativamente.
🧠 Relación con Spec Driven Development
Create a plan se alinea con un enfoque de:
Specification → Model → Implementation ⚒️
En lugar de:
UI first → Patch data model later 💣
Y eso en el desarrollo de proyectos empresarial, es un cambio cultural importante.
📐 Consideraciones clave para arquitectos
El atractivo "Create a plan" no sustituye decisiones críticas:
🔐 Seguridad
- No define modelo completo de roles RBAC
- No entiende que datos son sensibles
- No optimiza segregación por business unit
- No valida estrategia de ownership
🏗️ ALM
Genera componentes dentro de un environment
Hay que revisar:
- Solution layering
- Environment Variables
- Naming conventions
- Publisher strategy
📊 Performance
- No optimiza esquemas
- No modela escenarios de alto volumen
💳 Licensing
- Puede activar conectores premium
- Impacto directo en coste
- Impacto en almacenamiento de datos
🚀 Conclusión Arquitectónica
Create a plan no es un generador mágico de soluciones finales, es un acelerador de arquitectura inicial.
Bien usado:
- Reduce fricción en discovery
- Mejora coherencia estructural
- Facilita iteración temprana
Mal usado:
- Genera soluciones superficiales
- Puede inducir falsa sensación de diseño completo
Como arquitectos de soluciones la clave no es delegar el diseño a la IA, sino usarla para acelerar el primer 20% estructural y luego aplicar nuestro criterio técnico real para entregar una solución de calidad.
Remember: Talk is cheap, show me the code!