Desenvolver uma estratégia de ambiente de inquilino para adotar o Power Platform em escala

O percurso de adoção de cada organização do Microsoft Power Platform é exclusivo. Uma estratégia de ambiente de inquilino estabelece a fundação para ajudar a acelerar a utilização de uma forma gerível e segura.

Este documento técnico mostra-lhe como alinhar a sua estratégia de ambiente de inquilino do Power Platform com as capacidades e a visão do produto. Fica a saber como utilizar melhor as caraterísticas mais recentes da plataforma para implementar uma estratégia que permite que a sua adoção do Power Platform alcance a escala empresarial.

Introdução

O Power Platform capacita as organizações a criar soluções low-code para inovação rápida. Estas soluções podem focar-se na produtividade de indivíduos e equipas pequenas, ou aplicar-se a toda a organização. Podem também estender-se aos processos empresariais, incluindo parceiros e clientes externos. A suportar estas soluções estão ambientes do Power Platform, onde os recursos de low-code são criados, testados e utilizados. À medida que uma organização aumenta a sua adoção do Power Platform, implementar uma boa estratégia de ambiente de inquilino é essencial para torná-la gerível e segura à medida que o número de ambientes cresce.

Para o ajudar a ter mais sucesso, este artigo orienta-o sobre a melhor forma de utilizar as caraterísticas disponíveis para estabelecer a sua primeira estratégia de ambiente ou evoluir os seus planos atuais. Também descrevemos a nossa visão sobre como estas caraterísticas devem funcionar em conjunto e como evoluirão para gerir o Power Platform em escala. Nesta orientação, estabelecemos como encaminhar adequadamente novos utilizadores para ambientes e ambientes de grupo para aplicar consistentemente a governação, as regras de segurança e outros aspetos importantes de uma estratégia de ambiente de inquilino. Também fornecemos passos detalhados para proteger o seu ambiente predefinido, que é um primeiro passo crítico na implementação de uma estratégia de ambiente.

Embora muitos Perspetivas estejam disponíveis para gerenciar Power Platform ambientes, a abordagem neste artigo está alinhada com Microsoft a direção de produto mais recente e usa recursos atuais e aprimoramentos planejados a curto prazo. Esta orientação atualizada pode ajudá-lo a garantir que você use apenas os recursos e opções de ambiente que são estratégicos para gerenciar Microsoft ambientes em escala.

MicrosoftVisão da Estratégia de Ambiente do Inquilino

Muitas organizações iniciam o percurso do Power Platform com aplicações de produtividade pessoais e automatizações criadas e executadas num ambiente central partilhado denominado Ambiente predefinido. Frequentemente, estes recursos utilizam apenas as capacidades básicas incluídas e o Microsoft 365, e não utilizam todas as capacidades do Power Platform. À medida que essa adoção inicial se acelera, Microsoft fornece às organizações uma rampa para uma estratégia de ambiente para a adoção em escala empresarial de todos os Power Platform recursos. Estas capacidades de governação premium ficam disponíveis quando os utilizadores têm uma licença premium do Power Platform (Power Apps, Power Automate,, Microsoft Copilot Studio e do Dynamics 365). O Modelo de maturidade de adoção do Power Platform pode fornecer mais informações para ajudar as organizações a definir o respetivo mapa para alcançar a adoção à escala empresarial para além da sua estratégia de ambiente. Esta abordagem pode ajudar as organizações a amadurecer desde a produtividade pessoal básica até à adoção em escala empresarial do Power Platform.

As caraterísticas administrativas, de governação e de segurança do Power Platform permitem que as organizações adotem e façam a gestão do Power Platform para produtividade empresarial e da utilização de aplicações empresariais em escala. A utilização de Ambientes Geridos ativa um conjunto de capacidades premium que permitem maior visibilidade e controlo, bem como reduzem o esforço manual de administrar e proteger ambientes. Ao utilizar estas capacidades, pode assegurar a aplicação consistente das suas políticas de governação e segurança. Os admins podem efetuar a transição para uma estratégia de ambiente de escala empresarial utilizando estas capacidades. Passar menos tempo e esforço na administração ajuda a reduzir o custo total de posse (TCO) global da plataforma à medida que a sua organização dimensiona a utilização.

Um elemento-chave da transição para a escala empresarial é melhorar a estratégia de ambiente partilhado e central para os criadores, facilitando a utilização de ambientes pessoais de programação. Numa estratégia de ambiente central partilhada, os criadores criam, utilizam e partilham aplicações no ambiente predefinido. Esta estratégia pode resultar na falta de isolamento e fazer com que os criadores se sobreponham uns aos outros. Imagine se todos na empresa partilhassem uma única pasta do OneDrive para todos os documentos. Em vez disso, pode utilizar caraterísticas de ambiente para orientar os criadores para o respetivo ambiente pessoal, onde podem criar com segurança as suas aplicações protegidas contra criadores que trabalham em recursos não relacionados, com governação simplificada para admins. Os colegas de trabalho podem ser adicionados como mais criadores a estes ambientes para colaborarem na criação de soluções.

Figura: Ilustração de um ambiente central compartilhado (esquerda) e uma estratégia de roteamento de ambiente (direita).

Os ambientes de criador recém-criados podem ser automaticamente adicionados a um grupo que aplica regras para garantir que os ambientes têm políticas de governação e de segurança consistentes. Os admins podem processar exceções ao mover o ambiente de um criador para um grupo com regras relaxadas.

Os recursos de low-code criados pelos criadores representam a fase inicial no percurso de gestão do ciclo de vida das aplicações (ALM) de um recurso. Como parte desta fase inicial, é importante capturar cada versão de um recurso e conseguir recriá-la, se necessário. Quando o recurso está pronto para ser partilhado, o criador pode usar a integração contínua anexada ao ambiente de programação para promovê-lo para um ambiente de produção, onde os utilizadores podem executar o recurso isolado de qualquer atividade continuada do criador.

Deve dar prioridade às caraterísticas incorporadas da plataforma para gerir ambientes sempre que possível, em vez de criar as suas próprias ferramentas. Se as funcionalidades incorporadas não satisfizerem os requisitos exclusivos da sua organização, pode utilizar ferramentas de administração da plataforma para criar ferramentas personalizadas. Deve avaliar quaisquer ferramentas personalizadas em relação a novas caraterísticas, à medida que ficam disponíveis. Ficar de olho no Microsoft roteiro da plataforma e manter seu próprio roteiro pode ajudar a tornar isso mais fácil.

Deverá estabelecer a sua estratégia de ambiente utilizando as capacidades de ambiente recomendadas adaptadas às necessidades exclusivas da sua organização. Não pense em criar a sua estratégia de ambiente como uma atividade única. Deverá evoluir ao longo do tempo para incorporar novas caraterísticas de ambiente, à medida que se tornam disponíveis.

Caraterísticas que suportam uma estratégia de ambiente de escala empresarial

Os ambientes são uma bloco modular para Power Platform administração, governança e segurança. Uma descrição geral completa da caraterística está fora do âmbito deste artigo; no entanto, esta seção destaca as caraterísticas que suportam a implementação de uma estratégia de ambiente em escala empresarial.

• Tipos de ambientes descreve os diferentes usos de ambientes como parte de sua estratégia.

• Ambientes Geridos fornece um conjunto de recursos premium que tornam os ambientes mais fáceis de gerenciar em escala.

• A reivindicação automática de licenças simplifica a atribuição de licenças, permitindo que os usuários reivindiquem Power Apps licenças por utente quando forem necessárias, em vez de exigir que um administrador identifique os usuários que precisam de licenças com antecedência.

• Grupos e regras de ambiente explica como gerenciar ambientes como grupos e aplicar regras a grupos para automatizar políticas de governança consistentes.

• O roteamento de ambiente padrão afasta automaticamente os criadores da criação de recursos no ambiente padrão para seu próprio ambiente pessoal.

• Microsoft Dataverse proporciona maior segurança e ALM.

• As soluções preferidas ajudam os fabricantes a garantir que todos os ativos que eles criam estejam em uma Dataverse solução, tornando mais fácil promover-los para outros ambientes.

• O Pipelines in Power Platform fornece um processo simplificado para promover ativos desde o desenvolvimento até ambientes de teste e produção, disponibilizando integração e implantação contínuas (CI/CD) para todos os fabricantes.

• O Catalog in Power Platform permite que os criadores compartilhem componentes, como aplicativos e fluxos, e pontos de partida mais avançados, como modelos.

Tipos de ambientes

A tabela que se segue descreve os tipos de ambientes que pode criar, as respetivas caraterísticas e utilizações pretendidas.

Tipo	Características e utilizações
Predefinido	O ambiente fornecido com cada inquilino. Muitas experiências do Microsoft 365 utilizam este ambiente para personalizações e automatizações. Este ambiente não se destina a trabalho a longo prazo ou permanente para além dos cenários pessoais de produtividade do Microsoft 365.
Produção	Este ambiente deve ser utilizado para realizar trabalho permanente numa organização. Os ambientes de produção suportam retenção de cópia de segurança expandida, de sete dias até um máximo de 28 dias.
Sandbox	Estes ambientes de não produção suportam ações de ambiente, como copiar e repor. As sandboxes são melhores utilizadas para ambientes de teste e de compilação ALM.
Programador	Estes ambientes especiais destinam-se a áreas de trabalho de programação pessoais dos criadores, que isolam os recursos de low-code dos utilizadores e de outros criadores. Os criadores podem ter até três ambientes de programação. Não contam para a capacidade do seu inquilino. Os ambientes de programação que não são utilizados há 90 dias são automaticamente desativados e, em seguida, removidos do inquilino se o proprietário não responder às notificações. As aplicações do Dynamics 365 não estão disponíveis em ambiente de programação.
Avaliação	Estes ambientes destinam-se a suportar testes e provas de conceito a curto prazo. Estão limitados a um por utilizador. Os ambientes de avaliação são automaticamente removidos do seu inquilino após um curto período de tempo.
Microsoft Dataverse for Teams	Estes ambientes são criados automaticamente quando cria uma aplicação no Teams ou instala uma aplicação a partir do catálogo de aplicações. O modelo de segurança para estes ambientes alinha-se com a equipa à qual estão associados.
Suporte	Estes são ambientes especiais criados pelo Microsoft Suporte para permitir que os engenheiros solucionem problemas. Estes ambientes não contam para a capacidade do seu inquilino.

À medida que cria uma estratégia de ambiente de inquilino global, os diferentes tipos são relevantes para suportar as recomendações de estratégia.

Ambientes Geridos

Os ambientes têm um conjunto base de funcionalidades e caraterísticas, dependendo do tipo de ambiente. Os Ambientes Geridos expandem as caraterísticas base para fornecer um conjunto de capacidades premium que permitem aos admins gerir mais facilmente o Power Platform em escala com mais controlo, menos esforço e mais informações. Estas capacidades são desbloqueadas quando define um ambiente como gerido.

A tabela que se segue lista as caraterísticas de Ambientes Geridos que estão disponíveis, até ao momento em que este artigo foi escrito. São adicionadas novas caraterísticas com frequência, por isso, consulte a documentação para obter a lista mais recente. Embora todas as caraterísticas possam ajudá-lo a criar uma estratégia de ambiente, as caraterísticas em itálico são mais relevantes para a estratégia descrita neste artigo.

Mais visibilidade	Mais controlo	Menos esforço
Informações de uso Resumo do administrador Relatórios de licença Vista de política de dados Exportar dados para o Azure Application Insights Descrições geradas por IA para todos os aplicativos	Limites de partilha Políticas de dados para fluxos de desktop Verificador de soluções Conteúdo de boas-vindas do Maker Firewall IP Ligação de cookies IP Chaves gerenciadas pelo cliente Cofre do Cliente Backups estendidos	Fácil ativação Power Platform gasodutos Roteamento de ambiente Grupos e regras ambientais Power Platform consultor

Reivindicação automática de licenças

As políticas de reivindicação automática automatizam a atribuição e Power Apps as licenças aos usuários quando eles precisam de Power Automate um para usar determinados aplicativos ou recursos. A automatização pode ajudar a reduzir o número de licenças consumidas e evitar a sobrecarga da atribuição manual de licenças.

Após a configuração de uma política, qualquer utilizador na organização que necessite de uma licença do Power Apps individual recebe-a automaticamente sob as seguintes condições:

• Se um utilizador sem uma licença do Power Apps autónoma iniciar uma aplicação que exija uma licença premium, o sistema atribui automaticamente ao utilizador uma licença do Power Apps por utilizador.

• Se um utilizador sem uma licença do Power Apps autónoma iniciar uma aplicação num Ambiente Gerido, o sistema atribui automaticamente ao utilizador uma licença do Power Apps por utilizador.

Da mesma forma, após a configuração de uma política, qualquer utilizador na organização que necessite de uma licença do Power Automate individual recebe-a automaticamente sob as seguintes condições:

• O utilizador aciona, guarda ou ativa um fluxo de cloud premium com RPA (Automatização Robótica de Processos) assistida.

• O utilizador pede uma licença premium do Power Automate.

Recomendamos que configure a reivindicação automática de licenças se a sua estratégia de ambientes incluir Ambientes Geridos. Os utilizadores de aplicações e de fluxos encontram a menor fricção de licenciamento e só consomem licenças para utilizadores que estão a executar aplicações ou a utilizar o Power Automate ativamente.

Grupos e regras de ambiente

À medida que a adoção do Power Platform no seu inquilino aumenta, também o número de ambientes que requerem administração e governação. À medida que o número de ambientes aumenta, mais desafiante se torna garantir que aplicou definições e políticas de governação consistentes nos ambientes. A caraterística de grupos de ambiente facilita esta tarefa, permitindo-lhe criar grupos nomeados e associar ambientes a eles, tal como colocar documentos relacionados numa pasta de ficheiros.

Tenha em mente as seguintes considerações quando pensar em utilizar grupos de ambientes:

• Um ambiente tem de ser gerido para ser incluído num grupo.

• Um ambiente só pode estar num grupo de cada vez.

• Um ambiente pode ser movido de um grupo para outro.

• Os ambientes num grupo podem ser de várias regiões geográficas.

• Os grupos não podem conter outros grupos.

Para o ajudar a aplicar definições e governação consistentes, os grupos de ambientes podem ter uma ou mais das seguintes regras configuradas e ativadas:

• Controlos de partilha para aplicações de tela

• Informações de utilização

• Conteúdo de boas-vindas para criadores

• Imposição do verificador de soluções

• Retenção de cópias de segurança

• Descrições geradas por IA

Uma regra fica ativa quando é publicada. As regras ativas são aplicadas a todos os ambientes associados ao grupo.

Quando uma regra de grupo está a gerir uma definição, as definições individuais do ambiente são bloqueadas. A única maneira de alterá-las é modificar a regra. Se o ambiente for removido do grupo, mantém as definições do grupo, mas agora um administrador do ambiente pode alterá-las. Isto é importante para uma estratégia de ambiente, pois garante que um administrador de ambiente não pode substituir as políticas definidas para o grupo.

A utilização de grupos de ambientes permite-lhe organizar os ambientes de forma lógica, semelhante à estrutura, hierarquia de serviços de produtos da sua organização ou outras estruturas que exploraremos posteriormente. O diagrama a seguir é um exemplo conceptual de como a organização Contoso poderá pensar organizar os seus grupos de ambiente.

Figura: Conceituação de uma estratégia de ambiente para um locatário da Contoso.

Quando estiver a planear as regras a configurar, pense no que poderá aplicar em cada nível da hierarquia conceptual. Embora ainda não possa configurar a hierarquia de grupo, pode utilizar uma combinação de convenções de nomenclatura e configuração de regras para implementar o seu design conceptual. Por exemplo, considerando a conceptualização do inquilino da Contoso mostrada anteriormente, a ilustração a seguir representa os grupos de ambientes que a organização poderia utilizar para implementar a respetiva estrutura.

Figura: Exemplo de implementação dos grupos de ambiente conceitual no locatário real

Posteriormente neste artigo, exploramos mais formas de utilizar grupos de ambientes como parte de uma estratégia de ambiente de inquilino.

Encaminhamento de ambiente predefinido

Uma parte fundamental da estratégia de ambiente que descrevemos neste artigo é afastar os criadores da criação de recursos no ambiente predefinido. A caraterística de encaminhamento de ambientes redireciona os criadores para o respetivo ambiente de programação pessoal e cria novos ambientes de programação, conforme necessário.

Figura: um criador é automaticamente redirecionado para um ambiente pessoal ambiente de programação em vez do ambiente padrão ao criar aplicativos.

Os ambientes de programação criados por encaminhamento são geridos por predefinição. Os utilizadores com licenças do Plano de Programador estão limitados à criação e pré-visualização de recursos no ambiente. Para executar os recursos como utilizador, precisam de uma licença adequada.

Pode utilizar o encaminhamento de ambiente sozinho, mas a forma recomendada é utilizá-lo com grupos de ambientes. Quando utilizado desta forma, qualquer ambiente criado é associado ao grupo que designar para conter todos os novos ambientes de programação, garantindo que é imediatamente coberto pelas suas políticas de governação.

São atribuídos automaticamente aos criadores um direito de acesso que os torna administradores do ambiente do respetivo ambiente de programação. Quando o ambiente faz parte de um grupo de ambientes, o criador, como administrador do ambiente, não pode alterar as definições do ambiente porque são geridas pelas regras do grupo de ambientes. Apenas os admins, que podem modificar as regras de grupo, podem efetuar alterações.

Pode impor ainda mais controlo de duas maneiras. Primeiro, pode remover a permissão de criação manual de ambientes de programação nas definições do seu inquilino. Quando esta opção está definida, os criadores não podem criar ambientes no portal de administração. Também não terão um criado automaticamente pela política de encaminhamento. Em segundo lugar, pode especificar um grupo de segurança, na política de encaminhamento, para limitar quem pode obter automaticamente um ambiente criado.

Inicialmente, o encaminhamento de ambientes suporta o encaminhamento de criadores novos e existentes para longe do ambiente predefinido quando utilizam make.powerapps.com. Ao longo do tempo, outros serviços do Power Platform suportarão a caraterística de encaminhamento de ambientes.

Microsoft Dataverse

O Dataverse armazenar e gere dados em segurança que são utilizados por aplicações. No contexto de uma estratégia de ambiente, a caraterística da solução Dataverse é o que utiliza para transportar aplicações e componentes de um ambiente para outro. Os criadores criam os próprios recursos em contentores, soluções, que monitorizam o que criam. As soluções podem ser facilmente transportadas para outros ambientes. Com esta abordagem, pode separar ambientes de programação, onde os criadores criam recursos, dos ambientes de produção onde são utilizados. Tanto os criadores como os utilizadores são beneficiados. Os criadores podem continuar a evoluir os recursos e os utilizadores não são surpreendidos por alterações súbitas. Quando os criadores estiverem prontos para publicar as alterações, podem pedir para promover o recurso atualizado para o ambiente de produção.

As soluções do Dataverse são o mecanismo de implementação do ALM em produtos do Power Platform, como o Power Apps e o Power Automate. Os pipelines utilizam soluções do Power Platform para automatizar CI/CD de recursos criados pelos criadores. As soluções podem ser exportadas do Dataverse e armazenadas numa ferramenta de controlo de código fonte, como o Azure DevOps ou o GitHub. A solução no controlo de código fonte torna-se a origem da verdade se precisar de recriar o ambiente de programação. Por exemplo, se um criador criou uma aplicação popular e, em seguida, eliminou o ambiente de programação, uma solução exportada armazenada no controlo de código fonte poderia ser utilizada para recriar um ambiente de programação viável.

Outra consideração importante quando cria um ambiente com o Dataverse, é se alguma aplicação do Dynamics 365 será implementada no ambiente. Se o potencial existir, tem de ativar o Dynamics 365 quando criar o ambiente ou não conseguirá instalar aplicações do Dynamics 365 posteriormente.

Recomendamos que aprovisione o Dataverse em qualquer ambiente onde os criadores criem recursos que serão partilhados com outros utilizadores. Isto facilita que os recursos estejam prontos para ALM.

Soluções preferenciais

Quando um criador cria um recurso do Dataverse num ambiente do Dataverse, e não o inicia a partir de uma solução personalizada, o recurso é associado à solução predefinida e talvez também à solução predefinida Common Data Service. A solução predefinida é partilhada por todos os criadores que criam recursos no ambiente. Não existe uma forma fácil de identificar que criador criou que componentes ou que recursos pertencem a que aplicações. Isto pode dificultar a promoção de uma aplicação popular noutro ambiente para partilha com uma audiência maior. Teria de promover todos os recursos na solução predefinida, o que não é um cenário ideal.

Para suportar a sua estratégia de ambiente e facilitar o trabalho com ela, os criadores devem criar uma solução personalizada no ambiente de programação e, em seguida, defini-la como a solução preferencial no ambiente. Os criadores definem a solução preferencial num ambiente para indicar a solução à qual um recurso que criaram deve ser associado. As soluções preferidas podem ajudar a garantir que, quando os criadores utilizam pipelines para promover os seus recursos para outros ambientes, a solução promovida contém todos os recursos necessários. Pense nisto como preparar os recursos para estarem prontos para ALM.

Pipelines no Power Platform

Como vimos, um princípio fundamental de uma boa estratégia de ambiente é isolar onde um recurso é criado, a partir de onde é implementado e utilizado. Esta separação assegura que os utilizadores que estão a tentar utilizar um recurso não encontram tempo de inatividade porque um criador o está a atualizar. No entanto, requer que os recursos sejam promovidos para um ambiente de produção, idealmente, como parte de uma solução do Dataverse, antes de poderem ser utilizados.

As soluções do Dataverse podem ser transportadas manualmente entre ambientes. No entanto, pode automatizar o processo, e implementar políticas para garantir que ocorre uma gestão de alterações adequada, utilizando pipelines. Consoante as regras de ambiente que definir no verificador de soluções, os pipelines impõem automaticamente todas as regras antes de a solução ser implementada, evitando mais erros de implementação. O diagrama a seguir ilustra como os pipelines podem automatizar a promoção de um recurso desde o desenvolvimento até à produção.

Figura: Um pipeline automatiza a promoção de um ativo armazenado no controle do código-fonte desde o desenvolvimento, passando pelo teste, até a produção.

Pode configurar o número de ambientes e processos, como aprovações, que necessitam de ser incluídos num pipeline.

Os pipelines funcionam em conjunto com grupos de ambientes. Podem ser pré-configurados para ambientes de programação para permitir que os criadores iniciem facilmente o processo de promoção respondendo a um pedido quando tentam partilhar os seus recursos com outros utilizadores. Como parte de um pedido de implementação que utiliza pipelines, os criadores podem propor com quem partilhar os seus recursos e os direitos de acesso necessários. Um admin de pipelines pode aprovar ou rejeitar o pedido antes da implementação, garantindo privilégios mínimos para o criador que o originou.

Os pipelines armazenam Power Platform as definições de cada pipeline em um ambiente de host que Microsoft gerencia por padrão. No entanto, pode definir vários ambientes de anfitrião no seu inquilino que gere, permitindo-lhe lidar com requisitos exclusivos.

Catálogo no Power Platform

As organizações em que os programadores e os criadores criam e partilham componentes, tais como aplicações e fluxos, bem como modelos, que são pontos de partida mais avançados, tendem a obter mais valor do Power Platform. O Power Platform catálogo torna mais fácil para os fabricantes compartilharem seus componentes e modelos entre ambientes de forma mais eficaz.

O catálogo é instalado num ambiente e pode ser instalado com o anfitrião de pipelines no mesmo ambiente. Também é possível lidar com requisitos de segmentação de recursos exclusivos ao ter vários ambientes que têm um catálogo instalado.

Mapa de objetivos de caraterísticas

À medida Microsoft que continua a evoluir os recursos de governança e administração de suporte, você pode acompanhar o Power Platform planejador delançamento. Fica a saber o que está planeado, o que está para vir na próxima vaga de lançamento e o que pode experimentar agora. Pode até criar o seu próprio plano de lançamento, ao guardar os itens que pretende seguir.

Base de uma estratégia de ambiente de escala empresarial

Discutimos a nossa visão para uma estratégia de ambiente de inquilino à escala empresarial e as principais caraterísticas de ambiente que a suportam. Agora, vemos como pode utilizar essas caraterísticas em conjunto como parte de uma estratégia de ambiente. A sua estratégia deve basear-se nos requisitos exclusivos da sua organização, por isso, vamos começar com um exemplo básico antes de passarmos à forma de adaptar uma estratégia para satisfazer as suas necessidades.

Neste exemplo, a liderança da Contoso pretende capacitar os colaboradores para tirarem partido do Power Platform e identificou os seguintes requisitos de alto nível:

• Os colaboradores precisam de ser capazes de criar processos automatizados de aprovação de documentos e outras personalizações do Power Platform com o Microsoft 365.

• Os colaboradores devem ser capazes de criar automatizações do Power Apps e do Power Automate para melhorar a produtividade pessoal.

• Os criadores que estão a trabalhar na aplicação Monitorizador de Conformidade da empresa têm de conseguir desenvolvê-la e mantê-la.

Para suportar estes requisitos, a equipa de administração e governação da Contoso criou a seguinte topologia de ambiente:

Figura: Topologia de ambiente proposta para o projeto em escala da Power Platform Contoso.

Vamos explorar este diagrama de topologia de ambiente em detalhe.

O ambiente predefinido é utilizado para criar personalizações de produtividade do Microsoft 365. As políticas de prevenção de perda de dados e as restrições à partilha limitam outros tipos de atividade de criador e colocam proteções à volta do que os criadores podem criar neste ambiente.

Apenas os admins podem criar ambientes de avaliação, sandbox e produção. Os criadores usam um formulário personalizado Microsoft ou outro processo para solicitar um novo ambiente. O Kit de Iniciação do Centro de Excelência (CoE) do Microsoft Power Platform inclui um pedido de ambiente que pode ser utilizado.

São criados quatro grupos de ambientes: Programação, Programação Partilhada, UAT (testes de aceitação de utilizador) e Produção.

• Uma política de encaminhamento de ambiente definida para o grupo Programação encaminha os criadores do ambiente predefinido para os respetivos ambientes de programação. À medida que novos ambientes de programação são criados, são automaticamente associados ao grupo Programação e aplicam-se as regras respetivas.

• O grupo Programação Partilhada suporta ambientes que contêm projetos com vários criadores.

• O grupo UAT contém ambientes que são utilizados para testar recursos antes de serem promovidos para produção.

• O grupo Produção contém ambientes que alojam aplicações, fluxos e outros artefactos para utilização em produção.

O que está a faltar a esta topologia proposta são pipelines para automatizar a promoção entre ambientes de programação, teste e produção. Vamos adicioná-los agora.

Figura: A mesma topologia de ambiente com pipelines conectando um ambiente de host de pipeline a ambientes de desenvolvimento, teste e produção.

No diagrama de topologia de ambiente revisto, adicionámos um ambiente anfitrião de pipelines e dois pipelines. Um pipeline move recursos de programação para teste e, em seguida, para ambientes de produção. A regra de pipeline no grupo Programação será modificada para utilizar este pipeline. O outro pipeline move recursos do ambiente de programação partilhada para teste e, em seguida, para produção. A regra de pipeline no grupo Programação Partilhada será modificada para utilizar este pipeline.

Esta estratégia de ambiente básica fornece uma base que pode desenvolver para outros casos de utilização, que exploraremos em seguida.

Estratégias de ambiente para cenários específicos

Seguem-se alguns casos de utilização comum que poderá ter de incorporar na estratégia de ambiente de inquilino da fundação.

Controlar que criadores podem criar ambientes de programação

Por predefinição, qualquer pessoa que tenha uma licença do Power Platform Premium, uma licença do Plano de Programador ou uma função de admin de inquilinos do Power Platform, pode criar um ambiente de programação a partir do portal de administração.

Na estratégia do ambiente de base, o encaminhamento de ambiente garante que os criadores são direcionados para longe do ambiente predefinido para um novo ambiente de programação criado no grupo designado. No entanto, os criadores continuam a poder criar manualmente ambientes de programação que não estejam colocados num grupo de ambientes e que não tenham as respetivas regras aplicadas.

Para refinar que criadores são elegíveis para encaminhamento de ambientes, especifique um grupo de segurança na configuração de encaminhamento. Quando um grupo de segurança é configurado, apenas os membros do grupo de segurança são encaminhados. Todos os outros revertem para o ambiente predefinido.

Fornecer mais flexibilidade a criadores avançados

Na estratégia do ambiente de base, todos os novos ambientes de criador são encaminhados para um grupo de ambientes de programação designado. Normalmente, este grupo de ambientes tem um conjunto bastante restritivo de regras de governação aplicadas.

À medida que os criadores se tornam mais avançados, pode permitir-lhes pedir acesso a mais capacidades. Em vez de os remover do grupo de ambientes original e gerir manualmente a exceção, pode utilizar outro grupo de ambientes para monitorizar estes criadores avançados.

Figura: Adicione criadores mais capazes a um ambiente que flexibilizou as regras de governança.

Organizar ambientes de programação por região ou unidade de negócio

Na implementação atual do encaminhamento de ambientes, todos os novos ambientes de programação são criados num único grupo de ambientes. E se pretender organizar os ambientes de programação dos seus criadores por região ou unidade de negócio, por exemplo?

Utilize o encaminhamento para direcionar os criadores para um novo ambiente de programação criado no grupo designado. Em seguida, pode movê-lo para outro grupo que esteja baseado na região, unidade organizacional ou outros critérios, onde pode aplicar regras de governação mais granulares.

Figura: Depois que o roteamento de ambiente criar ambientes de desenvolvedor no grupo designado, mova-os para grupos estruturalmente mais específicos.

Atualmente, mover ambientes é uma ação manual, mas poderá automatizá-la quando o conector de administração do Power Platform suportar a caraterística de grupo numa atualização futura.

Desenvolver uma aplicação para utilização empresarial

Uma equipa na sua organização pode estar a desenvolver uma aplicação para utilização em toda a empresa. A equipa pode ser orientada para TI ou incluir utilizadores de empresa e de TI (o que é conhecido como uma equipa de fusão).

Na estratégia de ambientes mais simples, a equipa do projeto cria num ambiente partilhado que é um tipo de sandbox ou de produção. Um tipo de ambiente de programação não é a melhor forma de suportar a colaboração de vários criadores num recurso. No entanto, os criadores precisam de comunicar uns com os outros para evitar colisões e conflitos no ambiente partilhado.

Não são necessários ambientes de teste nem de produção dedicados. A aplicação pode ser testada e implementada em ambientes de teste e de produção ao nível da organização que alojam várias aplicações.

Figura: Dois aplicativos corporativos em desenvolvimento em ambientes dedicados e, em seguida, testados e implantados em ambientes compartilhados com outros aplicativos.

Numa variação mais avançada, cada criador tem um ambiente de programação individual. Isto tem a vantagem de proporcionar um maior isolamento ao criador, mas pode tornar mais complicada a combinação do trabalho individual num ambiente de integração. Embora trabalhar em isolamento possa ser útil para equipas maiores e sofisticadas, pode adicionar sobrecarga desnecessária a equipas mais pequenas que podem ter mais sucesso ao colaborar num ambiente de programação partilhada.

Figura: Dois criadores que trabalham no mesmo aplicativo em ambientes de desenvolvedor individuais devem combinar seu trabalho em um ambiente de integração compartilhado antes que ele passe para teste e produção.

Normalmente, esta variação incorpora uma estratégia de controlo de código fonte, com cada ambiente de programação representado como um ramo no controlo de código fonte, que é unido quando as alterações estão prontas para serem promovidas. É importante ter em conta como a aplicação será mantida após o lançamento inicial.

Por exemplo, a versão 1.0 da aplicação pode estar em produção enquanto a equipa se move para a criação da versão 2.0. A sua estratégia de ambiente tem de suportar a correção de um problema na versão 1.0, enquanto o desenvolvimento da versão 2.0 está em curso.

Figura: A versão 1.0 deve ser corrigida, testada e implantada enquanto a versão 2.0 está a ser desenvolvida, testada e implantada.

Os grupos de ambientes oferecem várias abordagens para lidar com este cenário de aplicações empresariais. Por exemplo, pode tratar-se de um único grupo de aplicações ou pode envolver ter grupos separados para cada fase de desenvolvimento. Na secção de melhores práticas, exploramos como avaliar as opções.

Minimizar a utilização de ambientes de programação

Os ambientes de programação individuais são a forma recomendada de fornecer aos criadores uma área de trabalho para criar soluções de low-code. Oferecem o mais alto nível de isolamento de outros criadores. Mas se a sua organização pretender minimizar o número de ambientes de programação, vários ambientes partilhados são melhores do que encorajar os criadores a criarem recursos no ambiente predefinido.

Neste cenário, restringiria a criação de ambientes de programação e criaria ambientes de programação partilhados do tipo de produção. Pode organizar estes ambientes partilhados por estrutura organizacional, região ou outros critérios. Um grupo de ambientes pode contê-los para garantir que têm regras de governação consistentes aplicadas. Conceda permissão aos criadores para criarem recursos de low-code no ambiente que lhes é atribuído.

Segurança como parte da sua estratégia de ambiente

Os ambientes são um componente-chave da utilização do Power Platform em segurança. Representam limites de segurança no seu inquilino que ajudam a proteger aplicações e dados. Como parte da estratégia de ambiente, tem de considerar como os requisitos de segurança influenciam o número e a finalidade dos ambientes no inquilino.

Os ambientes permitem-lhe criar vários limites de segurança no seu inquilino para proteger aplicações e dados. A proteção fornecida pelo ambiente pode ser ajustada para satisfazer a proteção de segurança necessária ao aplicar um conjunto configurável de recursos de segurança no ambiente. Uma discussão detalhada dos recursos de segurança do ambiente individual está para além do âmbito deste artigo. No entanto, nesta secção, oferecemos recomendações sobre como pensar na segurança como parte da estratégia de ambiente do inquilino.

Segurança ao nível do inquilino

A maioria das definições de segurança que afetam os ambientes são configuradas individualmente para cada ambiente. No entanto, pode efetuar algumas alterações ao nível do inquilino para ajudar a suportar a sua estratégia de ambiente.

• Considere desativar a caraterística Partilhar com Todos no Power Platform. Só os admins poderão partilhar um recurso com todos.
• Considere proteger a integração com o Exchange.
• Aplique o isolamento entre locatários para ajudar a minimizar o risco de exfiltração de dados entre locatários.
• Restringir a criação de novos ambientes de produção na rede aos administradores. Limitar a criação de ambientes é benéfico para manter o controle em geral: tanto para evitar o consumo de capacidade não contabilizado quanto para reduzir o número de ambientes a serem gerenciados. Se os utilizadores têm de pedir ambientes a partir da TI Central, é mais fácil ver aquilo em que pessoas estão a trabalhar se os administradores forem o controlador de chamadas.

Proteger o ambiente predefinido

O ambiente predefinido tem uma função no suporte a personalizações de produtividade do Microsoft 365. No entanto, como parte da estratégia de ambiente recomendada, é melhor minimizar a sua utilização o máximo possível. Em vez disso, os criadores devem criar nos seus próprios ambientes isolados. Apesar de não poder bloquear o acesso ao ambiente predefinido, pode minimizar o que pode ser feito nele.

Em primeiro lugar, utilize o encaminhamento de ambiente para direcionar os criadores para a sua própria área de trabalho para criar recursos de low-code.

• Reveja quem tem acesso de administrador ao ambiente predefinido e limite-o às funções que necessitam dele.

• Considere mudar o nome do ambiente predefinido para algo mais descritivo, como "Produtividade Pessoal".

  • Estabeleça uma política de prevenção de perda de dados (DLP) para o ambiente predefinido que bloqueie novos conectores e restrinja os criadores para utilizarem apenas conectores básicos não bloqueáveis. Mova todos os conectores que não podem ser bloqueados para o grupo de dados de negócio. Mova todos os conectores bloqueáveis para o grupo de dados bloqueado.

  • Crie uma regra para bloquear todos os padrões de URL usados por conectores personalizados.

Proteger o ambiente predefinido deve ser uma prioridade. Faça-o juntamente com a segurança ao nível do inquilino como parte do primeiro passo na implementação da sua estratégia de ambiente. Sem estas serem implementadas, os criadores têm mais oportunidades de adicionar recursos ao predefinido. Com eles em vigor, juntamente com o encaminhamento de ambientes, os criadores são encorajados a utilizar o seu próprio ambiente.

Proteger outros ambientes

Se a sua organização for como a maioria, tem vários ambientes para além do ambiente predefinido. O nível de segurança que cada um requer pode variar consoante as aplicações e os dados que contiver. Normalmente, os ambientes de programação têm regras mais relaxadas do que os ambientes de produção. Alguns ambientes de produção requerem a maior proteção possível.

Como parte do estabelecimento da sua estratégia de ambiente, identifique níveis comuns de segurança para os seus ambientes e as caraterísticas que protegem cada nível, como no exemplo a seguir.

Figura: Um exemplo de três camadas de segurança de ambiente e os recursos de segurança que se aplicam a ambientes em cada camada.

Incorpore os níveis de segurança identificados na sua estratégia de grupo e, sempre que possível, utilize regras para ativar as caraterística de segurança nos seus ambientes. Neste exemplo, uma regra limita a partilha em todos os ambientes designados como segurança normal ou média.

Alinhar ambientes com a sua estratégia de prevenção de perda de dados

As políticas de dados são outra parte importante de um esforço de governação global para controlar os serviços utilizados por recursos de low-code num ambiente. Os grupos de ambientes não têm uma regra para aplicar uma política DLP a um ambiente. No entanto, pode alinhar a sua estratégia de DLP com os seus grupos de ambientes. Por exemplo, pode criar uma política DLP com o mesmo nome, ou semelhante, que um grupo de ambientes e aplicá-la aos ambientes desse grupo.

Saiba mais sobre como estabelecer uma estratégia DLP.

Figura: Neste exemplo, os ambientes no grupo Desenvolvimento Pessoal seguem uma política de DLP que bloqueia todos os não-conectoresMicrosoft .

Adaptar uma estratégia de ambiente para a sua organização

Nas secções anteriores, descrevemos a nossa visão sobre a forma como as organizações podem gerir ambientes em escala. Explorámos recursos essenciais, como estes contribuem para uma estratégia de ambiente e qual o aspeto de uma topologia de ambiente de fundação que os utiliza. Demos exemplos de como criar essa base para acomodar cenários comuns. Uma vez que cada organização é única, o passo seguinte é personalizar uma estratégia de ambiente que vá ao encontro das necessidades da sua organização.

Comece onde está

Quer a sua organização seja nova no Power Platform ou já a utilize há anos, o primeiro passo é avaliar a sua situação. Avalie, a um nível alto, o que se encontra no seu ambiente predefinido, que outros ambientes tem e para que estão a ser utilizados. Muitas vezes, uma estratégia de ambiente é feita como parte de um esforço global para estabelecer a governação do Power Platform numa organização. Se for o caso, poderá já ter estabelecido alguma da visão de governação necessária para adaptar uma estratégia para a sua organização.

As informações da organização que deve conhecer incluem:

• Qual a visão de como o Power Platform será utilizado na organização?

• Quem na organização irá criar recursos de low-code?

Precisa de tomar algumas decisões importantes:

• Como é que os criadores irão obter novos ambientes?

• Vai agrupar os seus ambientes e, em caso afirmativo, como?

• Que níveis de segurança são necessários para diferentes ambientes e como é que os ambientes são classificados?

• Como decidirá se uma aplicação, automatização ou o Copilot utilizará um ambiente existente ou novo?

• Existem lacunas entre as caraterísticas base da plataforma e os seus requisitos que exijam um processo de governação personalizado?

• Como irá processar os recursos existentes no ambiente predefinido?

• Tem uma estratégia de política DLP de inquilino e de ambiente e, em caso afirmativo, de que forma está alinhada com a estratégia de ambiente que está a criar?

Também poderá encontrar alguma inspiração nos modelos operativos de cloud que fazem parte do Cloud Adoption Framework for Azure.

Preencher lacunas com a plataforma

Encontrará quase sempre requisitos que as capacidades incorporadas da plataforma não satisfazem. Ao avaliar essas lacunas, considere os seguintes resultados possíveis da sua avaliação:

• A lacuna é aceitável.

• A lacuna pode ser preenchida utilizando o Kit de Iniciação do Centro de Excelência do Power Platform.

• A lacuna pode ser preenchida utilizando as capacidades da plataforma, tais como APIs, conectores e aplicações personalizadas ou automatizações.

• A lacuna pode ser preenchida utilizando uma ferramenta ou aplicação de terceiros.

Kit de Iniciação CoE

O Kit de Iniciação do Centro de Excelência do Power Platform é uma coleção de componentes e ferramentas concebidos para ajudar a sua organização a adotar e suportar a utilização do Power Platform. Um aspeto-chave do kit de iniciação é a capacidade de recolher dados sobre a utilização da plataforma nos seus ambientes que podem ser úteis à medida que desenvolve e evolui a sua estratégia de ambiente.

Por exemplo, o dashboard Ambientes do Power BI oferece uma descrição geral que o ajuda a compreender que ambientes existem no inquilino, quem os criou e que recursos contêm.

Figura: O painel Ambientes em Power BI.

O kit inclui pontos de partida ou de inspiração, tal como um processo que os criadores podem utilizar para pedir novos ambientes e alterações às políticas DLP para os respetivos ambientes.

Figura: Fluxograma ilustrando um processo de gerenciamento de ambiente no CoE Starter Kit.

Programação e extensibilidade da plataforma

Um dos melhores aspetos de uma plataforma de low-code é que pode utilizá-la para criar aplicações, automatizações, portais e copilotos para o ajudar a geri-la. Também tem acesso a ferramentas de nível inferior que podem ser utilizadas para preencher lacunas no suporte à sua estratégia de ambiente.

Pode utilizar os seguintes conectores para criar aplicações e fluxos:

• Power Platform for Admins e Power Platform for Admins V2

• Power Apps for Admins e Power Apps para Makers

• Power Automate Gestão

Pode utilizar a interface de linha de comandos (CLI) do Power Platform para desenvolver automatizações para o ajudar a gerir o ciclo de vida do ambiente e outras tarefas relacionadas com práticas de DevOps.

Com cmdlets do PowerShell para criadores e administradores do Power Platform, pode automatizar várias das tarefas de monitorização e gestão.

O SDK de DLP do Power Platform pode ajudar a gerir as suas políticas de prevenção de perda de dados de inquilino e ambiente.

Recomendações de melhores práticas

Nesta secção do artigo, baseamo-nos nas recomendações das secções básicas e específicas do cenário.

Novos ambientes

Como parte do desenvolvimento da sua estratégia, considere quando cria ambientes para suportar uma carga de trabalho. A sua avaliação tem de equilibrar os benefícios do isolamento que um ambiente oferece, por exemplo, ser capaz de bloquear ambientes específicos mais do que outros é útil do ponto de vista da segurança, com as desvantagens, como o facto de o isolamento criar fricção para os utilizadores que tentam partilhar dados entre aplicações.

Quando estiver a avaliar se uma aplicação ou uma automatização pertence ao seu próprio ambiente, avalie as diferentes fases do ciclo de vida da aplicação separadamente. Durante o desenvolvimento, o isolamento de outras aplicações é importante. Quando várias aplicações são desenvolvidas num único ambiente, corre o risco de criar dependências entre aplicações.

Como recomendação geral, quando possível, os ambientes de desenvolvimento devem ser de finalidade única, descartáveis e facilmente recriados.

Testar várias aplicações no mesmo ambiente faz sentido se forem executadas em conjunto em produção. Na verdade, se não testar com as aplicações que serão executadas em produção, corre o risco de não descobrir problemas de compatibilidade.

Ao avaliar o ambiente de produção de uma aplicação, tenha em mente as seguintes considerações:

• A aplicação é compatível com as aplicações existentes no ambiente? Por exemplo, duas aplicações que utilizam a tabela Contacto do Dataverse para finalidades diferentes podem não ser compatíveis. As aplicações são compatíveis do ponto de vista da política DLP?

• Existem requisitos regulamentares ou de conformidade especiais para a separação de dados? Por exemplo, a sensibilidade dos dados requer que sejam isolados? Existe algum requisito para que os dados não possam ser incluídos com outros dados?

• Os dados são altamente confidenciais ou sensíveis? A transferência não autorizada causaria danos monetários ou reputacionais à organização? Isolar num ambiente separado pode permitir um maior controlo sobre a segurança.

• A aplicação precisa de dados de outras aplicações e precisa de ser colocada com eles? Por exemplo, duas aplicações que utilizam a sua tabela Cliente devem ser alojadas juntas. Separá-los criaria cópias de dados redundantes e criaria problemas com a manutenção dos dados.

• Os dados requerem residência dos dados regional? Em alguns cenários, a mesma aplicação ou automatização pode ser implementada em ambientes regionais para garantir o isolamento e a residência dos dados adequados.

• A maioria dos utilizadores está na mesma região que o ambiente? Se o ambiente estiver na EMEA, mas a maioria dos utilizadores da aplicação estiver baseada nos EUA, a partilha de um ambiente pode não fornecer o melhor desempenho.

• Serão necessários novos administradores ou os administradores existentes serão suficientes? Se a nova aplicação necessitar de mais administradores, são compatíveis com os administradores existentes, porque todos eles terão permissões de administrador em todas as aplicações no ambiente?

• Qual é a esperança de vida da aplicação? Se a aplicação ou automatização for temporária ou de curta duração, pode não ser boa ideia instalá-la num ambiente com aplicações mais permanentes.

• Os utilizadores terão dificuldade em ter de utilizar vários ambientes para aplicações diferentes? Isto pode afetar tudo, desde encontrar uma aplicação no dispositivo móvel até relatórios de gestão personalizada que têm de solicitar dados de vários ambientes.

Capacidade

Cada ambiente (além dos ambientes de avaliação e de programador) consume 1 GB para o aprovisionamento inicial. A capacidade é partilhada por todo o inquilino, pelo que tem de ser alocada a quem precisa.

Conservar a capacidade ao:

• Gerir ambientes de produção e teste partilhados. Ao contrário dos ambientes de desenvolvimento partilhados, as permissões nos ambientes de teste e produção devem limitar-se ao acesso de utilizador para testes.
• Automatizar a limpeza dos ambientes de desenvolvimento temporários e incentivar a utilização de ambientes de avaliação para testes ou trabalhos de prova de conceito.

Grupos de ambientes

Os grupos de ambientes são flexíveis e permitem-lhe acomodar vários casos de utilização exclusivos das suas organizações. Eis algumas formas em que poderia considerar o agrupamento de ambientes como parte da sua estratégia de ambiente:

• Por serviço ou componente; por exemplo, uma árvore de serviço do ServiceNow

• Programação, teste e produção

• Departamentos, grupos empresariais ou centros de custos

• Por Projetos

• Por localização, se a maioria dos ambientes numa localização tiver necessidades de governação semelhantes; isto também pode ajudar a satisfazer conformidade regulamentar regional e conformidade legal

Figura: Os grupos de ambiente para dois departamentos diferentes têm regras diferentes.

Nomeando ambientes e grupos

Como parte da sua estratégia, considere como os ambientes e os grupos são nomeados.

• Os nomes dos ambientes são visíveis para admins, criadores e utilizadores. Normalmente, apenas os admins utilizam grupos de ambientes, mas os criadores poderão deparar-se com ele se tiverem privilégios para criar ambientes.

• Os ambientes de programação criados automaticamente seguem o padrão Ambiente do <nome de utilizador>; por exemplo, "Ambiente da Avery Howard". Os grupos de ambientes não são nomeados automaticamente.

• Os nomes do ambiente e do grupo de ambientes não precisam de ser exclusivos. No entanto, para evitar confusões, é recomendável evitar nomes duplicados.

• Os nomes estão limitados a 100 carateres. Nomes mais curtos são mais fáceis de utilizar.

Estabeleça uma convenção de nomenclatura consistente.

• Nomes consistentes ajudam os administradores a saber qual é o propósito do grupo e que ambientes gere, além de facilitar a automação e os relatórios.

• Uma prática comum é incluir a fase do ciclo de vida no nome de um ambiente; por exemplo, Contoso Prog, Contoso Teste, Contoso Prod. O objetivo é separar claramente ambientes com o mesmo conteúdo, mas com finalidades diferentes.

• Outra prática comum é incluir o departamento ou a unidade de negócio no nome quando o ambiente é dedicado a esse grupo de utilizadores.

• Por exemplo, poderá decidir que todos os nomes de ambiente ou grupo de ambientes têm de seguir o padrão <fase de ciclo de vida>-<região>-<unidade de negócio>-<finalidade> (Prod-US-Finance-Payroll).

Mantenha os nomes curtos, significativos e descritivos.

Pense em como os seus grupos evoluirão e crescerão ao longo do tempo e certifique-se de que a sua convenção de nomenclatura pode acomodar essas necessidades em evolução.

Evite incluir informações confidenciais em nomes. Podem estar visíveis para qualquer pessoa que tenha acesso ao centro de administração.

Os recursos no ambiente predefinido

A sua estratégia de ambiente deve encorajar (ou impor) a utilização de ambientes pessoais de programação para reduzir o que é criado no ambiente predefinido. No entanto, deve olhar para o que os criadores já criaram no ambiente predefinido e avaliar como lidar com cada caso de utilização. É apropriado deixar no ambiente predefinido ou deve ser migrado para outro ambiente?

Uma parte fundamental da realização deste esforço de higiene é a identificação das aplicações que são amplamente utilizadas na sua organização e que devem ter o seu próprio ambiente de programação protegido, separado do ambiente de produção.

A tabela que se segue enumera exemplos de casos de utilização e ações de migração. Em última análise, a sua organização precisa de identificar os seus próprios casos de utilização e fatores de risco associados a deixar recursos no ambiente predefinido. Saiba mais sobre quando mover ativos do ambiente padrão.

Ambiente padrão	Ação de migração
Produtividade pessoal do Microsoft 365	Mantenha-se no ambiente predefinido.
Recursos com um único criador que foram utilizados recentemente, mas não são partilhados	Mover para o ambiente de programação individual do proprietário.
Recursos com um único criador que foram utilizados recentemente e são partilhados	Mover para o ambiente de programação individual do proprietário e executar a partir de um ambiente de produção partilhado.
Recursos com vários criadores que foram utilizados recentemente e são partilhados	Mover para um ambiente de programação partilhado e executar a partir de um ambiente de produção partilhado.
Recursos que não foram utilizados recentemente	Notifique o proprietário e mova para a quarentena se não houver resposta.

Recursos em ambientes no Dataverse for Teams

Microsoft Dataverse for Teams permite que os usuários criem aplicativos, bots e fluxos Microsoft Teams personalizados usando Power Apps, Microsoft Copilot Studio e Power Automate. Quando um dono de equipa adiciona esta capacidade à sua equipa, é criado um ambiente Microsoft Power Platform com base de dados Dataverse for Teams e ligado à sua equipa. Saiba como estabelecer políticas de governança para gerenciar Microsoft Dataverse for Teams ambientes.

Estratégia ambiental interna na Microsoft

Microsoft considera-se "Cliente Zero", uma vez que adota Power Platform internamente para impulsionar a automação e a eficiência entre os seus colaboradores. Os números a seguir fornecem uma ideia da escala de uso entre Microsoft locatários internos.

• 50.000-60.000 criadores ativos todos os meses

• Mais de 250.000 aplicações e mais de 300.000 fluxos

• Mais de 20.000 ambientes

Microsoft está a mudar de sua estratégia ambiental anterior para uma que usa os recursos de governança mais recentes Power Platform , incluindo Ambientes Geridos, grupos ambientais e regras.

Como parte dos planos de estratégia Microsoft aprimorados para agrupar cenários com base no tipo de desenvolvimento, propriedade organizacional e nível de risco. Como muita coisa está a ser criada em toda a empresa, é muito difícil concentrar-se em todos os cenários possíveis e personalizar para cada caso de utilização. Há muita coisa a acontecer e ele precisa de ser automatizado e utilizar o maior número possível de controlos prontos para utilização.

Microsoft está a estruturar seus Power Platform ambientes em três categorias mais amplas que abrangem sete casos de uso, refletindo diferentes graus de risco e controle: produtividade pessoal, colaboração em equipa e desenvolvimento empresarial.

• Produtividade pessoal – Isso é para alguém que só quer criar um aplicativo ou fluxo para si mesmo. Por exemplo, não estão a colaborar com outros. Estes utilizadores são encaminhados para ambientes de programação pessoais, que estão bloqueados. Estes ambientes utilizam as caraterísticas do Ambiente Gerido, incluindo restringir a partilha e também controlar outras coisas que pode fazer nos ambientes. Os conectores e as ações disponíveis estão fortemente restringidos neste grupo de ambientes. Estes ambientes são os menos arriscados. A utilização de ambientes fechados e pessoais permite que os utilizadores evitem o processo de conformidade mais rigoroso apenas para criar aplicações e fluxos de produtividade pessoais.

• Colaboração em equipa – Isso é para usuários que estão a criar ferramentas, automação e processos para sua equipa. Para este cenário,incentiva Microsoft o uso de Dataverse for Teams ambientes. O ciclo de vida, a gestão de acessos e a etiquetagem de dados são controlados ao nível do grupo do Microsoft 365, pelo que não temos de perder tempo a gerir estes utilizadores de uma perspetiva de governação do Power Platform. Este nível de utilização é o próximo passo no espectro de risco.

• Desenvolvimento empresarial/nível de produção usado por todos os funcionários – São pessoas construindo ferramentas ou soluções usadas de forma mais ampla em toda a empresa. Estes ambientes podem armazenar os dados mais confidenciais, utilizar conectores mais potentes e requerer mais governação. Este é considerado o risco mais elevado e a maior parte do esforço é despendido na governação. O ALM é necessário, com o trabalho de pré-produção a acontecer em ambientes de sandbox e só as soluções geridas são permitidas nos ambientes de produção. Estes ambientes têm de ser vinculados ao ServiceTree, que impõe revisões recorrentes de segurança e privacidade. As regras do grupo de ambientes são personalizadas com base em metadados e sinais do ServiceTree. Muitos grupos de ambientes e regras são utilizados para gerir e controlar estes ambientes.

MicrosoftA estratégia de governança não é estática. É fluido e muda para se adaptar a novos desafios e incorporar novas caraterísticas do Power Platform.

Evoluir a sua estratégia de ambiente de inquilinos

Neste artigo, descrevemos como estabelecer uma estratégia de ambiente de inquilinos de escala empresarial. A estratégia pode crescer com o seu negócio, independentemente de onde está a começar no percurso. Organizações de qualquer dimensão podem beneficiar da estratégia que apresentamos; no entanto, para organizações que já estão em maior escala, os benefícios são maiores.

Desenvolver uma estratégia de ambiente de inquilinos não é uma atividade única. É um percurso. Deve evoluir a sua estratégia ao longo do tempo à medida que as suas necessidades mudam. A sua estratégia também deve ser ajustada para adotar novos recursos da plataforma e enfrentar novos desafios.

Como todos os percursos, diferentes organizações aderem em diferentes pontos ao longo do caminho, mas todas têm o mesmo destino em mente. Seguem-se possíveis rampas que representam onde a sua organização está atualmente.

Iniciar

A sua organização está no início do percurso para a adoção do Power Platform. Isto denomina-se frequentemente como greenfield. Está a iniciar o seu percurso no melhor local porque não tem de se preocupar com os ambientes existentes nem com o impacto que as novas políticas podem ter na forma como as pessoas da sua organização estão a utilizar o Power Platform. Este é o melhor momento para implementar uma estratégia de ambiente de escala empresarial que esteja alinhada com as caraterísticas do produto e as melhores práticas.

Explore as principais caraterísticas e estratégias de ambiente descritas neste artigo. Aproveite para compreender os temas-chave e as considerações e decisões que precisa para projetar e implementar uma estratégia de ambiente de inquilinos que melhor se adapte aos seus requisitos.

Estabelecer uma base sólida agora é essencial para evitar ter de lidar com uma situação fora de controlo que pode ocorrer mais tarde se começar sem uma estratégia definida. Planeie a aceleração rápida da sua utilização do Power Platform, mas evite a tentação de projetar em excesso a sua estratégia de ambiente, adicionando complexidade que não é necessária. Lembre-se, este é um percurso e pode continuar a evoluir a sua estratégia à medida que as suas necessidades mudam.

Align

A sua organização tem e está a executar uma estratégia de ambiente que precisa de ser modificada para se alinhar com novas caraterísticas e melhores práticas do Power Platform. Isto denomina-se frequentemente como brownfield. Ao contrário das organizações que estão agora a começar, precisa de considerar o impacto na sua organização da mudança da sua estratégia de ambiente.

Explore as principais caraterísticas e estratégias do ambiente descritas neste artigo e avalie o que é necessário para evoluir a sua estratégia para que esteja mais alinhada. Normalmente, tudo o que é necessário são ajustes incrementais. Quando possível, planeie o lançamento de alterações para minimizar o impacto nos seus utilizadores.

As seguintes sugestões são alterações incrementais comuns que poderia implementar:

• Para iniciar o alinhamento sem afetar os ambientes existentes, crie um grupo de ambientes que contenha novos ambientes de programação e estabeleça regras para a forma como pretende governá-los. Ative o encaminhamento de ambientes para garantir que todos os novos ambientes de programação são criados no grupo designado.

• Avalie a sua estratégia de agrupamento e, se necessário, crie grupos para suportar os ambientes existentes. Estabeleça regras nesses grupos que se alinhem com as restrições e exceções existentes. Mova os ambientes existentes para esses grupos.

• Identificar aplicações amplamente populares que são criadas e utilizadas no ambiente predefinido. Utilize pipelines para os publicar num ambiente de produção onde os utilizadores da sua organização possam executá-los. Em seguida, trabalhe na migração do desenvolvimento dessas aplicações para um ambiente de programação individual ou para um ambiente de programação dedicado.

• Crie um plano para identificar, colocar em quarentena e remover recursos no ambiente predefinido que não estejam a ser utilizados.

Melhorar

A estratégia de ambiente que está a executar já está alinhada com as caraterísticas e as melhores práticas mais recentes, mas a sua organização pretende adicionar mais controlos ou caraterísticas.

Comunicar a estratégia de ambiente à sua organização

Implementa a sua estratégia de ambiente de inquilinos com mais sucesso se os seus utilizadores do Power Platform compreenderem e estiverem alinhados com o que está a tentar alcançar. Se ativar simplesmente a sua estratégia sem qualquer comunicação, os utilizadores verão as alterações como restrições e procurarão maneiras de contorná-las.

Como parte do desenvolvimento ou evolução da sua estratégia, decida como informar os utilizadores sobre os elementos-chave da estratégia que afetam a utilização do Power Platform. Não precisam de todos os detalhes técnicos da sua estratégia, apenas dos essenciais que ajudam a garantir que permanecem produtivos, como:

• O objetivo do ambiente predefinido

• Onde devem criar novos recursos de low-code

• Como devem utilizar o seu ambiente de programação pessoal

• Como pedir ambientes personalizados para unidades de negócio ou projetos específicos

• Políticas gerais de utilização de conectores e como pedir mais privilégios de conector para os respetivos ambientes

• Como partilhar o que criam com os outros

• As responsabilidades de um criador, por exemplo:

  • Manter o inquilino organizado. Eliminar os seus ambientes, aplicações e fluxos se já não forem necessários. Utilizar ambientes de teste se estiver a fazer experiências.

  • Partilhar com sensatez. Esteja atento à partilha excessiva dos seus ambientes, aplicações, fluxos e ligações partilhadas.

  • Proteger dados da organização. Evite mover dados de origens de dados confidenciais ou altamente confidenciais para armazenamento não protegido ou externo.

• Quando a sua estratégia mudar, partilhe como as alterações afetam os seus utilizadores, para que saibam o que fazer de forma diferente

Um bom começo é ativar o conteúdo de boas-vindas para criadores no grupo de ambientes onde são adicionados novos criadores.

Figura: Use o conteúdo de boas-vindas para ajudar os novos criadores a serem bem-sucedidos.

Outra abordagem eficaz para comunicar com os utilizadores é estabelecer um hub do Power Platform interno. O hub pode ser um lugar para as pessoas colaboram em projeto, partilharem ideias e descobrirem novas formas de aplicar a tecnologia para conseguir mais. O hub pode ser o local onde partilha informações mais detalhadas sobre a estratégia do ambiente que são relevantes para os utilizadores. Saiba como criar um hub Power Platform interno.

Conclusão

Neste artigo, exploramos caraterísticas concebidas para ajudar a sua organização a gerir ambientes do Power Platform em escala empresarial e incorporá-los na sua estratégia de ambientes de inquilinos.

À medida que a sua organização adota o Power Platform e a utilização acelera, a necessidade de ambientes pode mudar rapidamente. Necessita de uma abordagem ágil que ajude a sua estratégia de ambiente a acompanhar as mudanças e a cumprir a evolução dos requisitos de governação da sua organização.

Um fator-chave para o sucesso de uma estratégia de ambiente de inquilinos é comunicar com os seus criadores e utilizadores e obter o respetivo suporte. Certifique-se de que as pessoas que criam aplicações e automatizações de low-code sabem como seguir a estratégia de ambiente da sua organização e onde devem criar os respetivos recursos de low-code.

O percurso de adoção do Power Platform de cada organização é exclusivo. Apresentámos algumas ideias para o ajudar a começar com o pé direito. Sua Microsoft equipa de conta ou Power Platform parceiro pode ajudá-lo a criar uma estratégia de ambiente de locatário mais personalizada para sua organização.

Recursos

• Grupos ambientais
• Roteamento de ambiente
• Power Platform White paper sobre segurança empresarial
• low-code segurança e governação
• Conceitos de solução em ALM