Compartilhar via

Recomendações de design para simplicidade e eficiência

  • Artigo

Aplica-se a esta recomendação da lista de verificação de confiabilidade bem arquitetada: Power Platform

RE:01 Projete sua carga de trabalho para estar alinhada aos objetivos de negócios e evite complexidade ou sobrecarga desnecessárias. Use uma abordagem prática e equilibrada para tomar decisões de design que entreguem os resultados desejados. Restrinja seu design às necessidades para reduzir ineficiências e possíveis problemas.

Este guia descreve as recomendações para minimizar a complexidade e a sobrecarga desnecessárias para manter suas cargas de trabalho simples e eficientes. Escolha os melhores componentes para executar as tarefas de carga de trabalho necessárias para otimizar a confiabilidade de sua carga de trabalho. Para diminuir os encargos de desenvolvimento e gerenciamento, aproveite as eficiências oferecidas pelos serviços fornecidos pela plataforma. Esse design ajuda você a criar uma arquitetura de carga de trabalho resiliente, repetível, escalonável e gerenciável.

Definições

Termo Definição
Carga de trabalho Uma capacidade discreta ou tarefa de computação que você pode separar logicamente de outras tarefas.

Estratégias-chave de design

Um princípio fundamental do design para a confiabilidade é manter as coisas simples e eficientes. Concentre o design de sua carga de trabalho em atender aos requisitos de negócios para reduzir o risco de complexidade desnecessária ou sobrecarga excessiva. Considere as recomendações neste artigo para ajudar você a tomar decisões sobre seu design para criar uma carga de trabalho enxuta, eficiente e confiável. Cargas de trabalho diferentes podem ter requisitos diferentes de disponibilidade, escalabilidade, consistência de dados e recuperação de desastre.

Você deve justificar cada decisão de design com um requisito de negócios. Esse princípio de design pode parecer óbvio, mas é crucial para o design da carga de trabalho. Sua carga de trabalho suporta milhões de usuários ou alguns milhares? Há grandes picos de tráfego ou uma carga de trabalho constante? Qual nível de interrupção é aceitável? Os requisitos de negócios levam a essas considerações de design.

Compensação: Uma solução complexa pode oferecer mais recursos e flexibilidade, mas pode afetar a confiabilidade da carga de trabalho porque exige mais coordenação, comunicação e geranciamento de componentes. Como alternativa, uma solução mais simples pode não atender totalmente às expectativas do usuário ou pode ter um efeito negativo na extensibilidade à medida que a carga de trabalho evolui.

Exercícios de design colaborativo

Trabalhe com os stakeholders para:

  • Defina e atribua um nível de criticidade à sua carga de trabalho e seus componentes. Este exercício ajudará você a determinar os componentes necessários e a melhor abordagem para atingir o nível de resiliência necessário. Consulte Definir camadas de aplicativos para obter mais informações.

  • Defina requisitos funcionais e não funcionais. Os requisitos funcionais definem os recursos e o comportamento do sistema. Eles são especificados pelo usuário e capturados em casos de uso. Os requisitos não funcionais definem os atributos de desempenho e qualidade do sistema. Certifique-se de compreender os requisitos não funcionais, como disponibilidade, conformidade, retenção/residência de dados, desempenho, privacidade, tempo de recuperação, segurança e escalabilidade. Esses requisitos influenciam as decisões de projeto e as escolhas tecnológicas.

    Veja alguns exemplos de requisitos funcionais e não funcionais, no contexto de uma carga de trabalho que lida com relatórios de despesas:

    Requisitos funcionais Requisitos não funcionais
    A carga de trabalho deve permitir que os usuários façam logon com suas credenciais e acessem somente seus dados pessoais. A carga de trabalho deve estar disponível pelo menos 99,9% do tempo.
    A carga de trabalho deve incluir um painel que forneça uma visão geral dos relatórios de despesas abertas, aprovadas e recusadas. A carga de trabalho deve estar em conformidade com os regulamentos e normas relevantes no que diz respeito à proteção e privacidade dos dados.
    A carga de trabalho deve oferecer suporte a operações de backup e restauração para os dados da carga de trabalho. A carga de trabalho deve ter um tempo de resposta inferior a 5 segundos para a maioria das solicitações do usuário.
    A carga de trabalho deve enviar notificações aos usuários e administradores quando determinados eventos ou limites forem desencadeados. A carga de trabalho deve ter um alto nível de segurança e criptografia para os dados em trânsito e em repouso.

    Para obter mais informações, consulte o módulo de treinamento chamado Trabalhar com requisitos para o Microsoft Power Platform e o Dynamics 365.

  • Divida a carga de trabalho em componentes. Durante o processo de descoberta e de coleta de requisitos, algumas ideias de soluções devem começar a ficar claras. Identifique os componentes da solução que podem compor a solução proposta para atender às suas necessidades de negócios. Priorize a simplicidade, a eficiência e a confiabilidade em seu projeto. Determine os componentes que você precisa para oferecer suporte à sua carga de trabalho. Destaque onde os recursos prontos para uso podem ser usados e onde o desenvolvimento personalizado pode ser necessário.

  • Use a análise do modo de falha para identificar pontos únicos de falha e riscos potenciais. Entenda claramente a tolerância do seu negócio ao risco. Para obter mais informações, consulte Recomendações para executar a análise do modo de falha.

  • Defina metas de disponibilidade e recuperação para sua carga de trabalho para informar as decisões de arquitetura. As métricas de negócios incluem SLOs (objetivos de nível de serviço), SLAs (contratos de nível de serviço), MTTR (tempo médio de recuperação), MTBF (tempo médio entre falhas), RTOs (objetivos de tempo de recuperação) e RPOs (objetivos de ponto de recuperação). Defina valores de destino para essas métricas. Este exercício pode exigir compromisso e compreensão mútua entre as equipes de tecnologia e negócios para garantir que as metas de cada equipe atendam aos objetivos de negócios e sejam realistas. Para obter mais informações, consulte Recomendações para a definição de metas de confiabilidade. Power Platform Os SLAs fornecem os Microsoft compromissos de tempo de atividade e conectividade. Serviços diferentes têm SLAs diferentes e, às vezes, SKUs dentro de um serviço têm SLAs diferentes. Para obter mais informações, consulte Contratos de nível de serviço para serviços online.

Recomendações de design adicionais

Você pode executar as seguintes recomendações sem a participação do stakeholder:

  • Procure simplicidade e clareza em seu design. Use o nível apropriado de abstração e granularidade para seus componentes e serviços. Evite a engenharia excessiva ou a subengenharia de sua solução. Por exemplo:

    • Se você resolver um requisito de automação de processos do Power Automate, dividir um processo grande em vários fluxos da nuvem menores poderá dificultar a compreensão, o teste e a manutenção. Por outro lado, manter tudo em um fluxo grande pode ter um impacto negativo no desempenho e no volume de chamadas à API.

    • Se você resolver um requisito voltado para o usuário com o Power Apps, um grande aplicativo de tela monolítico com muitos controles poderá ter um impacto negativo no desempenho. Dividi-lo em aplicativos únicos ou em páginas personalizadas pode dificultar o teste, mas pode ter um significativo impacto positivo no desempenho.

  • Antecipe mudanças ao longo do tempo, seja para corrigir bugs, implementar novos recursos ou tecnologias ou tornar os sistemas existentes mais escaláveis e resilientes.

  • Descarregue preocupações transversais para um serviço separado. Minimize a necessidade de duplicar código em diferentes funções. Prefira reutilizar serviços com interfaces bem definidas que possam ser facilmente consumidas por diferentes componentes. Por exemplo, se um conjunto de operações de dados precisar ser executado a partir de locais diferentes, você poderá mover essa funcionalidade para um plug-in low-code.

  • Avalie a adequação de padrões e práticas comuns às suas necessidades. Evite seguir tendências ou recomendações que possam não ser as melhores para seu contexto ou seus requisitos. Por exemplo, implementar componentes de código personalizado pode não ser a melhor opção para todos os aplicativos porque eles podem introduzir complexidade, sobrecarga e problemas de dependência.

Desenvolva apenas o código suficiente

Os princípios de simplicidade, eficiência e confiabilidade também se aplicam às suas práticas de desenvolvimento. Considere estas recomendações:

  • Use os recursos da plataforma quando eles atenderem aos requisitos do seu negócio. Por exemplo:

    • Use controles modernos em vez de desenvolver seus próprios componentes de código para atingir um padrão de design Fluent 2.
    • Use conectores nativos em vez de desenvolver conectores personalizados para reduzir o código personalizado.
    • Use respostas generativas para permitir que seu copiloto encontre e apresente informações de diversas fontes, internas ou externas, sem tópicos criados manualmente. Microsoft Copilot Studio

  • Introduza sessões dedicadas de revisão de código como uma prática de desenvolvimento.

  • Implemente uma abordagem para identificar código morto. Seja cético em relação ao código que seus testes automatizados não cobrirem.

  • Considere o conjunto de habilidades de sua equipe de desenvolvimento. Leva tempo para adquirir uma nova habilidade ou adotar uma nova tecnologia.

Considere onde os dados estão

Como parte de seu projeto de arquitetura, você precisa considerar como armazenar seus dados ou como recuperar seus dados para atividades de leitura. Os dados podem ser recuperados e armazenados de maneiras diferentes:

  • Novos dados: se seu aplicativo criar dados que ainda não existem, como quando o processo de negócios existente foi feito no papel, recomendamos armazenar os dados em Microsoft Dataverse.

  • Leitura/gravação de um sistema existente: se seu aplicativo precisar recuperar dados de um banco de dados ou sistema existente, você precisará avaliar a melhor maneira de se conectar ao banco de dados ou sistema: usando um conector pronto para uso, um conector personalizado ou tabelas virtuais.

  • Faça uma cópia dos dados: Em situações em que os dados originais nunca devem ser modificados ou substituídos, você pode copiar os dados para outro armazenamento de dados como Dataverse. Essa estratégia mantém os dados do sistema original inalterados, mas permite que seu aplicativo funcione com eles. Esse cenário é comum ao trabalhar com dados em sistemas contábeis e relacionados à receita. Você deve considerar como os dados são copiados, com que frequência são atualizados e se há a necessidade de fazer uma sincronização bidirecional.

Facilitação do Power Platform

Para obter conselhos práticos de design, consulte os seguintes artigos:

Lista de verificação de confiabilidade

Consulte o conjunto completo de recomendações.

Lista de verificação de confiabilidade