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. A Microsoft Power Platform oferece um conjunto abrangente de ferramentas e tecnologias que capacitam as empresas a transformar e modernizar as suas aplicações de forma rápida e eficaz.

Este artigo explora os benefícios, estratégias e boas práticas da modernização de aplicações com a Microsoft Power Platform. Fornece insights 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.

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 da Microsoft Power Platform tornam possível construir e implementar aplicações modernas de forma mais rápida e económica 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 implantar agentes em vários canais, incluindo websites, 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
Potência Fx	Power Fx é uma linguagem low-code de código aberto inspirada em fórmulas Excel. Com um tipo forte, declarativo e funcional, com lógica imperativa e gestão de estado, todos expressos em texto de fácil compreensão, o Power Fx facilita as tarefas de programação comuns para programadores cidadãos e programadores profissionais. Suporta todo o espectro de desenvolvimento, desde no-code para quem nunca programou antes, até ao "pro-code" para profissionais experientes, capacitando equipas diversas a colaborar e a poupar tempo e despesas.
Conectores	Os conectores são vitais para permitir que a programação de baixo código e tradicional trabalhem juntas para fornecer aplicações modernas. Os conectores são um invólucro em torno de uma API que permite ao Power Apps e ao Power Automate utilizar fontes e serviços de dados 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 que as aplicações low-code consigam consumir a API de forma fácil.
Dataverse	O Dataverse é um armazenamento híbrido de dados em escala cloud construído sobre serviços de gestão de dados do Azure — mas é mais do que uma base de dados. É a plataforma de dados subjacente tanto para o Dynamics 365 como para o Power Platform, com lógica do lado do servidor sob a forma de fluxos de trabalho e plug-ins, regras de negócio e fluxos de processos, um modelo de segurança altamente sofisticado e uma plataforma de desenvolvimento extensível com suporte incorporado para aplicações multilingue e multi-moeda. 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 da inteligência artificial no Power Apps e no Power Automate para encontrar insights nos seus dados, automatizar processos e tornar as suas aplicações mais produtivas. Com o AI Builder, não precisas de competências em programação ou ciência de dados para aceder 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 da Power Platform, cidadãos ou profissionais, mais produtivos, permitindo-lhes dedicar mais tempo às melhores partes do seu trabalho e menos tempo a tarefas mundanas. Descreva o seu cenário de negócio ao Copilot no Power Automate e isso pode transformar a sua descrição num fluxo de trabalho automatizado. Diz ao Copilot no Power Apps o que queres fazer ou que informação queres ver e ele pode criar uma aplicação para isso. O Copilot estabelece 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 que utilizam a Microsoft Power Platform vão além do valor inicial de negócio de ter uma solução que utiliza 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 gargalos. 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. A Power Platform de baixo código é mais acessível a um conjunto maior de utilizadores. 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.

• Construa o carrinho, em vez da 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 um carrinho 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. A Power Platform reduz esta dívida técnica ao tornar mais fácil e menos dispendioso construir soluções corretamente à primeira. Também simplifica a integração e governação de dados com um modelo de dados comum e conectores, centraliza a gestão de soluções e apoia 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, é possível limitar quem pode partilhar quais fluxos e aplicações, e com quem, bem como usar políticas para restringir os conectores que os criadores podem utilizar. 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 construídas na plataforma beneficiam das inovações da Microsoft sem custos adicionais para si.

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

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 a ConnectMe, uma aplicação Microsoft Teams construída sobre Power Apps e Azure. Ao utilizar a aplicação em qualquer dispositivo móvel, as equipas na linha da frente têm informações chave sobre chegadas, embarque, bagagem, e portões à sua disposição em tempo real. Esta visibilidade simplifica as operações em terra, acelera os tempos de viragem das aeronaves e torna a viagem uma experiência mais agradável para os clientes. Saiba mais 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 assistente, atuando como um parceiro para gerar conteúdo no 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á por 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, e ainda mais, atualizá-las, exige escalar uma montanha de dívida técnica que aumenta conforme se 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 do ALM quando é mais apropriada, e os fatores que podem influenciar a seleção.

Fim de vida

Migration

Modernização

Retire

Substituir

Rehost

Refactor

Rearchitect

Rebuild

Descrição

Remover aplicação

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

Reimplementar sem alterações na nuvem

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 rápido em nuvem

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

Combinar pilhas de tecnologia

Acelerar a inovação

Acelerar o desenvolvimento

Reduzir despesas operacionais

Microsoft tecnologias

Power Apps

Dynamics 365

Azure IaaS

Azure VMWare

Power Platform

Contentores

Azure PaaS

Power Platform

Azure PaaS

Microsserviços sem servidor

Power Platform

Azure PaaS

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
Rehost	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 encapsular a lógica existente movendo-a para uma API que pode ser disponibilizada a soluções de baixo código 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 Marketplace pode ajudar a impulsionar a modernização quando o caso de uso corresponde a uma capacidade pré-construída. 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 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 de baixo-código e prioridade à cloud, pode utilizar serviços e ferramentas da plataforma cloud para proteger, gerenciar, 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. O mais importante a ter em conta é 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 um aplicativo, recomendamos que comece por verificar se este ainda é necessário e útil, ou se deve ser descontinuado. 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 determinares que uma aplicação não é adequada porque Power Apps falta um controlo obrigatório, podes usar o framework Power Apps component (PCF) e código tradicional para construir um controlo personalizado. Outro exemplo é uma aplicação com lógica complexa. Poderias centralizar a lógica numa API que o Power Apps possa 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 baseou-se em serviços tradicionalmente desenvolvidos como Angular, Xamarin e Azure. Ao adicionar Power Platform e Dynamics 365, NSure.com criado uma solução de próxima geração utilizando técnicas de codificação low-code e tradicionais, como ilustra o diagrama seguinte. Obtenha mais informações sobre o percurso da empresa.

Tão importante quanto identificar oportunidades de código baixo é reconhecer quando uma abordagem de código baixo 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 um oceano de 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 capacidades básicas para cenários simples offline. 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 poderiam ser usados para recolher e analisar os dados e sinais relevantes adicionados ao Dataverse para desencadear 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.
Tarefas de 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 de baixo código pode invocar.
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 fases de lançamento 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 gerar 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 e construída sob medida, 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 à equipa o conhecimento e a confiança no desenvolvimento low-code necessário para finalizar de forma bem-sucedida um projeto 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 construir 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 sentir-se à vontade para criar uma aplicação ou fluxo de teste que utilize o código que escrevem para garantir que funciona e estarem prontos para apoiar recursos de baixo nível de codificação na utilização dos seus ativos de extensibilidade.

As ferramentas de low-code e de código tradicional precisam compreender onde as soluções de low-code e de código tradicional começam e terminam e onde se intersectam.

Compilar 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 de baixo código (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 padrões de UX escritos para aplicações Angular à sua 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 construir uma aplicação a partir dos controlos do Power Apps Component Framework para evitar o uso de 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 de código reduzido

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. As licenças do Power Apps podem ser por utilizador ou por aplicação. Os sites 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 e pela licença para 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 construídos sobre os mesmos serviços cloud do Microsoft Azure disponíveis se usar métodos tradicionais de programação. 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 é alimentado por mais de 25 serviços Azure totalmente geridos, como Functions, Load Balancer, Cognitive Services, Synapse, DevOps, Active Directory e Microsoft Purview. As capacidades integradas incluem segurança abrangente, análises potentes, IA, lógica de negócio avançada e gestão de eventos, modelação de dados e integração com Dynamics 365, Microsoft 365, Azure e mais. Todas estas capacidades são construídas numa camada de armazenamento poliglota Dataverse, que se baseia no Azure SQL DB (para dados relacionais), Azure Cosmos DB (para NoSQL), Azure Blob Storage (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 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, ocorrendo normalmente 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 do 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. Os failovers planeados não incorrem em perda de dados e, para ambientes de produção, geralmente, podem ser concluídos 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.

No Power Automate

Os fluxos cloud do Power Automate são construídos sobre o Azure Logic Apps. O Power Automate fornece abstrações e integração com outros componentes low-code como o Power Apps e utiliza o motor de execução do Logic Apps. Os programadores familiarizados com Logic Apps irão descobrir que o Power Automate utiliza conceitos semelhantes, incluindo a linguagem de expressões.

Dentro do Power Apps

O motor de execução do Power Apps é construído sobre o framework React. As aplicações são construídas no Power Apps designer, que utiliza uma interface de arrastar e largar para construir 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 framework Power Apps Component (PCF) para criar controlos personalizados. Embora muitos frameworks de interface de utilizador possam ser usados juntamente com o PCF, o Power Apps tem suporte incorporado para o React.

Conectores internos

Os conectores utilizam o Azure API Management para gerir 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 do Azure API Management assegura uma interface consistente para produtos 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 característica chave que diferencia a 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 exposta a componentes de pouco código de maneira 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 o Azure Functions e publicá-la no Azure API Management. O Azure API Management pode exportar uma definição 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 framework Power Apps Component é um framework de extensibilidade para criar visuais personalizados para Power Apps e 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 virtuais	As tabelas virtuais facilitam a integração de dados que residem em sistemas externos. Representam os dados externos de forma fluida como tabelas no Microsoft Dataverse, sem replicar os dados e muitas vezes sem necessidade de codificação personalizada. O Dataverse inclui fornecedores de dados para OData v4 e Azure Cosmos DB. Um fornecedor de conectores virtuais, atualmente em pré-visualização, expande o número de fornecedores de dados disponíveis para incluir um subconjunto dos conectores da Power Platform, incluindo SharePoint e 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, eventos são gerados durante o processamento de uma operação de dados do Microsoft Dataverse ou sob pedido para eventos personalizados da API. O plug-in é implementado como uma classe personalizada compilada numa assembly de framework .NET que pode ser carregada e registada no 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

Como na maioria das plataformas, pode compor um número infinito de cenários de arquitetura usando componentes 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 construir experiências internas de aplicação com o Power Platform. Pode usar o Power Pages para aplicações web internas, mas é mais comum para aplicações externas.

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 seguinte descreve os dois tipos de aplicações que pode construir com Power Apps, aplicações canvas e aplicações orientadas a modelos.

Tipo de app	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 canvas funcionam com dados através de 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.
Aplicativos orientados 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 cloud do Power Automate que podem devolver resultados à aplicação ou executar de forma assíncrona.

Usar o Power Apps com os seus repositórios de dados ou APIs permite-lhe modernizar a experiência do utilizador, minimizando as perturbações 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 principal fonte de dados do 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 Power Pages é fornecer aos utilizadores externos acesso de autoatendimento a um processo de negócio organizacional. Os utilizadores internos podem usar uma aplicação 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:

• Deixe os dados no lugar: utilize 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 fontes 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 podem ser usados para gerar análises do Power BI ou processados para gerar insights baseados em 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 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 de linhas e colunas 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 Azure Blob Storage, 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 para ficheiros e imagens é apropriada 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, um local ou a cópia final de um contrato legal. No entanto, se vários utilizadores precisarem de modificar o contrato legal em simultâneo, a utilização do SharePoint proporcionaria maiores capacidades de colaboração. Considere usar o Azure Blob Storage diretamente se precisar que a segurança seja gerida separadamente do Dataverse ou se precisar de usar certas funcionalidades específicas de ficheiros.

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 conecta-se à camada de aplicações e é, frequentemente, feita através de APIs ou, com soluções de código reduzido, 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 de Power Automate de baixo código com tratamento adequado de erros 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 descontinuada.

• 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 segundo plano.

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 avançar com 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 os agentes do Copilot Studio podem ser incorporados nos canais do Teams. Ao utilizar o conector do Teams, as aplicações e os fluxos podem facilmente publicar e consumir mensagens do Teams. Os cartões Power Apps podem ser usados como micro-apps para partilhar informação acionável num canal do Teams.

• SharePoint: As aplicações Power Apps orientadas por modelo podem ser configuradas para se ligarem a documentos armazenados numa biblioteca do SharePoint para os disponibilizar numa linha do Dataverse. Com o Microsoft Lists ou um SharePoint list, os utilizadores podem executar fluxos do Power Automate no contexto de um item da lista.

• Power BI: Os insights do Power BI podem ser apresentados no contexto de uma aplicação Power Apps canvas. Pode incorporar uma aplicação orientada a modelos num relatório do Power BI para permitir que os utilizadores ajam com base nos insights sem sair 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 externa pode ser feita usando as capacidades de eventos de publicação do Dataverse. O Dataverse pode ser configurado para publicar no Azure Service Bus, Azure Event Hubs ou qualquer recetor Webhook. Por exemplo, quando uma nova linha é criada numa tabela de projeto do Dataverse, esta pode ser publicada numa Azure Service Bus queue. 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 devem também considerar opções de integração pré-construídas disponíveis por terceiros no Microsoft Marketplace. Por exemplo, a Microsoft tem uma solução pré-construída para organizações que precisam de integrar SAP com a 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 lançam documentos no respetivo sistema SAP ERP do Razão Geral usando o Power Platform.

Opções de conectividade para 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 os componentes low-code do Power Apps, Power Automate e Power BI acedam novamente a recursos no local para suportar 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 locais provenientes de fontes 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.

• Azure Private Link e Azure endpoints privados de rede permitem que aplicações e fluxos acedam a Power BI de forma segura. Os endpoints privados são usados para enviar tráfego de dados de forma privada, utilizando a infraestrutura de rede backbone da Microsoft, em vez de atravessarem a internet. Os endpoints privados garantem que o tráfego que entra nos recursos Power BI da sua organização, como relatórios ou espaços de trabalho, siga sempre o caminho da rede de ligação privada configurado pela sua organização.

• Azure ExpressRoute fornece uma forma avançada de ligar a sua rede local a Microsoft serviços cloud usando conectividade privada. Uma única ligação ExpressRoute pode aceder a múltiplos online services como Power Platform, Dynamics 365, Microsoft 365 e serviços cloud Azure sem passar pela 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ãs baseada nos valores dos dados de inspeção é lógica da experiência do 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 lógica de negócio numa aplicação low-code é a abordagem mais simples, mas oferece opções limitadas para reutilização ou para impor consistência entre aplicações e automaçõ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 mecanismos de compensação para gestão de rollback 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 do 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 tarefas 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 orientada por eventos, mas estaria disponível a pedido para as aplicações e fluxos que dela necessitam. Como os plug-ins orientados a eventos, 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 ambiente de execução favorito para alojamento de APIs, como Azure Functions, Azure Container Apps, ou em quaisquer serviços capazes 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 construtos de transação 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 o Azure API Management para governar o uso destas APIs e ajudar a torná-las mais acessí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 o uso pode ser restringido 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 funções de segurança 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 com o grupo Entra ID.
• Os ambientes atuam como fronteiras de segurança, permitindo que diferentes necessidades de segurança sejam implementadas em cada um deles.
• Os fluxos do Power Automate e as aplicações canvas usam 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.
• O uso do conector pode ser ainda mais restrito com políticas de gestão de dados. As restrições de entrada e saída entre locatários também podem ser aplicadas aos conectores.

É importante notar que ao aceder a fontes de dados através de conectores, toda a segurança subjacente que a fonte de dados oferece é adicionada às camadas de segurança descritas. Por predefinição, o Power Apps e o Power Automate não concedem aos utilizadores acesso à origem de dados do conector de que ainda não disponham. 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 uma ou mais funções de segurança que, juntas, determinam os seus privilégios globais. 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é atribuir a propriedade de grupo a 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.

• User identity: Como é que os utilizadores se autenticam e isso já foi mapeado no Microsoft Entra ID em cenários provenientes de instalações locais? Isto inclui o mapeamento de grupos necessários para suportar a atribuição de grupos ou equipas de aplicações em armazenamento de dados na 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.

Incorporar IA costumava envolver esforço significativo na integração da lógica da aplicação e na criação de modelos treinados personalizados. 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 os Copilots em produtos e serviços principais para facilitar o acesso a tecnologia avançada de IA. Um Copilot utiliza técnicas modernas de IA e grandes modelos de linguagem e pode ser interagido pelos utilizadores nas aplicações que utilizam diariamente, como Microsoft 365, Windows, Dynamics 365 e Power Platform.

Expandir com plug-ins

Os utilizadores de aplicações alimentadas pelo Copilot podem pedir ajuda ao Copilot com 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 Microsoft 365 Copilot pode incorporar dados da Power Platform armazenados no Dataverse, para que os utilizadores não tenham de alternar entre aplicações. Por exemplo, a partir do Outlook, um utilizador pode pedir ao Copilot para gerar uma atualização de estado para todas as inspeções falhadas concluídas hoje. O Microsoft 365 Copilot herda automaticamente a estrutura nativa de segurança e governação do Dataverse e aplica a segurança e permissões dos utilizadores em tempo de execução.

Conectores como plugins

Os conectores Power Platform também são importantes para a experiência do Copilot. Os conectores podem ser ligados como plug-ins para expandir as capacidades do Copilot. Por exemplo, o Microsoft 365 Copilot 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. Usando plug-ins, pode integrar os seus processos de negócio e dados com o Copilot para capacitar os utilizadores a interagir a partir das aplicações que utilizam.

Construa 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 modernas mais envolventes ao incluir copilots que cria com o Copilot Stack, um framework 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 ajustem à forma 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 se criam os 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 Azure DevOps que fornecem todas as ações comuns necessárias para construir automações CI/CD que incluem artefactos low-code.

O diagrama a seguir ilustra um exemplo de uma equipa a criar uma aplicação de 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 lançamento 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 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 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 ativados quando são detetadas muitas exceções. A análise regular das suas aplicações modernizadas pode identificar tendências que exigem mais investigação.

Conclusão

Neste artigo, explorámos os benefícios, estratégias e boas práticas de modernizar as suas aplicações legadas com a 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 artigo, viu como adotar uma abordagem low-code nos seus esforços de modernização — especificamente, como as capacidades de desenvolvimento low-code da Microsoft Power Platform permitem construir e implementar 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 artigo estabelece a base para você. 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.
• Forme uma equipa que modernize 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 Microsoft account ou parceiro Power Platform pode ajudá-lo a planear a sua jornada e manter-se no caminho certo ao longo do percurso.

Recursos

• O Impacto™ Económico Total das Capacidades Premium 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 código aberto 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 transforma as suas operações financeiras globais com aplicações inovadoras e agentes baseados em IA utilizando a Power Platform
• Azure Private Link
• Microsoft Azure ExpressRoute
• Planeador de Versões do Power Platform
• Microsoft Power Platform Guia de Licenciamento
• Microsoft descreve a estrutura para construir aplicações e copilotos de IA; expande o ecossistema de plugins de IA