Compartir a través de

Recomendaciones de diseño para lograr simplicidad y eficiencia

  • Artículo

Se aplica a esta recomendación de la lista de verificación de confiabilidad bien diseñada: Power Platform

RE:01 Diseñe su carga de trabajo para alinearla con los objetivos empresariales y evitar complejidades o gastos generales innecesarios. Utilice un enfoque práctico y equilibrado para tomar decisiones de diseño que brinden los resultados deseados. Limite su diseño a las necesidades para reducir ineficiencias y problemas potenciales.

Esta guía describe las recomendaciones para minimizar la complejidad y los gastos generales innecesarios para mantener sus cargas de trabajo simples y eficientes. Elija los mejores componentes para realizar las tareas de carga de trabajo necesarias para optimizar la fiabilidad de su carga de trabajo. Para reducir sus cargas de desarrollo y gestión, aproveche las eficiencias que ofrecen los servicios proporcionados por la plataforma. Este diseño le ayuda a crear una arquitectura de carga de trabajo que sea resistente, repetible, escalable y manejable.

Definiciones

Término Definición
Carga de trabajo Una capacidad discreta o tarea de computación que puede separar lógicamente de otras tareas.

Estrategias clave de diseño

Un principio clave del diseño con fiabilidad es mantener las cosas simples y eficientes. Enfoque el diseño de su carga de trabajo en cumplimiento de los requisitos empresariales para reducir el riesgo de complejidad innecesaria o gastos generales excesivos. Tenga en cuenta las recomendaciones de este artículo para ayudarle a tomar decisiones sobre su diseño para crear una carga de trabajo sencilla, eficiente y fiable. Diferentes cargas de trabajo pueden tener diferentes requisitos de disponibilidad, escalabilidad, coherencia de datos y recuperación ante desastres.

Debe justificar cada decisión de diseño con un requisito empresarial. Este principio de diseño puede parecer obvio, pero es crucial para el diseño de cargas de trabajo. ¿Su carga de trabajo admite millones de usuarios o unos cuantos miles? ¿Hay grandes ráfagas de tráfico o una carga de trabajo constante? ¿Qué nivel de interrupción es aceptable? Los requisitos empresariales impulsan estas consideraciones de diseño.

Compensación: Una solución compleja puede ofrecer más funciones y flexibilidad, pero podría afectar la confiabilidad de la carga de trabajo porque requiere más coordinación, comunicación y gestión de componentes. Por el contrario, una solución más simple podría no satisfacer completamente las expectativas del usuario o podría tener un efecto negativo en la extensibilidad a medida que evoluciona la carga de trabajo.

Ejercicios de diseño colaborativo

Trabajar con partes interesadas para:

  • Defina y asigne un nivel de criticidad a su carga de trabajo y sus componentes. Este ejercicio le ayudará a determinar los componentes necesarios y el mejor enfoque para alcanzar el nivel de resiliencia requerido. Consulte Definir niveles de aplicaciones para obtener más información.

  • Definir requisitos funcionales y no funcionales. Los requisitos funcionales definen las características y el comportamiento del sistema. Los especifica el usuario y se capturan en casos de uso. Los requisitos no funcionales definen el rendimiento y los atributos de calidad del sistema. Asegúrese de comprender los requisitos no funcionales como disponibilidad, cumplimiento, retención/residencia de datos, rendimiento, privacidad, tiempo de recuperación, seguridad y escalabilidad. Estos requisitos influyen en las decisiones de diseño y las opciones tecnológicas.

    A continuación se muestran algunos ejemplos de requisitos funcionales y no funcionales en el contexto de una carga de trabajo que gestiona informes de gastos:

    Requisitos funcionales Requisitos no funcionales
    La carga de trabajo debe permitir a los usuarios iniciar sesión con sus credenciales y acceder únicamente a sus datos personales. La carga de trabajo debe estar disponible como mínimo el 99,9 % del tiempo.
    La carga de trabajo debe incluir un panel que proporcione una descripción general de informes de gastos abiertos, aprobados y rechazados. La carga de trabajo debe cumplir los reglamentos y las normas pertinentes para la protección de datos y la privacidad.
    La carga de trabajo debe admitir operaciones de copia de seguridad y restauración de los datos de la carga de trabajo. La carga de trabajo debe tener un tiempo de respuesta de menos de 5 segundos para la mayoría de las solicitudes de los usuarios.
    La carga de trabajo debe enviar notificaciones a los usuarios y administradores cuando se activen determinados eventos o umbrales. La carga de trabajo debe tener un alto nivel de seguridad y cifrado para los datos en tránsito y en reposo.

    Para obtener más información, consulte el módulo de formación con el título Trabajar con requisitos de Microsoft Power Platform y Dynamics 365.

  • Divida la carga de trabajo en componentes. Durante el proceso de detección y recopilación de requisitos, algunas ideas sobre la solución deberían comenzar a estar claras. Identifique los componentes de la solución que podrían componer la solución propuesta para satisfacer sus requisitos empresariales. Priorice la simplicidad, la eficiencia y la fiabilidad en el diseño. Determine los componentes que necesita para soportar la carga de trabajo. Resalte dónde se pueden utilizar las capacidades listas para usar y dónde puede ser necesario un desarrollo personalizado.

  • Utilice el análisis del modo de falla para identificar puntos únicos de falla y riesgos potenciales. Comprenda claramente la tolerancia al riesgo de su empresa. Para más información, vea Recomendaciones para realizar análisis de modo de error.

  • Defina objetivos de disponibilidad y recuperación para su carga de trabajo para fundamentar las decisiones de arquitectura. Las métricas de negocio incluyen objetivos de nivel de servicio (SLO), contratos de nivel de servicio (SLA), tiempo medio de recuperación (MTTR), tiempo medio entre errores (MTBF), objetivos de tiempo de recuperación (RTO) y objetivos de punto de recuperación (RPO). Defina valores objetivo para estas métricas. Este ejercicio puede requerir compromiso y entendimiento mutuo entre los equipos de tecnología y negocio para garantizar que las metas de cada equipo cumplen los objetivos de negocio y son realistas. Para más información, vea Recomendaciones para definir objetivos de fiabilidad. Power Platform Los SLA proporcionan los compromisos de tiempo de actividad y conectividad. Microsoft Diferentes servicios tienen diferentes SLA y, a veces, las SKU de un servicio tienen diferentes SLA. Para obtener más información, consulte Contratos de nivel de servicio para servicios en línea.

Recomendaciones de diseño adicionales

Puede realizar las siguientes recomendaciones sin la participación de las partes interesadas:

  • Esfuércese por lograr simplicidad y claridad en su diseño. Utilice el nivel adecuado de abstracción y granularidad para sus componentes y servicios. Evite aplicar un diseño excesivo o insuficiente a su solución. Por ejemplo:

    • Si resuelve un requisito de automatización de procesos con Power Automate, desglosar un proceso grande en múltiples flujos de nube más pequeños podría hacer que resulte más difícil de entender, probar y mantener. Por otro lado, mantener todo en un flujo grande podría tener un impacto negativo en el rendimiento y el volumen de llamadas de la API.

    • Si resuelve un requisito del usuario con Power Apps, una aplicación de lienzo monolítica y grande con muchos controles podría tener un impacto negativo en el rendimiento. Dividirla en aplicaciones individuales o páginas personalizadas puede dificultar las pruebas, pero podría tener un impacto positivo significativo en el rendimiento.

  • Anticipar el cambio a lo largo del tiempo, ya sea para corregir errores, implementar nuevas características o tecnologías, o hacer que los sistemas existentes sean más escalables y resilientes.

  • Delegar las preocupaciones transversales a un servicio separado. Minimice la necesidad de duplicar código entre diferentes funciones. Es preferible reutilizar servicios con interfaces bien definidas que puedan ser consumidas fácilmente por diferentes componentes. Por ejemplo, si es necesario realizar un conjunto de operaciones de datos desde distintos lugares, puede mover esta funcionalidad a un complemento con poco código.

  • Evalúe la idoneidad de los patrones y prácticas comunes para sus necesidades. Evite seguir tendencias o recomendaciones que podrían no ser las mejores para su contexto o sus requisitos. Por ejemplo, implementar componentes de código personalizado quizá no sea la mejor opción para todas las aplicaciones, ya que pueden introducir problemas de complejidad, gastos generales y dependencia.

Desarrollar justo el código necesario

Los principios de simplicidad, eficiencia y fiabilidad también se aplican a sus prácticas de desarrollo. Tenga en cuenta estas recomendaciones:

  • Utilice capacidades de la plataforma cuando cumplan sus requisitos de negocio. Por ejemplo:

    • Utilice controles modernos en lugar de desarrollar sus propios componentes de código para lograr un estándar de diseño Fluent 2.
    • Utilice conectores nativos en lugar de desarrollar conectores personalizados para reducir el código personalizado.
    • Utilice respuestas generativas en Microsoft Copilot Studio para permitir que su copiloto encuentre y presente información de múltiples fuentes, internas o externas, sin necesidad de temas creados manualmente.

  • Introduzca sesiones dedicadas de revisión de código como práctica de desarrollo.

  • Implemente un enfoque para identificar código inactivo. Sea escéptico con respecto al código que no cubren sus pruebas automatizadas.

  • Examine el conjunto de aptitudes de su equipo de desarrollo. Se necesita tiempo para aprender una nueva aptitud o adoptar una nueva tecnología.

Examine dónde residen sus datos

Como parte de su diseño arquitectónico, debe considerar cómo almacenar sus datos o cómo recuperarlos para actividades de lectura. Los datos se pueden recuperar y almacenar de diferentes formas:

  • Datos nuevos: si tu aplicación crea datos que aún no existen, como cuando el proceso comercial existente estaba Listo en papel, recomendamos almacenar los datos en Microsoft Dataverse.

  • Leer/escribir desde un sistema existente: si su aplicación necesita recuperar datos de una base de datos o un sistema existente, debe evaluar la mejor manera de acceder a la base de datos o al sistema: usando un conector listo para usar, un conector personalizado o tablas virtuales.

  • Hacer una copia de los datos: En situaciones en las que los datos originales nunca deben modificarse ni sobrescribirse, puede copiar los datos a otro almacén de datos como Dataverse. Esta estrategia mantiene inalterados los datos del sistema original y permite que su aplicación trabaje con ellos. Este escenario es común cuando se trabaja con datos en sistemas de contabilidad y relacionados con ingresos. Debe considerar cómo se copian los datos, con qué frecuencia se actualizan y si es necesario realizar una sincronización bidireccional.

Facilitación de Power Platform

Para obtener consejos prácticos de diseño, consulte los siguientes artículos:

Lista de comprobación de fiabilidad

Consulte el conjunto completo de recomendaciones.

Lista de verificación de confiabilidad