Modernização de aplicações com o Power Platform

No atual cenário digital em rápida evolução, as organizações enfrentam o desafio constante de modernizar as respetivas aplicações legadas para acompanhar as necessidades de negócios em constante mudança. A modernização das aplicações é crucial para melhorar a eficiência operacional, melhorar a experiência do cliente e permanecer à frente da concorrência. O Microsoft Power Platform oferece um conjunto abrangente de ferramentas e tecnologias que capacitam as empresas a transformar e modernizar as aplicações de forma rápida e eficaz.

Este documento técnico explora as vantagens, estratégias e melhores práticas da modernização de aplicações com o Microsoft Power Platform. Fornece informações e orientações sobre como a plataforma low-code da Microsoft pode ajudá-lo a garantir o sucesso dos seus esforços de modernização de aplicações como parte da transformação digital da sua organização.

Sugestão

Pode guardar ou imprimir este documento técnico ao selecionar Imprimir no seu browser e, em seguida, ao selecionar Guardar como PDF.

Introdução

As aplicações legadas apresentam muitos desafios para as organizações. Estas aplicações são, muitas vezes, criadas em pilhas de tecnologia e estruturas desatualizadas, tornando-as difíceis de integrar com sistemas e ferramentas modernas. Geralmente, têm limitações de escalabilidade e desempenho que prejudicam a capacidade de uma organização de lidar com as exigências das cargas de trabalho e dos clientes. As aplicações legadas carecem de flexibilidade e agilidade, o que limita a capacidade de se adaptarem rapidamente às necessidades de negócios e à dinâmica do mercado em mudança. As vulnerabilidades de segurança, os elevados custos de manutenção, as capacidades de integração limitadas e o risco de dependência do fornecedor agravam ainda mais os desafios das aplicações legadas. Para superá-los, as organizações precisam de modernizar a infraestrutura de aplicações para tirar partido de novas tecnologias.

As capacidades de desenvolvimento low-code do Microsoft Power Platform possibilitam a criação e implementação de aplicações modernas mais rápidas e com maior eficácia do que nunca. Integre facilmente os seus sistemas e origens de dados existentes para uma troca de dados e colaboração totalmente integradas. Utilize inteligência artificial para melhorar experiências de utilizador, automatizar processos e obter informações valiosas a partir dos seus dados. Quer seja um programador cidadão a dar uns retoques ou um programador profissional a trabalhar numa personalização complexa, pode fomentar a transformação digital de forma intuitiva, rápida e a um custo mais baixo do que com as abordagens tradicionais.

Porquê o Power Platform?

As ferramentas e tecnologias abrangentes que compõem o Power Platform reduzem drasticamente a duração, o custo e os requisitos de desenvolvimento dos projetos de modernização e transformação digital. A sua abordagem low-code reduz — e pode até eliminar — a necessidade de recursos caros de codificação, ciência de dados e de engenharia de IA. Tanto os programadores cidadãos como os programadores profissionais beneficiam. Os programadores cidadãos podem assumir um papel ativo no processo de modernização, ao criar aplicações diretamente com base na respetiva experiência de domínio e ao reduzir a sua dependência das equipas de TI. Os programadores profissionais podem até fornecer soluções complexas em muito menos tempo, libertando-os para passarem para o próximo projeto mais cedo.

Produtos e conceitos do Power Platform

Cada produto na família do Power Platform tem uma área de foco exclusiva. As organizações podem implementar os produtos individualmente ou em combinação para satisfazer os seus requisitos específicos. Os produtos estão interligados e formam um todo totalmente integrado, independentemente de como são combinados.

A tabela a seguir oferece uma descrição geral de alto nível de cada produto do Power Platform.

Produto	Descrição
Power Apps	Crie aplicações personalizadas numa tela intuitiva de arrastar e largar. Com mais de mil conectores, origens de dados e serviços internos e externos estão a apenas alguns cliques de distância. As suas aplicações podem ser executadas num browser, no ambiente de trabalho ou em dispositivos móveis.
Power Automate	Crie fluxos de trabalho para automatizar até mesmo processos complexos. Incorpore origens de dados e serviços internos e externos usando conectores personalizados e incorporados. Use a automatização de processos digitais (DPA) quando as aplicações tiverem uma interface de programação de aplicações (API). Utilize a automatização robótica de processos (RPA) para automatizar tarefas repetitivas realizadas num browser ou numa aplicação de ambiente de trabalho. Acione fluxos de trabalho para execução quando ocorrem eventos noutros sistemas e serviços ou agende-os para execução numa hora específica.
Copilot Studio	Criação de agentes de conversação utilizando uma interface gráfica no-code. Pode implementar agentes em vários canais, incluindo sites, aplicações móveis e plataformas de mensagens, como o Microsoft Teams. A criação assistida por IA pode acelerar a criação de tópicos. As respostas generativas podem encontrar e apresentar informações de várias origens sem exigir a criação de tópicos.
Power BI	Arraste gráficos, tabelas e outros elementos visuais para uma tela para criar facilmente relatórios sofisticados que revelam informações contidas nos seus dados. Inclua machine learning automatizado para modelagem preditiva e visualizações de IA com árvores de decomposição para desagregamentos detalhados de análise de causa raiz. Explore os seus dados ao fazer perguntas em linguagem natural num formato de perguntas e respostas simples.
Power Pages	Crie rapidamente sites atraentes e condicionados por dados numa plataforma de software como serviço (SaaS) segura, de nível empresarial e low-code. Com modelos ricos e personalizáveis e uma experiência visual fluida, criar, alojar e administrar sites de negócios modernos direcionados para o exterior é mais fácil.

A família de produtos do Power Platform baseia-se em algumas capacidades e conceitos de suporte. A tabela a seguir descreve os mais importantes a serem compreendidos.

Conceito	Descrição
Power Fx	O Power Fx é uma linguagem low-code de open source inspirada por fórmulas do Excel. Com um tipo forte, declarativo e funcional, com lógica imperativa e gestão de estado, todos expressos em texto amigável para humanos, o Power Fx facilita as tarefas de programação comuns para programadores cidadãos e programadores profissionais. Suporta todo o espetro de programação de sem código para aqueles que nunca programaram antes para "código pro" para profissionais experientes, o que permite que diversas equipas colaborem e poupem tempo e despesas.
Conectores	Os conectores são vitais para permitir que a codificação low-code e tradicional trabalhem juntas para fornecerem aplicações modernas. Os conectores são um wrapper à volta de uma API que permite que o Power Apps e o Power Automate utilizem origens de dados e serviços internos e externos. Mais de mil conectores pré-criados estão disponíveis e pode criar o seu para qualquer API RESTful. A definição do conector inclui os metadados necessários para facilitar o consumo da API por aplicações low-code.
Dataverse	O Dataverse é um arquivo de dados híbrido em escala de cloud baseado em serviços de gestão de dados do Azure, mas é mais do que uma base de dados. É a plataforma de dados subjacente para o Dynamics 365 e o Power Platform, com lógica do lado do servidor na forma de fluxos de trabalho e de plug-ins, regras de negócios e fluxos de processo, um modelo de segurança altamente sofisticado e uma plataforma de desenvolvimento extensível com suporte integrado para aplicações multilingues e multimoedas. As aplicações podem ser criadas rapidamente a partir do modelo de dados, tornando-o uma das formas mais rápidas de implementar uma solução de formulário sobre dados.
AI Builder	O AI Builder facilita a utilização de inteligência artificial no Power Apps e no Power Automate para encontrar informações nos seus dados, automatizar processos e tornar as suas aplicações mais produtivas. Com o AI Builder, não precisa de programação ou de capacidades de ciência de dados para ao poder da IA. Os modelos pré-criados e personalizáveis estão prontos para utilização imediata para muitos cenários de negócios comuns e pode criar os seus próprios modelos para satisfazer uma necessidade de negócios específica.
Copilot	A assistência de IA do Copilot torna os utilizadores e programadores, cidadãos ou profissionais, do Power Platform mais produtivos, permitindo-lhes passar mais tempo nas melhores partes dos seus trabalhos e menos tempo em tarefas mundanas. Descreva o seu cenário de negócios ao Copilot no Power Automate e este pode transformar a sua descrição num fluxo de trabalho automatizado. Diga ao Copilot no Power Apps o que quer fazer ou que informações quer ver e ele pode criar uma aplicação para isso. O Copilot configura ligações, cria e preenche tabelas, gera ecrãs e até oferece sugestões para melhorar o seu fluxo ou aplicação. As suas aplicações terão experiências com tecnologia de copiloto incorporadas desde o primeiro ecrã, para que os utilizadores possam descobrir informações através de conversas.
Ambientes e soluções	Os ambientes são limites que contêm e facilitam a gestão e a proteção de recursos do Power Platform. Também são usados na gestão do ciclo de vida de aplicações (ALM), no qual as soluções são desenvolvidas e testadas em ambientes separados antes de serem implementadas num ambiente de produção. As soluções são personalizações e extensões do Power Platform empacotadas. Uma solução pode incluir aplicações, fluxos, tabelas, gráficos, dashboards, conectores e outros componentes de que a personalização ou extensão necessita. As soluções podem ser desenvolvidas, testadas e implementadas em produção em ambientes separados como parte da política ALM de uma organização. Pode exportar soluções para partilhá-las com outros utilizadores ou organizações e importar soluções de outras pessoas. As solução são geridas ou não geridas. As soluções não geridas são usadas para desenvolvimento e testes. As soluções geridas são usadas para implementação e distribuição em produção.

Principais benefícios do Power Platform para modernização de aplicações

Os benefícios de modernizar aplicações usando o Microsoft Power Platform expandem-se para além do valor comercial inicial de ter uma solução que usa tecnologias modernas.

• Custos mais baixos. As organizações podem poupar dinheiro no desenvolvimento e manutenção de aplicações. Um estudo encomendado pela Forrester Consulting descobriu que as organizações que usam o Power Platform podem ver uma redução de 45 porcento nos custos de desenvolvimento de aplicações e obter um retorno de 140% sobre o seu investimento.

• Expanda o conjunto de recursos e elimine estrangulamentos. Os programadores profissionais, os cientistas de dados e os engenheiros de IA são altamente remunerados e têm muita procura. As pequenas e médias organizações, muitas vezes, não se dão ao luxo de ter competências internas em codificação e a terceirização é cara. O Power Platform de low-code é mais acessível por um conjunto maior de recursos. Especialistas no assunto e colaboradores com experiência em processos de negócios podem ajudar a acelerar os esforços de modernização, mesmo que nunca tenham escrito uma linha de código.

• Crie a carroça, não a roda. O desenvolvimento de software tradicional começa sempre de novo, reinventando a roda em todos os novos projetos. Tendo produtos low-code, intuitivos e fáceis do Power Platform como rodas, pode concentrar-se na criação de uma carroça melhor — o que melhora os seus processos de negócios — e tire partido dos benefícios dos seus esforços de modernização mais cedo.

• Reduzir a dívida técnica. O custo — tanto financeiro como em oportunidades perdidas — de atualizar a versão de soluções de software "rápidas e sujas" e manter a infraestrutura legada é alto. O Power Platform reduz esta dívida técnica, tornando mais fácil e barato criar soluções logo da primeira vez, simplificando a integração e a governação de dados com um modelo de dados e conectores comuns, ao fornecer uma plataforma centralizada para gerir soluções e suportar a melhoria contínua com análises e IA.

• Melhore a segurança e garanta a conformidade. Todos os produtos do Power Platform incluem segurança, conformidade e governação totalmente integradas e de nível empresarial de origem, a começar pelos ambientes em que são executados. Os Ambientes Geridos são um conjunto de ferramentas que permitem aos administradores gerir o Power Platform em escala, com mais controlo e menos esforço. Entre outras capacidades, pode limitar quem pode partilhar que fluxos e aplicações, e com quem, bem como usar políticas para restringir os conectores que os criadores podem usar. Os modelos de segurança de dados nativos e flexíveis significam que cada aplicação não precisa de criar o seu próprio.

• Modernização constante. Quanto mais significativas forem as aplicações que pretende modernizar, menor é a probabilidade de que queira substituí-las todas de uma vez. Uma abordagem low-code é ideal para a criação de soluções em incrementos geríveis.

• Integrar aplicações legadas. As aplicações mais antigas, geralmente, não têm APIs. As capacidades de RPA do Power Platform podem automatizar aplicações clássicas e incluí-las nos seus novos processos de negócios modernos. A RPA também pode ser útil na modernização incremental de aplicações grandes e complexas.

• Inove sem gastar mais. As capacidades do Power Platform continuam a melhorar. As aplicações incorporadas na plataforma beneficiam de inovações da Microsoft sem mais custos para si.

• Aumente a produtividade dos trabalhadores num local de trabalho moderno. O Power Platform faz parte do local de trabalho moderno da Microsoft. As aplicações modernizadas na plataforma podem tirar partidos das capacidades do Microsoft 365, incluindo experiências móveis cativantes e colaboração fácil e intuitiva. A IA de ponta, como o Copilot, o AI Builder e caraterísticas que serão anunciadas em breve, tornam os utilizadores e programadores mais produtivos com menos frustração e curvas de aprendizagem menores.

Inovação para o trabalhador de primeira linha

Os trabalhadores de primeira linha precisam de aplicações modernas que possam usar em qualquer dispositivo, em qualquer lugar em que estejam a trabalhar. Precisam ter acesso a informações em tempo real para tomar melhores decisões mais rapidamente. Precisam de colaborar com colegas de trabalho e com a gestão para manter tudo a funcionar sem problemas. Quando a American Airlines decidiu modernizar aspetos das suas operações, conseguiram tudo isso e muito mais.

Em parceria com a Microsoft, a American Airlines criou o ConnectMe, uma aplicação Microsoft Teams baseada no Power Apps e no Azure. Ao utilizar a aplicação em qualquer dispositivo móvel, as equipas de primeira linha têm as principais informações de chegada, embarque, bagagem e portão na ponta dos dedos em tempo real, o que simplifica as operações em terra, acelera os tempos de viragem dos aviões e torna as viagens uma experiência mais agradável para os clientes. Obtenha mais informações sobre a transformação da companhia aérea.

Capacitação da IA para os profissionais do conhecimento

Os profissionais do conhecimento estão a nadar num oceano de dados e, por demasiadas vezes, sentem que estão a afogar-se. Quase todas as aplicações recolhem dados. Poucas ajudam os utilizadores a compreender os dados que recolhem, muito menos a extrair informações que possam ajudar os trabalhadores a fazer melhor o seu trabalho. As capacidades de IA podem ser adicionados às aplicações como parte da modernização, não apenas ao automatizar a recolha e a análise de dados, mas também ao facilitar a identificação de padrões e tendências pelos profissionais do conhecimento. A análise preditiva pode usar modelos de IA para prever resultados futuros com base em dados históricos com alta precisão, o que permite que os líderes efetuem planos com confiança. As aplicações modernizadas podem incluir IA de copiloto, a agir como um parceiro para gerar conteúdo em contexto, resumindo entrevistas, elaborando mensagens de marketing e vendas direcionadas e até mesmo oferecendo informações úteis em tempo real enquanto um representante de suporte ao cliente ou vendedor está ao telefone com um cliente.

Um percurso incremental para modernizar aplicações legadas

Se a sua organização for como a maioria, tem uma lista crescente de aplicações desatualizadas que beneficiariam da modernização. As aplicações legadas, normalmente, usam tecnologia obsoleta e são criadas em infraestrutura — hardware e software — que já não é suportada. Muitas vezes, apenas alguns colaboradores, geralmente os que estão perto da aposentadoria, sabem como trabalham. Os novos colaboradores não querem nada com elas porque não podem usar as ferramentas modernas a que estão habituados ou com as quais querem trabalhar. Mantê-las, quanto mais atualizá-las, requer escalar uma montanha de dívidas técnicas que aumentam quanto mais sobe. Anos, talvez décadas, de manutenção de correções resultam numa base de código que ninguém ousa tocar — especialmente, quando partes importantes do negócio dependem dela.

Muitas vezes, as organizações não conseguem substituir facilmente estas aplicações de uma só vez. Em vez disso, embarcam num percurso de modernização incremental. Uma abordagem incremental maximiza os benefícios da modernização e, ao mesmo tempo, mitiga alguns dos riscos de um esforço único de modernização.

Opções para modernizar aplicações

A modernização nem sempre significa reconstruir uma aplicação legada do zero. Outras opções são retirá-la, substituí-la, realojá-la, refatorizá-la e voltar a arquitetá-la.

A tabela a seguir descreve cada opção, a fase da ALM quando for mais apropriado e os controlador que podem influenciar a seleção.

Fim de vida

Migração

Modernização

Extinguir

Substituir

Voltar a alojar novamente

Refatorizar

Voltar a arquitetar

Reconstruir

Descrição

Remover aplicação

Substituir aplicação por SaaS ou outra aplicação

Voltar a implementar tal como está na cloud

Otimizar código existente

Mudar o código para uma nova arquitetura de aplicação ou quebrá-lo em microsserviços

Reescrever a aplicação de raiz com âmbito e especificações originais

Controladores

Já não são necessários

Reduzir despesas

Reduzir despesas de capital

Tirar partido das tecnologias mais recentes

Reduzir despesas de capital

Recuperar armazenamento de dados

ROI de cloud rápido

Atualizações mais rápidas e curtas

Código mais portátil

Maior eficiência da cloud em recursos, velocidade e custo

Melhorar o desempenho

Reduzir a dívida técnica

Melhorar a escalabilidade, a fiabilidade e a capacidade de manutenção

Facilitar a adoção de novas capacidades de cloud

Misturar pilhas de tecnologia

Acelerar a inovação

Acelerar o desenvolvimento

Reduzir despesas operacionais

Tecnologias da Microsoft

Power Apps

Dynamics 365

IaaS do Azure

VMWare do Azure

Power Platform

Contentores

PaaS do Azure

Power Platform

PaaS do Azure

Microsserviços sem servidor

Power Platform

PaaS do Azure

Microsserviços sem servidor

A tabela a seguir sugere formas em que uma abordagem low-code pode ser aplicada a cada uma das opções de modernização de aplicações.

Opção	Descrição
Voltar a alojar novamente	O realojamento move uma aplicação tal como está de um ambiente mais antigo para um mais recente. Uma abordagem low-code não se aplica diretamente, mas o realojamento pode ser o primeiro passo antes de aplicar outras estratégias que incluiriam soluções low-code.
Refatorizar ou voltar a arquitetar	A refatorização ajusta o código para que as aplicações possam obter o benefício máximo de um ambiente de cloud primeiro. Voltar a arquitetar modifica significativamente o código. Pode incluir o encapsulamento da lógica existente ao movê-la para uma API que pode ser exposta a soluções low-code através de um conector.
Substituir ou reconstruir	A substituição troca uma aplicação por uma diferente. A reconstrução recria uma aplicação a partir do zero. Esta opção, geralmente, ocorre quando uma abordagem low-code alcança os melhores resultados de negócio. Começar com uma aplicação do Dynamics 365 ou do Microsoft AppSource pode ajudar a iniciar a modernização quando o caso de utilização corresponde a uma capacidade pré-criada. As organizações podem então utilizar componentes do Power Platform para personalizar a aplicação de acordo com as suas necessidades exclusivas.

A abordagem low-code do Power Platform tem o potencial de oferecer muito mais do que apenas mais uma ferramenta de desenvolvimento. Tornar o low-code parte da sua estratégia de aplicações modernas também pode estabelecer uma base para capacitar não programadores, como especialistas no assunto, a participar do seu esforço de modernização. As organizações descobriram que estabelecer um Centro de Excelência (CoE) em torno do Power Platform e usar ferramentas, como o Kit de Iniciação CoE para criar diretrizes e governação, ajuda os utilizadores a criar aplicações e automatizações low-code com sucesso e garante que ativos, como APIs e componentes, possam ser reutilizados. O low-code pode acelerar o desenvolvimento de aplicações e ajudar as organizações a extrair valor dos seus dados mais rapidamente, independentemente de onde estão localizados. Na verdade, muitas organizações decidem integrar uma mentalidade low-code na sua cultura.

Um guia para o seu percurso de modernização

É fácil ficar sobrecarregado quando começa a pensar em modernizar aplicações legadas. Um guia pode ajudar a planear o seu percurso e mantê-lo no sempre no caminho certo. Um bom lugar para começar é com estes três passos, considerando cada um com uma mentalidade low-code.

1. Planeamento. Pense cuidadosamente nos seus objetivos para modernizar uma aplicação legada e defina a sua estratégia para os alcançar. Tenha uma declaração clara do problema que pretende que a modernização resolva. Este é o momento de avaliar as aplicação e os ambientes em relação ao que não está a funcionar, o que está a funcionar, mas pode ser melhorado e, o mais importante, que valor, para a empresa ou para os utilizadores, resulta de quaisquer alterações. Avalie cada oportunidade de modernização relativamente ao seu potencial para tirar partido de uma abordagem low-code. Dê prioridade a oportunidades que incorporem soluções low-code. Use o Avaliador de Estratégias de Adoção da Cloud para criar um case de negócio para a modernização de aplicações.

2. Implementação. Modernize as suas aplicações não apenas incrementalmente, mas iterativamente. Uma abordagem iterativa dá às organizações a flexibilidade de alterar o âmbito ou a estratégia do projeto, conforme necessário. As soluções low-code do Power Platform podem ser desenvolvidas e testadas mais rapidamente do que as aplicações desenvolvidas tradicionalmente, e a implementação em Ambientes Geridos requer apenas alguns passos. Embora o low-code exija menor aquisição de novas competências do que a codificação tradicional, certifique-se de que os seus colaboradores estão adequadamente treinados em como trabalhar como equipas de fusão, que combinam recursos low-code e tradicionais.

3. Operações. A modernização de aplicações não se limita à implementação. Com uma abordagem low-code e de cloud primeiro, pode utilizar serviços e ferramentas da plataforma cloud para proteger, governar, gerir e otimizar as suas aplicações.

Avaliar oportunidades para soluções low-code

As organizações usam vários métodos, desde revisão informal até árvores de decisão detalhadas, para determinar se uma abordagem low-code é a maneira certa de modernizar uma aplicação legada. A coisa mais importante a considerar é que o low-code não é uma decisão de tudo ou nada. É comum criar parte de uma aplicação a partir de componentes do Power Platform e parte dela a partir de componentes desenvolvidos com técnicas tradicionais de codificação.

Para avaliar uma aplicação, recomendamos que comece por determinar se ainda é necessária e útil ou se deve ser aposentada. Se decidir que ainda é necessária, avalie se uma solução low-code pode substituir a aplicação como um todo. Se a aplicação inteira não for adequada para uma substituição de low-code, avalie se uma ou mais cargas de trabalho ou componentes da aplicação podem ser. Pode achar que uma solução low-code expandida com código desenvolvido tradicionalmente fornece o melhor dos dois mundos.

Por exemplo, se determinar que uma aplicação não é adequada porque o Power Apps não tem um controlo necessário, pode usar o Power Apps component framework (PCF) e código tradicional para criar um controlo personalizado. Outro exemplo é uma aplicação com lógica complexa. Pode centralizar a lógica numa API que a que o Power Apps pode aceder usando um conector personalizado. Em ambos os exemplos, a extensibilidade do Power Platform permitiu que a maior parte da aplicação fosse criada com componentes low-code, preenchendo as lacunas com o código desenvolvido tradicionalmente.

NSure.com, uma plataforma proprietária de compras de seguros online, oferece um exemplo do mundo real. O lançamento inicial da empresa contou com os serviços Angular, Xamarin e Azure desenvolvidos tradicionalmente. Ao adicionar o Power Platform e o Dynamics 365, a NSure.com criou uma solução de próxima geração que utilizam técnicas de codificação low-code e tradicionais, como ilustra o diagrama a seguir. Obtenha mais informações sobre o percurso da empresa.

Tão importante quanto identificar oportunidades de low-code é reconhecer quando uma abordagem low-code não é a correta. As tabelas a seguir descrevem casos de utilização que, geralmente, não são adequados para soluções low-code. As organizações enfrentam desafios diferentes no front-end e no back-end, por isso, vamos considerá-los separadamente.

Cenários de front-end que não se adequam a uma abordagem low-code

Cenário	Desafio
O dispositivo do utilizador não é compatível	O Power Platform reconhece dispositivos móveis e dispositivos especializados, como leitores de código de barras. Dispositivos que dependem de APIs ou controladores específicos podem não ser suportados e exigiriam uma abordagem mais tradicional.
Grande volume de dados do lado do cliente	A experiência de utilizador em algumas aplicações requer grandes quantidades de dados, um desafio para qualquer tecnologia, não apenas low-code. Transferir e processar muitos dados pode sobrecarregar os sistemas de back-end e degradar o desempenho da aplicação e do dispositivo em que é executada. Os utilizadores não são tão produtivos quando são forçados a navegar por muitos dados. Antes de recorrer aos métodos de codificação tradicionais para lidar com a carga, explore se a filtragem e a navegação adequadas podem fornecer uma melhor experiência de utilizador.
Requisitos offline complexos	As aplicações que precisam de trabalhar em locais onde a conectividade é fraca ou inexistente podem ser difíceis de implementar e suportar, quer usem low-code ou código tradicional. O Power Apps oferece capacidade básica para cenários offline simples. Por exemplo, uma aplicação que captura oportunidades potenciais durante um evento e as carrega numa base de dados de marketing após o evento funcionaria bem. Para aplicações que exigem arquivos e imagens, conectores que não sejam do Dataverse ou resolução de conflitos complexos, deve considerar técnicas de código tradicionais.

Cenários de back-end que não se adequam a uma abordagem low-code

Cenário	Desafio
Dados de alta velocidade	A importação de milhões de linhas de dados como parte de migrações e eventos semelhantes é, geralmente, suportada. No entanto, as cargas de trabalho que envolvem o processamento de milhões de linhas de dados de hora a hora ou diariamente devem ser sujeitas a mais avaliação. Por exemplo, recolher grandes volumes de telemetria da Internet das Coisas (IoT) para o Dataverse não faria sentido. Em vez disso, os serviços cloud do Azure podem ser usados para recolher e analisar os dados e sinais relevantes adicionados ao Dataverse para acionar ações na aplicação. As aplicações que envolvem um grande volume de atualizações aos dados do Dataverse regularmente podem exigir a assistência do código tradicional para dimensionar as atualizações.
Cargas de trabalho em fundo com lógica complexa	Cargas de trabalho em fundo que envolvem lógica complexa ou um grande volume de chamadas à API podem não ser adequadas para uma solução low-code. Em vez disso, a lógica pode ser centralizada numa API que uma solução low-code pode chamar.
APIs que usam protocolos não RESTful	Os conectores do Power Platform suportam apenas APIs REST. Se precisar de se ligar a outra API de estilo, como SOAP ou gRPC, forneça a sua própria API REST que comunique com a incompatível.

Recomendamos que acompanhe as vagas de versão do Power Platform, porque continuam a fechar lacunas no que pode fazer com soluções low-code. Criar uma prova de conceito low-code é uma boa maneira de determinar se o seu cenário é adequado.

Dar prioridade as oportunidades low-code

Ao avaliar o seu portfólio de aplicações, não é suficiente identificar bons candidatos para a transformação low-code. A sua equipa tem de lhes dar prioridade para maximizar o sucesso dos seus esforços de modernização.

A atribuição de prioridades deve considerar os seguintes fatores:

• A maturidade low-code da sua organização
• A complexidade da oportunidade
• ROI para a organização, utilizadores e TI
• Tempo para o valor

Ser realista sobre as capacidades low-code da sua organização pode ajudar a escolher uma oportunidade que desafie a sua equipa a crescer, mas não sobrecarregá-la para falhar. Não tem de escolher a aplicação mais simples sem quaisquer desafios. Uma aplicação ideal ofereceria algumas oportunidades para explorar como combinar código tradicional com soluções low-code.

As aplicações com integração complexa com outros sistemas, muitas vezes, não são o melhor lugar para começar. Tentar lidar com aplicações que são muito grandes ou muito complexas pode levar à frustração e ao fracasso. Evite candidatos low-code questionáveis. Guarde-os para depois de a sua equipa concluir algumas modernizações bem-sucedidas.

Ao modernizar uma aplicação grande e monolítica, considere se pode modernizar incrementalmente pequenas partes dela. Aplicações monolíticas costumavam ser comuns. Agora, são mais comuns aplicações menores, focadas em funções ou em tarefas. Permitem o desenvolvimento incremental e melhorias, bem como dimensionamento das equipas que as criam.

As primeiras modernizações são importantes porque permitem que a organização veja o impacto das soluções low-code. Avaliar os benefícios e os riscos para os intervenientes de uma aplicação é importante quando está a atribuir prioridades a oportunidades. Escolher uma aplicação com que ninguém se importa ou que tenha um impacto baixo na organização não será a melhor demonstração das vantagens de uma solução low-code.

A adoção da aplicação modernizada pelos utilizadores é importante. Os utilizadores precisam de sentir que a nova aplicação low-code se encaixa juntamente com as restantes aplicações que utilizam. Outro risco para a adoção é o grau de personalização a que estão habituados. Se esperam uma experiência altamente personalizada, podem estar menos inclinados a adotar uma solução low-code que pareça menos pessoal.

Organizar e melhorar as competências das suas equipas

As organizações que são bem-sucedidas na modernização das respetivas aplicações legadas não atribuem apenas um projeto de modernização a uma equipa de programadores de código tradicionais e esperam que tenham sucesso. É importante dar à sua equipa o conhecimento e a confiança no desenvolvimento low-code de que precisa para concluir com sucesso um esforço de modernização.

Uma equipa de recursos low-code trabalhando ao lado de recursos de código tradicionais é chamada de equipa de fusão. As equipes de fusão são projetadas para incentivar a colaboração, treinando ambos os tipos de recursos na integração de soluções low-code com o código tradicional. Um arquiteto de soluções estabelece como a solução é arquitetada entre low-code e código tradicional.

Embora seja fácil atribuir todo o trabalho a programadores tradicionais, os esforços de modernização low-code são boas oportunidades para expandir a equipa do projeto. Muitos utilizadores de empresa criam excelentes recursos low-code. Podem acelerar o trabalho da equipa porque já compreendem o problema do negócio. Só precisam de saber como concluir os tipos de trabalho low-code que a equipa recebe e estar familiarizados com testes e procedimentos de ALM. Isso pode significar aprender a criar aplicações no Power Apps ou fluxos de trabalho no Power Automate. Também devem compreender o que os codificadores tradicionais podem desenvolver para facilitar os seus esforços de low-code. Isto não significa que precisam de saber como escrever código tradicional.

Os recursos de código tradicionais precisam de ter um conhecimento básico de abordagens low-code e de como diferem do código que normalmente escrevem. Mais importante ainda, precisam de conhecer as opções de extensibilidade de soluções low-code. Devem estar confortáveis em criar uma aplicação ou fluxo de teste que use o código que escrevem para garantir que funciona e estar prontos para suportar recursos low-code no consumo dos seus ativos de extensibilidade.

Os recursos de low-code e de código tradicional precisam de entender onde as soluções de low-code e de código tradicional começam e terminam e onde se cruzam.

Recolher requisitos

Pode descobrir que tem aplicações com uma década ou mais e não documentadas. Podem exigir conhecimento de engenharia reversa ou de utilizador de empresa para recriar. É importante lembrar que, embora uma abordagem low-code seja eficiente, não torna a recolha de requisitos e conhecimento de processos de negócios mais rápida nem torna os requisitos complexos menos complexos. Muitas vezes, há uma expetativa irrealista de que uma equipa que está a modernizar uma aplicação realiza tanto quanto uma equipa que está a criar uma nova aplicação com low-code. Estabeleça as expetativas da sua organização com estes desafios em mente.

Duas abordagens podem ajudar a acelerar o esforço de obter conhecimento sobre uma aplicação legada. Primeiro, expanda a equipa para incluir utilizadores de empresa com conhecimento de domínio. Em segundo lugar, concentre-se em compreender o processo de negócio e o resultado desejado, em vez de documentar como é implementado no sistema legado. A exceção a isto é se a aplicação legada exige lógica especializada que execute regras de negócio que tem de seguir.

Evite trabalhar contra abordagens low-code

As organizações que são novas na modernização de aplicações com soluções low-code, muitas vezes, cometem o erro de desenvolver low-code da mesma forma que desenvolvem código tradicional. Por exemplo, uma organização pode aplicar normas de UX escritas para aplicações Angular na respetiva primeira implementação do Power Apps. A equipa do projeto gastaria tempo desnecessário a tentar satisfazer as normas que foram projetadas para as capacidades da estrutura Angular e não para as necessidades de negócio.

As equipas que estão habituadas a trabalhar com código tradicional podem tentar minimizar o low-code. Por exemplo, em vez de usar controlos do Power Apps, a equipa poderia criar uma aplicação a partir de controlos do Power Apps component framework para evitar usar low-code tanto quanto possível. É melhor para as equipas chegarem o mais longe possível com low-code até atingirem bloqueadores que não podem ser contornados. As equipas que aprendem a tirar partido das capacidades da plataforma são mais bem-sucedidas na obtenção do máximo benefício do low-code. O low-code continua a tornar-se mais capaz de assumir o que costumava ser possível apenas com o código tradicional. Um desafio comum no passado era ficar preso porque o low-code não conseguia replicar algumas funcionalidades necessárias. O Power Platform aborda este desafio com opções de extensibilidade que permitem que, principalmente, aplicações low-code incorporem componentes especializados escritos em código tradicional quando necessário.

As abordagens low-code podem desempenhar um papel importante nas suas estratégias de modernização. Os melhores resultados exigem uma instrução clara do problema que o esforço de modernização pretende resolver, planeamento, a equipa que vai para além das funções predefinidas, a preparação e a atribuição de prioridades. Fazer ajustes apropriados às suas normas e processos, se necessário, também ajuda as organizações a perceber todo o potencial do low-code. A modernização feita corretamente deve melhorar o valor comercial geral das aplicações modernizadas.

As plataformas low-code evoluíram rapidamente nos últimos anos. Embora sempre tenham sido boas a suportar cenários de produtividade individual, o foco recente tem sido nas capacidades empresariais. As organizações estão a criar aplicações low-code que suportam o local de trabalho moderno, incluindo o trabalho híbrido (remoto e no local) e a consequente necessidade de formas de incentivar a colaboração. As plataformas low-code, como o Power Platform, agora podem ser dimensionadas para lidar com aplicações das quais todos os utilizadores de uma organização podem depender e que podem ser integradas com modelos de segurança empresariais. Ao ligar capacidades de low-code à infraestrutura empresarial, pode usar técnicas de low-code lado a lado com métodos tradicionais. O low-code abstrai grande parte da complexidade e permite que um conjunto mais amplo de pessoas participe na criação de soluções.

Compreender a estrutura de custos de uma abordagem low-code

Uma pergunta comum que as organizações fazem quando consideram um esforço de modernização é quanto custará? Embora uma discussão completa sobre licenciamento e análise de custos esteja além do âmbito deste artigo, podemos explorar estes tópicos a um nível alto.

Os produtos do Power Platform são produtos licenciados. Pode licenciá-los individualmente para satisfazer os seus requisitos. Pode configurar a faturação do Azure para pay as you go, o que permite a utilização sem um compromisso de licença inicial ou compra e inclui alguma utilização do Power Automate na aplicação. O Power Automate também tem licenciamento por utilizador e por fluxo para trabalho autónomo. O licenciamento por fluxo funciona bem quando tem automatização que beneficia toda a organização. Licenças do Power Apps podem ser por utilizador ou por aplicação. Os sites do Power Pages são licenciados por utilizador, site ou mês. É necessária uma licença adicional para sites autenticados. Todas as licenças incluem o uso de conectores e o Dataverse, com a opção de licenciar mais armazenamento e pedidos de API para cenários de alto volume.

Todos os produtos do Power Platform têm preços por volume que, geralmente, se aplicam aos esforços de modernização de aplicações e devem ser avaliados para a estratégia exclusiva de cada organização.

Ao avaliar o custo do low-code em comparação com o código tradicional, é essencial perceber que a comparação não é de maçãs para maçãs. Com o low-code, paga pela mão de obra para implementar um processo de negócio exclusivo no produto low-code e para a licença do produto o utilizar. Em geral, a licença inclui várias aplicações e automatizações, sem que cada um requeira mais custo.

Com as abordagens de codificação tradicionais, paga pela mão de obra para implementar um processo de negócio exclusivo no código, pela mão de obra para criar a infraestrutura da aplicação e pelos serviços de cloud necessários para suportar a aplicação.

Todas as soluções, sejam low-code ou tradicionais, requerem manutenção e cuidado contínuos. No entanto, as soluções low-code requerem menos recursos para tal. Também incorrem em menos dívidas técnicas porque a infraestrutura da aplicação é fornecida pela plataforma.

Em comparação com uma aplicação totalmente personalizada que não é criada sobre uma plataforma low-code, uma solução low-code tem um custo mais previsível. Evite cair na armadilha de comparar o licenciamento de low-code com o custo inicial da implementação de código tradicional.

Um olhar sobre o Power Platform

Os componentes do Power Platform são criados nos mesmos serviços de cloud do Microsoft Azure que estão disponíveis se usar métodos de codificação tradicionais. A integração destes componentes entre si e com caraterísticas de segurança, escalabilidade e recuperação após desastre foi feita para si.

Dentro do Dataverse

O Dataverse tem tecnologia de mais de 25 serviços do Azure totalmente geridos, como Funções, Balanceador de Carga, Serviços Cognitivos, Synapse, DevOps, Active Directory e Microsoft Purview. As capacidades incorporadas incluem segurança abrangente, análises poderosas, IA, lógica de negócios avançada e processamento de eventos, modelação de dados e integração com o Dynamics 365, o Microsoft 365, o Azure e muito mais. Todas estas capacidades são criadas numa camada de armazenamento poliglota do Dataverse, que é baseada no DB SQL do Azure (para dados relacionais), Azure Cosmos DB (para NoSQL), Armazenamento de Blobs do Azure (para ficheiros) e Azure Data Lake Storage Gen 2 (para análise em larga escala e retenção de dados a longo prazo). Estão disponíveis para uso transparente nos componentes low-code do Power Platform e através da API REST do Dataverse.

A elevada disponibilidade e a continuidade de negócio e recuperação após desastre (BCDR) são importantes para aplicações críticas para o negócio. O Dataverse maximiza a disponibilidade com os serviços de fiabilidade do Azure. A replicação de servidores principais e secundários é síncrona, com uma malha por baixo que pode detetar falhas e escolher um novo servidor principal que segue protocolos de correção. As ativações pós-falha de elevada disponibilidade, que ocorrem dentro de uma região do Azure, estão totalmente integradas e raramente são notadas pelos utilizadores e, geralmente, acontecem em segundos. É garantido que não terão qualquer perda de dados, independentemente de a interrupção ser planeada ou não.

As ativações pós-falhas de recuperação após desastre ocorrem entre duas regiões Azure. Para garantir uma ativação pós-falha mais rápida com perda mínima de dados, é mantida uma cópia contínua de recuperação após desastre que usa replicação assíncrona. As ativações pós-falha planeadas não incorrem em perda de dados e, para ambientes de produção, geralmente, podem ser concluídas em segundos ou alguns minutos.

Para além da implementação técnica de elevada disponibilidade e BCDR, a equipa de operações testa regularmente a prontidão para responder a vários tipos de eventos.

Dentro do Power Automate

Os fluxos de cloud do Power Automate são criados com base no Azure Logic Apps. O Power Automate fornece abstrações e integração com outros componentes low-code, como o Power Apps, e usa o motor de runtime do Logic Apps. Os programadores que estão familiarizados com Logic Apps verão que o Power Automate utiliza conceitos semelhantes, incluindo a linguagem de expressão.

Dentro do Power Apps

O motor de runtime do Power Apps é criado na estrutura React. As aplicações são criadas no estruturador do Power Apps, que usa uma interface de arrastar e largar para criar ecrãs. As fórmulas do Power Fx implementam lógica. Os conectores expandem o acesso das aplicações a outros serviços, lógica e componentes que permitem extensões visuais reutilizáveis. Os programadores podem usar o Power Apps Component Framework (PCF) para criar controlos personalizados. Embora muitas estruturas de IU possam ser usadas juntamente com PCF, as caraterísticas do Power Apps incorporam suporte para React.

Conectores internos

Os conectores utilizam a Gestão de API do Azure para gerir as credenciais e ligações de cada utilizador.

A mesma arquitetura é usada para todos os conectores, incluindo conectores personalizados que cria para as suas próprias APIs. A utilização da Gestão de API do Azure garante uma interface consistente para produtos do Power Platform, como Power Apps e Power Automate com todos os conectores.

Uma exceção é o conector do Dataverse. Aparece na lista de conectores para aplicações e fluxos, mas é implementado de forma diferente. Quando uma aplicação ou um fluxo usa dados ou ações do Dataverse, a interação é direta através da API OData do Dataverse.

Opções de extensibilidade do Power Platform

A extensibilidade é uma caraterística fundamental que diferencia o Microsoft Power Platform de outras plataformas low-code. Um princípio orientador da plataforma é "sem penhascos" — não deve ser impedido de realizar algo usando low-code, mesmo que isso exija código tradicional. Pode criar uma carga de trabalho inteira como parte de uma aplicação maior usando o código tradicional, se necessário. No entanto, a plataforma oferece muitas opções de extensibilidade que permitem que o low-code e o código tradicional sejam usados em conjunto na mesma carga de trabalho.

A tabela a seguir fornece uma descrição geral de alto nível de algumas das opções de extensibilidade comuns. Referimo-nos a alguns deles novamente mais tarde, quando discutimos como abordar a modernização e as normas que pode aplicar.

Opção	Descrição
APIs e conectores personalizados	Os conectores personalizados para as suas APIs REST centralizam a lógica da aplicação e permitem que seja exposto a componentes low-code de forma segura e controlada. Pode usar esta abordagem numa estratégia API primeiro para modernização de aplicações. O conector personalizado usa um documento da OpenAPI para definir como um componente low-code pode interagir com a API REST. Por exemplo, pode criar uma API usando as Funções do Azure e publicá-la no a Gestão de API do Azure. A Gestão de API do Azure pode exportar uma definição da OpenAPI para criar automaticamente o conector personalizado para utilização numa solução low-code. Esta abordagem separa as aplicações cliente das APIs, permitindo que evoluam de forma independente. As APIs são geridas centralmente, adicionando uma camada de segurança ao não expor a API diretamente e ao usar técnicas de autenticação como chaves de subscrição, tokens, certificados de cliente e cabeçalhos personalizados.
Power Apps Component Framework	O Power Apps Component Framework é uma estrutura de extensibilidade para criar elementos visuais personalizados para o Power Apps e o Power Pages. Os componentes de código são criados com HTML, JavaScript ou TypeScript. Pense nos componentes de código como blocos modulares da IU que podem ser reutilizados para criar uma ou mais aplicações. Os componentes incluem um manifesto que define como um componente low-code pode interagir com o componente de código. A interface do componente permite que o motor de runtime de alojamento comunique os eventos do ciclo de vida do contentor de alojamento. Isto permite que o componente de código componha os seus elementos visuais usando informações de contexto fornecidas pelo contentor de alojamento. Para ideias, navegue pela galeria da comunidade em https://pcf.gallery.
Tabelas virtual	As tabelas virtuais facilitam a integração de dados que residem em sistemas externos. Representam de forma totalmente integrada os dados externos como tabelas no Microsoft Dataverse, sem replicar os dados e, muitas vezes, sem a necessidade de codificação personalizada. O Dataverse vem com fornecedores de dados para OData v4 e Azure Cosmos DB. Um fornecedor de conectores virtuais, atualmente em pré-visualização, expande os fornecedores de dados disponíveis para incluir um subconjunto dos conectores do Power Platform, incluindo o SharePoint e o SQL Server. Para cenários mais avançados, os programadores podem criar fornecedores de dados personalizados. A criação de fornecedores de dados personalizados requer conhecimento profundo dos dados externos e do Dataverse. A capacidade de criar plug-ins do Dataverse com o Power Fx para a lógica está em pré-visualização.
Plug-ins do Dataverse	Um plug-in do Dataverse é um processamento de eventos personalizado que é executado em resposta a um evento específico. Pense em plug-ins como procedimentos armazenados num motor de base de dados, mas escritos em .NET. Por exemplo, os eventos são criados durante o processamento de uma operação de dados do Microsoft Dataverse ou a pedido para eventos de API personalizados. O plug-in é implementado como uma classe personalizada compilada numa assemblagem .NET Framework que pode ser carregada e registada com o Dataverse. Usando uma interface definida, o plug-in pode obter informações de contexto sobre o evento que está a ser processado. Os plug-ins podem ser executados como parte da transação do Dataverse e podem executar outras operações de dados que fazem parte da transação atual. Os plug-ins destinam-se a pequenas unidades de trabalho. O desempenho tem de ser otimizado para que não afetem negativamente o desempenho geral. Os plug-ins são sempre executados, independentemente das operações da interface de utilizador ou da API, tornando-os numa forma poderosa de impor consistentemente a lógica de negócio.

Explorar cenários de arquitetura de modernização low-code

Tal como com a maioria das plataformas, pode compor um número infinito de cenários de arquitetura usando componentes do Power Platform e outros serviços cloud da Microsoft. Nesta secção do documento, exploramos alguns dos cenários mais comuns e abordamos algumas considerações que deve ter em mente ao usá-los.

Experiências da aplicação

Modernizar a experiência de utilizador pode fazer uma grande diferença para os utilizadores. O Power Apps é a principal forma de criar experiências de aplicação internas com o Power Platform. Pode usar o Power Pages para aplicações Web internas, mas é mais comum para aplicações voltadas para o exterior.

Power Apps

As cargas de trabalho devem ser concebidas de modo a que os utilizadores possam concluir grande parte do seu trabalho sem alternar entre aplicações. Ao modernizar uma aplicação grande e monolítica, pode dividir a funcionalidade em várias aplicações. Por outro lado, se os utilizadores precisarem de trabalhar com várias aplicações, poderá consolidá-los numa única aplicação que apresenta uma vista unificada das suas várias origens de dados.

A tabela a seguir descreve os dois tipos de aplicações que pode criar com o Power Apps, aplicações de tela e aplicações condicionadas por modelo.

Tipo de aplicação	Descrição
Aplicações de tela	As aplicações de tela são altamente personalizáveis. Consistem de um ou mais ecrã com os quais pode interagir. Você controla o esquema de cada ecrã e a navegação entre ecrãs. As aplicações de tela trabalham com dados que usam conectores. Uma única aplicação pode funcionar com vários conectores, tornando-o bom para integração em várias origens de dados como uma aplicação composta.
Aplicações condicionadas por modelo	As aplicações condicionadas por modelo utilizam o Dataverse como a origem de dados primária. Consistem de uma ou mais páginas, que podem ser tabelas do Dataverse ou páginas personalizadas. Uma página de tabela do Dataverse pode ser desagregada para uma página de detalhes para visualização e edição. As páginas personalizadas podem incorporar um ecrã de aplicação de tela e dados de conectores. As aplicações condicionadas por modelo têm uma estrutura de navegação incorporada personalizável. É consistente entre todas as aplicações condicionadas por modelo, o que ajuda a adoção pelos utilizadores.

O diagrama a seguir ilustra uma arquitetura básica para uma aplicação de tela ou uma aplicação controlada por modelo, no qual a aplicação se liga diretamente a origens de dados.

Para minimizar ligações diretas a uma origem de dados, pode fazer com que a aplicação use um conector personalizado para a API, que faz todo o trabalho necessário na origem de dados. Esta abordagem permite controlar que operações são expostas a componentes low-code e pode abstrair a complexidade da lógica subjacente. O diagrama a seguir ilustra esta abordagem de API primeiro.

O Power Apps também pode executar diretamente fluxos de cloud do Power Automate que podem devolver resultados para a aplicação ou executar de forma assíncrona.

A utilização do Power Apps com os seus repositórios de dados ou APIs permite modernizar a experiência de utilizador e, ao mesmo tempo, minimizar a interrupção noutras partes de uma solução legada. Esta abordagem também pode permitir que se ligue a vários sistemas legados numa única aplicação, o que oferece aos utilizadores um único local para concluir o trabalho deles.

Power Pages

A origem de dados primária para o Power Pages é o Dataverse. Ao adicionar páginas a um site, armazena as definições de página no Dataverse. As páginas podem apresentar dados do Dataverse e recolher dados dos utilizadores para armazená-los numa tabela do Dataverse.

Pode configurar páginas para acesso anónimo ou para acesso autenticado usando o Microsoft Entra ID para utilizadores internos ou fornecedores de identidade para utilizadores externos. Quando os utilizadores autenticados acedem a dados, apenas os dados a que têm permissão para aceder estão disponíveis.

Uma aplicação comum de um site do Power Pages é fornecer aos utilizadores externos acesso de atendimento automático a um processo de negócio organizacional. Os utilizadores internos podem usar uma aplicação do Power Apps. O diagrama a seguir ilustra tal arquitetura.

Gestão de dados

A modernização de aplicações requer a avaliação dos dados usados na solução geral. As aplicações modernizadas têm várias opções para processar dados. Em muitos casos, várias aplicações usam o mesmo repositório de dados. Torna-se difícil migrar os dados para um novo repositório como parte da modernização de uma das aplicações. Um princípio fundamental do Power Platform é que os dados podem ser usados onde estão ou trazidos para a plataforma num Dataverse ou num data lake.

Tem as seguintes opções para a arquitetura de dados da aplicação modernizada:

• Deixar os dados no lugar: use conectores ou APIs com conectores personalizados para aceder aos dados onde eles residem. Quando os dados estão no local, o gateway de dados pode facilitar a conectividade segura. Use tabelas virtuais para integrar dados externos compatíveis como uma tabela do Dataverse.

• Migrar para o Dataverse: o Dataverse é uma boa opção para dados transacionais e para consolidar várias origens num único sistema de registo. Os dados podem ser mapeados e migrados de várias origens usando o Power Query e fluxos automatizados. O Dataverse também suporta tabelas elásticas, concebidas para ingerir dados de alto volume armazenados em formatos não estruturados ou semiestruturados.

• Migrar para o data lake: para dados históricos, analíticos ou de telemetria, use um data lake. Os dados no lago lake podem ser usados para gerar análises do Power BI ou processados para gerar informações com tecnologia de IA.

Ao avaliar opções para a arquitetura de dados de uma aplicação modernizada, tenha em mente as seguintes considerações:

• Impacto noutras aplicações: embora a migração para um arquivo de dados mais eficiente possa ser ideal para uma aplicação, o impacto inicial noutras aplicações que usam os dados pode ser muito alto. Algumas organizações consideram deixar os dados em arquivos de dados antigos e criar novos dados no Dataverse, migrando do arquivo antigo à medida que mais aplicações são modernizadas.

• Impacto em novas aplicações: deixar dados num arquivo de dados antigo, embora fácil, pode afetar negativamente a facilidade com que as aplicações modernizadas podem usá-los. Os arquivos de dados mais antigos podem não ter uma boa integração com outros serviços de cloud, o que dificulta a incorporação dos dados na nova arquitetura geral.

• Consolidação de dados: é comum, como parte da modernização de aplicações, identificar dados que não têm propriedade ou responsabilidade claras para garantir a respetiva utilização adequada. Ao consolidar os respetivos dados no Dataverse, as organizações podem melhorar a governação deles e garantir melhor que são usados corretamente.

• Privacidade e segurança de dados: deve avaliar a privacidade e a segurança com base nas suas necessidades atuais e na arquitetura de modernização de destino, não apenas em como a aplicação legada as processou. As soluções de cloud têm mais opções para implementar controlos de privacidade e segurança. Frequentemente, um único arquivo de dados pode simplificá-los. Também deve considerar como implementar a segurança de dados unificados em aplicações híbridas que dividem dados entre vários repositórios.

• Problemas de integração. Os arquivos de dados mais antigos podem não ter as APIs necessárias para permitir o acesso sem migrar os dados ou criar uma API que as aplicações possam usar com um conector personalizado. A conectividade do arquivo de dados antigo com as aplicações que o usam deve ser avaliada para determinar se o desempenho seria aceitável.

Deve determinar uma arquitetura de dados para cada aplicação que será modernizada. Um primeiro passo é estabelecer uma visão geral de como as suas arquiteturas de dados se incorporam o Dataverse. Se o objetivo é maximizar o valor do low-code, deve usar o Dataverse sempre que possível. Ter uma visão no início pode ajudá-lo a evitar a propagação de mais silos de dados.

Dados externos e o Dataverse

As aplicações legadas, geralmente, dependem de dados que residem fora da organização e já existiam muito antes do Dataverse. A modernização destas aplicações não precisa de envolver a duplicação dos dados no Dataverse. Em vez disso, pode representar os dados como tabelas virtuais do Dataverse. As tabelas virtuais podem participar em relações com outras tabelas virtuais e com tabelas locais. As aplicações modernizadas veem um conjunto unificado de tabelas que parece existir inteiramente no Dataverse.

As tabelas virtuais são implementadas usando uma arquitetura de fornecedor de dados. O Dataverse inclui um fornecedor OData que pode ser utilizado com serviços Web OData V4. Um fornecedor de dados de conector virtual, atualmente em pré-visualização, permite usar conectores tabulares do Power Platform como tabelas virtuais.

O diagrama a seguir ilustra o uso do conector virtual.

Os programadores também podem criar fornecedores personalizados para outras origens de dados externas. No entanto, têm de compreender e implementar todos os mapeamentos do Dataverse e o suporte à operação.

As considerações a seguir podem ajudá-lo a avaliar a utilização de tabelas virtuais nos seus projetos de modernização:

• Todas as origens de dados externas têm de ter uma chave primária e o fornecedor de dados tem de apresentá-la como um GUID para o Dataverse. Pode acomodar chaves não GUID com preenchimento se o valor preenchido for estável e exclusivo.
• A segurança dos dados é configurada ao nível da tabela virtual. A segurança ao nível da linha e coluna não está disponível.
• O desempenho de tabelas virtuais depende do fornecedor de dados, da API da origem de dados externa e da conectividade à origem de dados. Na maioria dos casos, o acesso à tabela virtual é mais lento do que com tabelas do Dataverse locais.
• Algumas caraterísticas do Dataverse, como a pesquisa, a auditoria, gráficos e dashboards e acesso offline não estão disponíveis para tabelas virtuais.
• A utilização de tabelas virtuais para dados de referência pode resultar em sincronização reduzida.

Ficheiro e imagens

Ao modernizar aplicações que usam ficheiros e imagens, é importante considerar onde a nova solução os armazenará. O Dataverse possui capacidades especializadas para armazenar ficheiros e imagens. Ambos podem ser adicionados a tabelas como uma coluna e são armazenados no Armazenamento de Blobs do Azure que é gerido pelo Dataverse. As aplicações podem trabalhar com eles usando o conector do Dataverse, sem necessidade de autenticação nem API separadas.

A utilização do Dataverse de ficheiros e imagens é apropriado quando têm uma ligação direta com os dados e vários utilizadores não precisam de colaborar neles, por exemplo, uma foto de um produto ou uma localização ou a cópia final de um contrato legal. No entanto, se vários utilizadores precisarem de modificar o contrato legal simultaneamente, a utilização do SharePoint proporcionará maiores capacidades de colaboração. Considere usar o Armazenamento de Blobs do Azure diretamente se precisar de ter a segurança gerida em separado ou se precisar de usar determinadas caraterísticas específicas de ficheiros do Dataverse.

Integrações

Frequentemente, a modernização de aplicações inclui integrações com sistemas internos ou externos. As integrações podem ser amplamente categorizadas como dados, aplicações ou processos.

• A integração de dados combina dados de diferentes origens para dar ao utilizador uma vista unificada. Oferece uma abordagem desacoplada, mas não permite a construção de lógica ou processos em tempo real. O desempenho pode ser melhor porque todos os dados são locais.

• A integração de aplicações liga-se à camada de aplicações e é, frequentemente, feita através de APIs ou, com soluções low-code, conectores. A integração ao nível da aplicação fornece um limite definido entre duas soluções, mas também cria uma dependência em tempo real em muitos casos. Este tipo de integração também cria um limite de segurança, onde o acesso pode ser controlado pelo sistema que está a fornecer a API.

• A integração de processos liga vários sistemas diferentes, cada um dos quais parte de um processo empresarial geral. Este tipo de integração é o mais desacoplado, permitindo que os sistemas participantes processem cada parte do processo empresarial. Em cenários de modernização, pode ser útil particionar uma parte de um processo de modernização com low-code, integrado com outras partes ainda processadas por um sistema legado.

Ao avaliar como implementa integrações, é importante não assumir que a abordagem antiga é a melhor para a aplicação está a modernizar. Por exemplo, se um processo for síncrono e em tempo real, considere se pode fazê-lo de forma assíncrona. A integração síncrona pode ser mais frágil numa solução de cloud. Por exemplo, um fluxo low-code do Power Automate com processamento de erros apropriado poderia orquestrar a integração. Esta abordagem não só melhoraria a fiabilidade, mas também melhoraria a produtividade dos utilizadores, porque já não precisariam de esperar que a integração fosse concluída.

As considerações a seguir podem ajudá-lo a avaliar como apresentar integrações existentes:

• A integração ainda é necessária? Não é incomum descobrir que já ninguém usa os resultados da integração e que pode ser aposentada.

• Existem desafios de conectividade se a aplicação modernizada estiver na cloud? Os desafios podem incluir latência e acesso a uma API no local ou a um arquivo de dados. Em alguns casos, o gateway de dados no local pode ajudar a aceder ao serviço ou aos dados da cloud. Quando o acesso aos dados ou ao serviço for muito lento, considere se pode tornar os dados locais para a aplicação modernizada ou realizar a integração em fundo.

A integração também pode ajudar a dimensionar corretamente uma aplicação modernizada. Pode particionar uma ou mais partes da aplicação legada para deixar para trás ou implementar numa aplicação separada. Esta abordagem funcionaria bem quando utilizadores de funções diferentes usam partes diferentes da aplicação legada. Pode implementar uma ou mais das funções usando low-code e usar a integração de processos para permitir que a aplicação existente processe as partes restantes do processo. Com esta abordagem, pode modernizar incrementalmente as partes restantes ao longo do tempo. Ter partes independentes do processo implementadas separadamente também pode facilitar uma maneira mais ágil de implementar melhorias independentemente das outras partes do processo.

Antes de efetuar quaisquer integrações personalizadas, deve avaliar as capacidades de integração incorporadas no Power Apps.

• Microsoft Teams: as aplicações de tela do Power Apps e agentes do Copilot Studio podem ser incorporados em canais do Teams. Utilizar o conector do Teams, as aplicações e os fluxos podem facilmente publicar e consumir mensagens do Teams. Os cartões do Power Apps podem ser usados como microaplicações para partilhar informações acionáveis num canal do Teams.

• SharePoint: as aplicações condicionadas por modelo do Power Apps podem ser configuradas para ligar a documentos armazenados numa biblioteca do SharePoint para disponibilizá-los numa linha do Dataverse. Com as Listas da Microsoft ou uma lista do SharePoint, os utilizadores podem executar fluxos do Power Automate no contexto de um item de lista.

• Power BI: as informações do Power BI podem ser mostradas no contexto de uma aplicação de tela do Power Apps. Pode incorporar uma aplicação condicionada por modelo num relatório do Power BI para permitir que os utilizadores ajam em informações sem saírem do Power BI.

Usar o Dataverse como o repositório de dados primário para a aplicação modernizada fornece algumas capacidades incorporadas que podem ser úteis para integração.

• As APIs personalizadas do Dataverse podem ser usadas para integração de entrada ao nível da aplicação. As APIs personalizadas fornecem uma operação exclusiva que está associada a uma pequena quantidade de lógica de código personalizada. Por exemplo, um sistema de envio poderia usar a API personalizada RequestNewProject e a lógica associada saberia como colocar os dados recebidos nas tabelas do Dataverse apropriadas. O sistema de envio seria abstraído da estrutura de tabelas do Dataverse.

• A integração de saída pode ser feita usando as capacidades de eventos de publicação do Dataverse. O Dataverse pode ser configurado para publicar no Azure Service Bus, Hubs de Eventos do Azure ou em qualquer recetor Webhook. Por exemplo, quando uma nova linha de tabela de projeto do Dataverse é criada, pode ser publicada numa fila do Azure Service Bus. Também pode publicar mais eventos concetuais que correspondam a um evento do processo empresarial. Por exemplo, pode definir e publicar eventos quando um projeto for concluído.

O diagrama a seguir ilustra um exemplo de eventos de entrada e de saída num ambiente do Dataverse.

As organizações também devem considerar opções de integração pré-criadas disponíveis de terceiros no Microsoft AppSource. Por exemplo, a Microsoft tem uma solução pré-criada para organizações que precisam de integrar o SAP com o Power Platform. Esta solução pré-criada incorpora aplicações e fluxos e adiciona novas funcionalidades que facilitam a comunicação entre o sistema SAP da sua organização e o Power Platform.

Por exemplo, Ernst & Young usou a integração SAP pré-criada para desenvolver rapidamente uma solução para otimizar um processo financeiro global de alta frequência. O diagrama a seguir da solução PowerPost da empresa mostra como os utilizadores de finanças publicam documentos no respetivo sistema SAP ERP do Razão Geral usando o Power Platform.

Opções de conectividade da integração

À medida que as soluções se movem para a cloud, a conectividade de volta aos recursos no local pode ser essencial para garantir que as integrações ainda funcionam com a aplicação modernizada. Estas aplicações também têm de ser capazes de se integrar com outros recursos de cloud tradicionais que podem residir em ambientes de rede diferentes. O Power Platform suporta as quatro opções principais para conectividade segura: gateways de dados, gateways de dados de rede virtual, ligações privadas e ExpressRoute.

• Os gateways de dados permitem que componentes low-code do Power Apps, Power Automate e o Power BI alcancem os recursos no local de suporte aos cenários de integração híbridos. Os gateways fornecem uma forma rápida para aplicações low-code modernizadas acederem a origens de dados que ainda estão no local. Com um gateway, pode ligar-se a dados no local a partir de origens, como um sistema de ficheiros local, DB2, Oracle, SAP ERP, SQL Server e SharePoint. Um gateway pode suportar vários utilizadores e acesso a várias origens. Também pode configurar gateways de dados como clusters para fornecer elevada disponibilidade.

  O suporte de gateway é integrado no processo de ligação para conectores, o que permite a indicação de quando um gateway é necessário e a seleção do gateway configurado. Depois de a ligação ser configurada, as aplicações e os fluxos podem usar o conector como sendo um sem gateway.

  

• Os gateways de dados de rede virtual permitem que os fluxos de dados do Power BI e do Power Platform se liguem a serviços de dados numa rede virtual do Azure sem a necessidade de um gateway de dados no local numa máquina virtual dentro da rede virtual.

• Os pontos finais privados do Azure Private Link e da Rede do Azure permitem que as aplicações e os fluxos acedam ao Power BI com segurança. Os pontos finais privados são usados para enviar tráfego de dados de forma privada usando a infraestrutura de rede de suporte da Microsoft, em vez de atravessar a Internet. Os pontos finais privados garantem que o tráfego que entra nos recursos do Power BI da sua organização, como relatórios ou áreas de trabalho, segue sempre o caminho de rede de ligação privada configurado da sua organização.

• O Azure ExpressRoute fornece uma forma avançada de ligar a sua rede no local aos serviços de cloud da Microsoft utilizando a conectividade privada. Uma única ligação ExpressRoute pode aceder a vários serviços online, como o Power Platform, o Dynamics 365, o Microsoft 365 e os serviços cloud do Azure sem atravessar a Internet pública. O ExpressRoute requer planeamento e configuração significativos e envolve mais custos para o serviço ExpressRoute e o fornecedor de conectividade.

Independentemente das abordagens usadas para a conectividade de integração, deve avaliar a sua conectividade para garantir que tem latência e largura de banda baixas o suficiente para suportar as suas integrações e a aplicação modernizada.

Lógica de negócio

Ao criar aplicações modernas, pode escolher com o que implementar a lógica de negócio e onde implementá-la na sua arquitetura de aplicações. Sem orientação, a maioria das organizações acabaria com uma lógica de negócio caótica. Ter uma lógica reutilizável que garanta consistência na implementação pode ajudar a acelerar os esforços de modernização.

Para os nossos propósitos, definimos a lógica de negócio como sendo diferente da lógica da experiência de utilizador. Por exemplo, a lógica para navegar entre ecrã com base nos valores dos dados da inspeção é a lógica da experiência de utilizador. A lógica que implementou para determinar se uma inspeção está concluída pode incluir várias avaliações de condições e seria considerada lógica de negócio.

Ao arquitetar uma solução que inclui low-code, as considerações a seguir podem ajudá-lo a decidir onde poderá colocar a lógica de negócio.

• Na aplicação Power Apps: colocar a lógica de negócio na aplicação low-code é a abordagem mais simples, mas fornece opções limitadas para reutilizar ou impor consistência entre aplicações e automatizações. Geralmente, deve limitar esta abordagem a uma lógica simples e que não seja crítica, que outras aplicações ou automatizações não precisam de usar. As ferramentas low-code não fornecem uma experiência de depuração linha por linha. Se a lógica se estender a mais do que um ecrã ou for difícil de ler, deve considerar outras abordagens que seriam mais fáceis de manter. Não é incomum que alguma lógica de negócio seja duplicada localmente na aplicação e na cloud. Por exemplo, se um utilizador estiver a introduzir uma reserva de hotel, a regra de negócio é que a data de saída não pode ser anterior à data de entrada. Se a aplicação não validou isto, o utilizador chegaria até ao final e submeteria a reserva apenas para encontrar que o conector personalizado a rejeitou. Lidar com a validação localmente na aplicação e na cloud oferece uma experiência de utilizador muito melhor.

• Num fluxo de cloud do Power Automate: pode expressar a lógica de negócio nas ações num fluxo e o fluxo pode ser acionado em resposta a um evento ou a um pedido executado a pedido a partir de outras aplicações e fluxos. O fluxo pode fornecer uma abordagem low-code para centralizar a lógica. Os passos no fluxo são independentes e não fazem parte de uma transação; no entanto, os fluxos podem implementar compensação para processar a reversão se ocorrerem erros. Os fluxos podem executar passos usando ligações que têm permissões além do que o utilizador da aplicação pode ser capaz de fazer, fornecendo uma maneira de elevar permissões. Esta abordagem também permite minimizar as permissões de que o utilizador da aplicação pode precisar.

• Num plug-in do Dataverse: os plug-ins são executados em resposta a um evento de linha de dados, como criar, atualizar ou eliminar. Esta lógica é executada sempre que o evento ocorrer, independentemente de que aplicação ou fluxo realizou a ação ou se foi feita diretamente a partir da API do Dataverse. O benefício deste comportamento é que garante a consistência em todas as utilizações. Além disso, todas as alterações de dados ao Dataverse a partir da lógica do plug-in são transacionais e são todas concluídas ou todas revertidas. A lógica de plug-in tem de ser curta e eficiente e não tentar implementar trabalho de longa duração. Por vezes, os plug-ins em eventos não são a melhor abordagem se tiver de ouvir eventos em várias tabelas para concluir um único evento de negócio, como Fechar Inspeção. Por exemplo, poderá considerar uma API personalizada do Dataverse, em vez de ter plug-ins em várias tabelas. Os plug-ins podem realizar lógica com permissões elevadas que o utilizador, normalmente, não tem. Esta abordagem também permite minimizar as permissões de que o utilizador da aplicação pode precisar. Os plug-ins podem ser implementados numa solução do Dataverse juntamente com aplicações e fluxos.

• Em APIs personalizadas do Dataverse: as APIs personalizadas do Dataverse permitem-lhe implementar a sua própria mensagem de API personalizada que pode executar lógica. Por exemplo, pode criar uma API personalizada Fechar Inspeção que é chamada para fazer todo o trabalho de verificar e fechar uma inspeção. Não seria condicionada por evento, mas usada a pedido pelas aplicações e fluxos que precisam dela. Como os plug-ins condicionados por evento, as alterações aos dados feitas no plug-in da API personalizada são transacionais. Uma API personalizada é melhor quando o único serviço que usa é a API do Dataverse para outro trabalho de dados. Os plug-ins para APIs personalizadas podem ser implementados numa solução do Dataverse juntamente com aplicações e fluxos.

Implementar uma API de código

Pode implementar APIs no seu runtime de alojamento de API favorito, como as Funções do Azure, Azure Container Apps ou qualquer serviço capaz de alojar uma API REST. Estas APIs personalizadas podem implementar qualquer lógica, e tanto aplicações low-code quanto aplicações de código tradicionais podem usá-las. As APIs personalizadas não fornecem qualquer suporte a transações além do que pode ser fornecido por uma API que elas usam. Por exemplo, uma API personalizada poderia usar construções de transações do SQL Server se usasse o SQL Server. A implementação de uma API de código seria independente dos recursos low-code que poderiam usá-la. Pode usar a Gestão de API do Azure para governar a utilização destas APIs e ajudar a torná-las mais detetáveis.

Segurança

A segurança, incluindo autenticação e autorização, é uma parte essencial da arquitetura de uma aplicação modernizada. As aplicações modernas são, muitas vezes, mais difíceis de proteger do que as aplicações legadas. Incluem vários serviços cloud e os utilizadores trabalham com elas a partir de localizações mais diversas. Concetualmente, a segurança na plataforma está lá para garantir que os utilizadores podem fazer o trabalho que precisam com o menor atrito possível, continuando a proteger os dados e serviços.

O Power Platform adota uma abordagem de várias camadas para a segurança que pode usar para criar a sua arquitetura de segurança. Um princípio central destas capacidades é que as soluções low-code devem integrar-se com o seu aparato de segurança existente para minimizar o impacto de introduzi-las.

Vejamos de forma geral as múltiplas camadas de segurança que compõem o modelo de segurança do Power Platform.

• Os utilizadores são autenticados pelo Microsoft Entra ID e a utilização pode ser restringida através de políticas de acesso condicional.
• O licenciamento é a primeira porta de controlo que permite o acesso aos componentes do Power Platform.
• A capacidade de criar aplicações e fluxos de trabalho é controlada por direitos de acesso no contexto de ambientes.
• A capacidade de os utilizadores verem e utilizarem os recursos do Power Platform é controlada ao partilhar a aplicação com eles. Os recursos são partilhados diretamente com o utilizador ou grupo do Entra ID.
• Os ambientes agem como limites de segurança, permitindo que diferentes necessidades de segurança sejam implementadas num.
• Os fluxos e as aplicações de tela do Power Automate utilizam conectores. As credenciais de ligação específicas e os direitos de serviço associados determinam as permissões quando as aplicações utilizam os conectores.
• Os ambientes com uma instância do Dataverse suportam modelos de segurança mais avançados que são específicos para controlar o acesso aos dados e serviços nessa instância do Dataverse.
• A utilização do conector pode ser ainda mais restringida com políticas de prevenção da perda de dados (DLP). As restrições de entrada e saída entre inquilino também podem ser aplicadas aos conectores.

É importante notar que ao aceder a origens de dados com conectores, toda a segurança subjacente que o origem de dados oferece acresce às camadas de segurança descritas. Por predefinição, o Power Apps e o Power Automate não fornecem aos utilizadores acesso à origem de dados do conector que já não têm. Os utilizadores só devem ter acesso aos dados a que necessitam genuinamente de aceder.

Quando usa o Dataverse como parte de uma solução, este inclui um modelo de segurança baseado em função que pode ser adaptado a muitos cenários de negócio. Os dados podem ser protegidos até uma coluna individual numa linha de dados. Os utilizadores recebem um ou mais direitos de acesso que, juntos, determinam os seus privilégios gerais. O Dataverse fornece blocos modulares de modelagem de segurança, como unidades de negócios e equipas. Por exemplo, as unidades de negócio podem ser usadas para definir limites de segurança para manter os dados isolados entre dois grupos diferentes de utilizadores da organização. Pode usar equipas para agrupar utilizador que precisam de acesso semelhante aos dados. Pode até mesmo atribuir a propriedade do grupo de linhas de dados. O diagrama a seguir ilustra o uso de unidades de negócio para isolar dados para divisões de uma organização.

Conceber o seu modelo de segurança

Adapte o modelo de segurança da aplicação modernizada para a arquitetura geral da aplicação. As aplicações que usam um único repositório de dados e sem conectores exigem um trabalho mínimo de design de segurança. Como as aplicações usam mais conectores e repositórios de dados, a sua modelagem de segurança tem de incluir outras considerações.

• Identidade do utilizador: como é que os utilizadores se autenticam e isso já foi mapeado no Microsoft Entra ID em cenários provenientes do local? Isto inclui o mapeamento de grupos necessários para suportar a atribuição de grupo ou da equipa de aplicações em arquivos de dados de cloud, como o Dataverse.

• Identidade da ligação do conector: quando as aplicações usam um ou mais conectores, que tipo de autenticação é feita para a ligação e fornece o nível de controlo necessário para implementar os controlos de segurança necessários? Por exemplo, as aplicações que usam um principal de serviço para se ligar não exigem que o utilizador da aplicação tenha acesso direto ao conector, o que pode ser benéfico em alguns cenários. Ligações de utilizador individuais podem ser apropriadas para aplicações que precisam de saber que utilizador realizou uma operação ou definir o âmbito de respostas para utilizadores específicos.

• Portabilidade da construção de segurança: como as suas aplicações usam mais conectores e repositórios de dados, é importante lembrar que nem todas as construções de segurança passam diretamente de um mapa para outro. Por exemplo, no Dataverse existem várias maneiras pelas quais um utilizador pode obter acesso a uma linha de dados, incluindo a partilha da linha com o utilizador. Se uma aplicação associar uma biblioteca de documentos do SharePoint à linha, a segurança que dá acesso à biblioteca de documentos é separada da segurança que controla o acesso do Dataverse. Não mapeiam diretamente. As aplicações modernizadas têm de acomodar estes tipos de incompatibilidades entre os conectores e repositórios de dados que usam.

Inteligência artificial

Nos últimos anos, a IA encontrou o seu caminho para os esforços de modernização de aplicações. Ao modernizar aplicações, as organizações devem considerar o uso de inteligência artificial para ajudar a tornar os utilizadores mais produtivos e mais capazes de tomar decisões informadas. Os resultados da infusão de IA também podem traduzir-se em melhores experiências de cliente que afetam positivamente os resultados de negócio.

Incluindo a IA usada para envolver trabalho pesado na integração da lógica da aplicação e na criação de modelos preparados à medida. Com a disponibilidade e o poder dos grandes modelos de linguagem, as aplicações agora podem introduzir novas maneiras de usar a IA para ajudar os utilizadores a obter respostas e a realizar tarefas. Os utilizadores podem usar pedidos de linguagem natural para interagir com as capacidades de IA numa ampla gama de cenários de negócio de assistência.

A Microsoft introduziu Copilots nos principais produtos e serviços para facilitar o acesso à tecnologia avançada de IA. Um Copilot usa técnicas modernas de IA e modelos de linguagem grandes com os quais os utilizadores podem interagir nas aplicações que usam todos os dias, como o Microsoft 365, o Windows, o Dynamics 365 e o Power Platform.

Expandir com plug-ins

Os utilizadores de aplicações com tecnologia do Copilot podem pedir ajuda ao Copilot para tarefas comuns na aplicação. Pode expandir Copilots para incluir dados e tarefas que estes ainda não conhecem e que estão além do âmbito da aplicação com a qual o utilizador está a trabalhar. O Copilot do Microsoft 365 pode incorporar dados armazenados do Power Platform no Dataverse, para que os utilizadores não precisem de alternar entre aplicações. Por exemplo, no Outlook, um utilizador pode pedir ao Copilot para gerar uma atualização de estado para todas as inspeções com falha concluídas hoje. O Copilot do Microsoft 365 herda automaticamente a estrutura nativa de segurança e governação Dataverse e aplica a segurança e as permissões de utilizador em runtime.

Conectores como plug-ins

Os conectores do Power Platform também são importantes para a experiência do Copilot. Os conectores são capazes de se ligar como plug-ins para expandir as capacidades do Copilot. Por exemplo, o Copilot do Microsoft 365 com o conector do Power Platform para o Software Jira pode permitir que um gestor de projetos peça o estado de um pedido de suporte do Jira e aja com base na resposta, como encaminhá-lo para aprovação adicional ou iniciar uma nota de encomenda para novo hardware. Ao utilizar plug-ins, pode integrar os seus processos de negócio e dados com o Copilot para capacitar os utilizadores a interagir a partir de quaisquer aplicações que usem.

Criar o seu próprio copiloto

À medida que os utilizadores se habituam a ter assistência de IA do copiloto nas respetivas aplicações, esperam-na em todas as aplicações. Pode tornar as suas aplicações modernos mais cativantes. incluindo copilotos que cria com a pilha do Copilot, uma estrutura de desenvolvimento de IA.

Pode utilizar o controlo do Copilot pré-criado no Power Apps para adicionar copilotos às suas aplicações de tela e aplicações condicionadas por modelo. Ao configurar uma vista de uma origem de dados e algumas informações básicas de pedidos, pode fornecer rapidamente uma experiência de copiloto própria na aplicação.

Gestão do ciclo de vida das aplicações

Uma parte importante de qualquer esforço de modernização é estabelecer um processo apropriado de gestão do ciclo de vida de aplicações. As organizações, geralmente, querem que os seus esforços de low-code se encaixem em como trabalham com a ALM de código tradicional. O Power Platform fornece ferramentas de ALM para que possa incluir artefactos low-code nos processos que normalmente usa.

O ALM no Power Platform começa com a forma como cria os seus recursos low-code. Os recursos que cria estão no contexto de um ambiente do Power Platform. Um ambiente pode ter um arquivo de dados do Dataverse. Pode usar vários ambientes — normalmente, programação, teste e produção — para implementar zonas de destino num processo de ALM que inclui low-code. O número e a finalidade dos ambientes são flexíveis e as organizações podem ajustá-los para satisfazer as necessidades individuais do projeto. Uma solução do Dataverse é um contentor para recursos low-code relacionados, o que facilita o controlo de versão e o transporte de um ambiente para outro.

Os pipelines do Power Platform fornecem uma abordagem low-code para automatizar implementações e implementar a integração contínua e entrega contínua (CI/CD). O Power Platform gere o processo quando os pipelines são configurados. Os administradores podem gerir e governar centralmente os pipelines.

As organizações também podem usar as ferramentas de CI/CD de sua escolha. O Power Platform CLI é uma ferramenta de linha de comando que pode usar com a maioria das ferramentas de automatização de CI/CD. O Power Platform Build Tools fornece ações para o GitHub e tarefas para o Azure DevOps, que fornecem todas as ações comuns necessárias para criar automatizações de CI/CD que incluem artefactos low-code.

O diagrama a seguir ilustra um exemplo de uma equipa a criar uma aplicação Inspeção. No respetivo ciclo interior, trabalham num ambiente de programação e armazenam o trabalho num repositório Git. O ciclo exterior consiste de um ambiente de teste e de um ambiente de produção. Um pipeline de compilação usa a solução controlada por versão, realiza todas as verificações necessárias e produz um artefacto de solução de Inspeção. Em seguida, um pipeline de versão implementa a solução para teste, onde os testadores podem verificar se está pronta para produção. Uma vez aprovada, o pipeline de versão implementa a solução em produção.

Quando exporta uma solução a partir do Dataverse, esta é exportada como um único ficheiro comprimido. Para armazenar os recursos low-code no controlo de versão, pode usar as ferramentas de compilação para descompactar o ficheiro de solução em ficheiros de componentes individuais. Durante a automatização da compilação, as ferramentas de compilação combinam ficheiros individuais do controlo de versão num único ficheiro comprimido.

A implementação de uma solução num ambiente que contém uma versão anterior da solução usa um processo de atualização inteligente que só aplica alterações. Este processo de atualização de versão evita a necessidade de diferenciar scripts ou outras maneiras de determinar o que precisa de ser implementado.

Quando a sua aplicação modernizada inclui recursos de low-code e de código tradicional, pode combiná-los num único processo de CI/CD ou geri-los independentemente. Com a gestão independente, os recursos podem ser implementados individualmente e as equipas de projeto podem conseguir maior agilidade. Por exemplo, a API que uma aplicação low-code usa pode ser implementada independentemente se a equipa não introduzir alterações interruptivas.

Monitorização e informações

As aplicações modernizadas precisam de ser integradas em ambientes operacionais que forneçam a capacidade de diagnosticar problemas em diferentes ambientes, do desenvolvimento até à produção. Application Insights, uma extensão do Azure Monitor, recolhe telemetria do Power Apps e do Dataverse. Estas informações não só ajudam a identificar e a resolver problemas, mas também fornecem informações sobre o que os utilizadores fazem numa aplicação. Pode utilizar estas informações para ajudar a melhorar as aplicações e os processos na sua aplicação modernizada.

Enquanto uma aplicação do Power Apps está em desenvolvimento, os programadores podem incluir lógica para registar eventos personalizados. Depois de ligar a aplicação implementada ao Application Insights, a extensão recolhe automaticamente a telemetria básica, incluindo mais contexto de eventos registados, à medida que os utilizadores interagem com a aplicação.

Os administradores também podem configurar ambientes do Dataverse para exportar telemetria para o Application Insights. Os dados registados podem incluir chamadas à API do Dataverse, execução de plug-ins, operações SDK e exceções. Os programadores que criam lógica de plug-in personalizada podem registar mais dados de telemetria personalizados diretamente para o Application Insights.

Utilizar o Application Insights nas suas aplicações pode facilitar a correlação de problemas com vários recursos. A equipa de operações pode criar alertas no Azure Monitor para serem acionadas quando um grande número de exceções for detetado. A análise regular das suas aplicações modernizadas pode identificar tendências que exigem mais investigação.

Conclusão

Neste documento técnico, explorámos os benefícios, as estratégias e as melhores práticas da modernização das suas aplicações legadas com o Microsoft Power Platform. Obteve informações e orientações sobre como empregar capacidades de low-code do Power Platform para garantir o sucesso dos seus esforços de modernização como parte da transformação digital da sua organização.

As aplicações legadas apresentam muitos desafios para as organizações. Para superá-los, as organizações têm de embarcar em iniciativas de modernização de aplicações para revitalizar a infraestrutura e tirar partido de tecnologias modernas. Neste documento técnico, viu como adotar uma abordagem low-code para os seus esforços de modernização — especificamente, como as capacidades de desenvolvimento low-code do Microsoft Power Platform permitem que crie e implemente rapidamente aplicações modernas.

O low-code abre as portas a um conjunto mais amplo de pessoas do que os codificadores tradicionais. Um fator-chave das organizações que têm sucesso com uma abordagem low-code é garantir que as pessoas envolvidas na modernização de aplicações têm preparação em desenvolvimento low-code, sejam elas programadores profissionais ou utilizadores de empresa. Os utilizadores de empresa estão mais próximos do problema empresarial que está a ser resolvido e podem contribuir com conhecimento especializado que poupa tempo. Os programadores de código tradicionais podem aplicar as técnicas e as competências que já têm para criar extensões para preencher quaisquer lacunas de low-code. As organizações podem ser mais eficazes ao misturar recursos de negócio e técnicos no que gostamos de chamar de "equipas de fusão".

Este documento técnico estabelece a base para si. Os próximos passos são seus. Eis algumas sugestões:

• Reserve alguns minutos para descobrir o que sua organização já está a fazer com o low-code. Pode surpreendê-lo!
• Avalie as suas oportunidades de modernização de aplicações.
• Identifique e dê prioridade a um bom primeiro candidato.
• Equipe uma equipa que moderniza a aplicação. Para obter os melhores resultados, certifique-se de que é uma equipa de fusão.
• Certifique-se de que a equipa tem a preparação necessária para ser bem-sucedida.
• Permita que a equipa modernize a aplicação.
• Reflita sobre o esforço de modernização. Refine-o e dimensione-o para outras aplicações legadas.

O percurso de cada organização para a modernização de aplicações é exclusivo. A sua equipa de conta Microsoft ou parceiro do Power Platform pode ajudar a planear o seu percurso e mantê-lo no sempre no caminho certo.

Recursos

• O Impacto Económico Total™ das Capacidades Premium do Microsoft Power Platform
• A aplicação ConnectMe da American Airlines cria uma experiência de viagem mais suave para os clientes e melhores ferramentas de tecnologia para os membros da equipa
• Repositório de open-source do Power Fx no GitHub
• Kit de Iniciação CoE
• Avaliação da Adoção do Power Platform
• Agência de seguros digital automatiza um processo de compras complexo usando o Power Platform
• Galeria do PCF
• A EY ajuda a permitir a entrada na origem para um processo financeiro global com o Power Platform, o que reduz os tempos de processamento em 95 porcento
• Azure Private Link
• Microsoft Azure ExpressRoute
• Planeador de Versões do Power Platform
• Guia de Licenciamento do Microsoft Power Platform
• A Microsoft descreve a estrutura para a criação de aplicações de IA e copilotos; expande o ecossistema de plug-in de IA