Architecting Power Platform for Complex Enterprise Solutions with Ian Tweedie [MVP]

Microsoft Power Platform suele describirse como una plataforma de bajo código. Pero ¿qué ocurre cuando las aplicaciones que construyes se vuelven críticas para el negocio, están muy integradas y son demasiado complejas para un enfoque sencillo orientado al creador?En este episodio de M365 FM, Mirko Peters conversa con el arquitecto de soluciones de Power Platform Ian Tweedie sobre lo que sucede cuando Power Platform deja atrás las aplicaciones simples de bajo código y pasa a formar parte de una arquitectura empresarial seria.

EL BAJO CÓDIGO NO SIGNIFICA BAJA ARQUITECTURA
Power Platform puede aportar un gran porcentaje del valor empresarial con rapidez, pero las soluciones empresariales casi siempre contienen requisitos que van más allá de las capacidades estándar de bajo código.Ian explica por qué nunca debe confundirse el bajo código con el no-code, y por qué los principios tradicionales de arquitectura de software siguen siendo importantes al construir con Power Apps, Power Automate, Dataverse, conectores personalizados, APIs y servicios de Azure.

CUANDO POWER PLATFORM SE CONVIERTE EN SOFTWARE EMPRESARIAL
No existe necesariamente una línea clara entre "bajo código" y "empresarial".La complejidad empieza a aumentar cuando las aplicaciones implican múltiples recorridos de usuario, equipos de desarrollo, integraciones, requisitos de seguridad, procesos críticos para el negocio y servicios interconectados.En ese punto, la arquitectura se vuelve esencial.Ian explica por qué las soluciones deben dividirse en funcionalidades y módulos claramente definidos con interfaces limpias, en lugar de convertirse en una gran aplicación interconectada.

SALIR DEL PROBLEMA DEL "DALE AL TOPO" EN EL DESARROLLO
Corriges un error y aparece otro en otro lugar.Ese problema tan conocido en el desarrollo suele ser síntoma de una arquitectura fuertemente acoplada.Ian analiza cómo el diseño modular puede aislar la funcionalidad y reducir dependencias no previstas. Usando la entrega de correo electrónico como ejemplo, explica cómo separar los procesos de negocio de los mecanismos de entrega puede facilitar que las aplicaciones sean más fáciles de probar, mantener, reemplazar y escalar.

BAJO CÓDIGO + CÓDIGO PROFESIONAL = ARQUITECTURA HÍBRIDA
Power Platform no tiene por qué competir con el desarrollo de software tradicional.Un frontend de Power Apps puede representar solo una pequeña parte de una aplicación mucho más grande que utiliza Azure, AWS, GCP, APIs o servicios personalizados.La pregunta arquitectónica importante no es si algo es "bajo código" o "código profesional".Es qué tecnología se adapta mejor a cada funcionalidad.

DESARROLLADORES CIUDADANOS, CREADORES Y ARQUITECTURA
Los desarrolladores ciudadanos aportan algo extremadamente valioso: un profundo conocimiento de los procesos de negocio con los que trabajan cada día.Pero la experiencia empresarial no se traduce automáticamente en una buena arquitectura de aplicaciones.Ian analiza el equilibrio entre dar poder a los creadores e introducir suficiente arquitectura, gobernanza, normalización y revisión técnica para evitar que las soluciones se vuelvan difíciles de mantener.

GOBERNANZA SIN MATAR LA INNOVACIÓN
Muy poca gobernanza genera caos.Demasiada gobernanza genera fricción, y puede empujar a los empleados hacia soluciones alternativas no soportadas, hojas de cálculo, VBA y shadow IT.El reto está en encontrar el nivel adecuado de gobernanza según el riesgo organizativo, la criticidad de la aplicación, los usuarios y el impacto en el negocio.

POWER PLATFORM, APIs Y AZURE
¿Dónde debe residir la lógica de negocio?¿Deben almacenarse los secretos dentro de Power Platform? ¿Cuándo deben Azure Key Vault, Azure Functions o API Management formar parte de la arquitectura?Ian explica por qué la arquitectura siempre debe empezar por el problema que se quiere resolver, en lugar de añadir servicios de Azure simplemente porque estén disponibles.

GIT, CONTROL DE CÓDIGO FUENTE Y CI/CD
A medida que el desarrollo en Power Platform se vuelve más colaborativo, las prácticas de desarrollo tradicionales cobran cada vez más relevancia.La conversación explora Git, repositorios, entornos de desarrollo, pipelines, control de código fuente, aislamiento de funcionalidades, dependencias cruzadas e CI/CD.Puede que no siempre exista un enfoque perfecto para el control de código fuente en Power Platform; a veces el objetivo es elegir la "opción menos mala" para el proyecto.

EL MANUAL DE ARQUITECTURA DE POWER PLATFORM DE IAN

El principio básico de Ian es sencillo:Divide las soluciones en funcionalidades y módulos.Cada funcionalidad debe tener una razón clara de existir y, idealmente, realizar una responsabilidad específica.Después, determina cómo se comunican esas funcionalidades, dónde debe ejecutarse la lógica, cómo deben probarse y qué tecnología se adapta mejor para implementarlas.

LA RONDA RÁPIDA
Mirko somete a Ian a una serie de preguntas rápidas:¿Debe utilizar Dataverse toda aplicación empresarial?¿Puede Power Platform construir aplicaciones de misión crítica?¿Puede Power Automate reemplazar a Logic Apps?¿El bajo código reduce automáticamente la deuda técnica?¿Puede Power Platform reemplazar el desarrollo de aplicaciones tradicional?Y quizá lo más importante: ¿qué debes pedir al visitar Newcastle?

CONCLUSIÓN CLAVE
El bajo código no significa baja arquitectura.A medida que las soluciones de Power Platform crecen, se conectan más y se vuelven más importantes para el negocio, los fundamentos de la ingeniería de software siguen siendo relevantes.La arquitectura importa.El modelado de datos importa.La gobernanza importa.La seguridad importa.El diseño de APIs importa.DevOps importa.Y el desarrollo empresarial exitoso en Power Platform depende cada vez más de entender cómo trabajan juntos el bajo código, el código profesional, Azure, las APIs, la automatización y las prácticas tradicionales de ingeniería de software.

Hazte mecenas de este podcast: https://www.spreaker.com/podcast/m365-fm-a-microsoft-mvp-podcast-by-mirko-peters--6704921/support.