Hierarquia de portfólio

Para entender como um portfólio de cargas de trabalho, ativos e serviços de suporte funcionam todos juntos, precisas estabelecer uma hierarquia de portfólio. Este artigo fornece definições claras para os níveis da hierarquia do seu portfólio, juntamente com orientações para as equipes cumprirem as expectativas para cada nível. Ao longo deste artigo, cada nível da hierarquia também é chamado de escopo.

Cargas de trabalho

Uma coleção de tecnologias que fornece valor comercial definido é chamada de carga de trabalho. A coleção pode incluir aplicativos, servidores ou máquinas virtuais, dados, dispositivos e outros ativos agrupados de forma semelhante. A maioria das empresas depende de várias cargas de trabalho para fornecer funções vitais para os negócios.

Normalmente, uma parte interessada do negócio e um líder técnico compartilham a responsabilidade pelo suporte contínuo de cada carga de trabalho. Em algumas fases do ciclo de vida da carga de trabalho, essas funções são claramente indicadas. Em fases mais operacionais do ciclo de vida de uma carga de trabalho, essas funções podem ser transferidas para uma equipe de gerenciamento de operações compartilhadas ou uma equipe de operações na nuvem. À medida que o número de cargas de trabalho aumenta, as funções (declaradas ou implícitas) tornam-se mais complexas e mais matriciadas.

As cargas de trabalho e seus ativos de suporte estão no centro de qualquer portfólio. Os escopos ou camadas definem como essas cargas de trabalho são vistas e em que medida elas são afetadas pela matriz de potenciais equipes de suporte.

Embora os termos possam variar, todas as soluções de TI incluem ativos e cargas de trabalho:

• Ativo: A menor unidade de função técnica que apoia uma tarefa ou solução.
• Carga de trabalho: A menor unidade de suporte de TI para o negócio. Uma carga de trabalho é uma coleção de infraestrutura, aplicativos e ativos de dados que dão suporte a um objetivo comercial comum ou à execução de um processo de negócios comum.

Quando você está implantando sua primeira carga de trabalho, a carga de trabalho e seus ativos podem ser o único escopo definido. As outras camadas podem ser explicitamente definidas à medida que mais cargas de trabalho são implantadas.

Portfólio de TI

Quando as empresas dão suporte a cargas de trabalho por meio de abordagens matriciais ou abordagens centralizadas, é provável que exista uma hierarquia mais ampla para dar suporte a essas cargas de trabalho:

• Zonas de pouso: As zonas de pouso fornecem cargas de trabalho com os utilitários básicos necessários, ou encanamentos compartilhados, que são necessários para suportar uma ou mais cargas de trabalho. As zonas de pouso são tão críticas na nuvem que toda a metodologia Ready do Cloud Adoption Framework se concentra nas zonas de pouso. Para obter uma definição mais detalhada, consulte O que é uma zona de pouso?
• Utilidades fundamentais: Estes serviços de TI partilhados são essenciais para que as cargas de trabalho funcionem dentro do portfólio de tecnologia e negócios.
• Fundação da plataforma: Essa construção organizacional centraliza soluções fundamentais e ajuda a garantir que esses controles sejam aplicados a todas as zonas de pouso.
• Plataformas de nuvem: Dependendo da estratégia geral de suporte ao portfólio completo, os clientes podem precisar de várias plataformas de nuvem com implantações distintas da base da plataforma para governar várias regiões, soluções híbridas ou até mesmo soluções multicloud.
• Portfólio: Através de uma lente de tecnologia, o portfólio é uma coleção de cargas de trabalho, ativos e recursos de suporte que abrangem todas as plataformas de nuvem. Através de uma lente de negócios, o portfólio é a coleção de projetos, pessoas, processos e investimentos que apoiam e gerenciam o portfólio de tecnologia para impulsionar os resultados de negócios. Juntas, essas duas lentes capturam o portfólio.

Hierarquia, responsabilização e orientação

Uma equipe responsável gerencia cada camada da hierarquia de portfólio. O diagrama a seguir mostra o mapeamento entre a equipe responsável e a orientação para apoiar suas decisões de negócios, decisões técnicas e implementação técnica.

Observação

As equipas mencionadas na lista seguinte podem ser equipas virtuais ou indivíduos. Para algumas variantes dessa hierarquia, algumas das equipes responsáveis podem ser colapsadas, conforme descrito mais adiante nas variantes de responsabilização.

• Portfólio: A equipe de estratégia de nuvem e o centro de excelência em nuvem (CCoE) usam as metodologias Strategy e Plan para orientar decisões que afetam o portfólio geral. A equipe de estratégia de nuvem é responsável pelo nível corporativo da hierarquia de portfólio de nuvem. A equipe de estratégia de nuvem também deve ser informada sobre decisões sobre o ambiente, zonas de aterrissagem e cargas de trabalho de alta prioridade.
• Plataformas de nuvem: A equipe de governança de nuvem é responsável pelos guardrails que garantem a consistência em cada ambiente em alinhamento com a metodologia Govern. A equipe de governança de nuvem é responsável pela governança de todos os recursos em todos os ambientes. A equipe de governança de nuvem deve ser consultada sobre alterações que possam exigir uma exceção ou alteração nas políticas de governança. A equipe de governança de nuvem também deve ser informada sobre o progresso com a carga de trabalho e a adoção de ativos.
• Zonas de pouso e fundação de nuvem: A equipa da plataforma de nuvem é responsável pelo desenvolvimento das zonas de pouso e dos utilitários da plataforma que suportam a adoção. A equipe de automação em nuvem é responsável por automatizar o desenvolvimento e o suporte contínuo para essas zonas de pouso e utilitários de plataforma. Ambas as equipes usam a metodologia Ready para orientar a implementação. Ambas as equipes devem ser informadas sobre o progresso na adoção da carga de trabalho e quaisquer alterações na empresa ou no ambiente.
• Cargas de trabalho: A adoção acontece no nível da carga de trabalho. As equipes de adoção de nuvem usam as metodologias Migrate e Innovate para estabelecer processos escaláveis para acelerar a adoção. Após a conclusão da adoção, a propriedade das cargas de trabalho provavelmente é transferida para uma equipe de operações na nuvem que usa a metodologia Manage para orientar o gerenciamento de operações. Ambas as equipes devem estar confortáveis usando o Microsoft Azure Well-Architected Framework para tomar decisões de arquitetura detalhadas que afetam as cargas de trabalho às quais dão suporte. Ambas as equipas devem ser informadas das alterações nas zonas e ambientes de aterragem. Ambas as equipas podem, ocasionalmente, contribuir para as características da zona de aterragem.
• Ativos: Ativos normalmente são de responsabilidade da equipe de operações na nuvem. Essa equipe usa a linha de base de gerenciamento na metodologia Manage para orientar as decisões de gerenciamento de operações. Ele também deve usar o Azure Advisor e o Azure Well-Architected Framework para fazer alterações detalhadas de recursos e arquitetura necessárias para atender aos requisitos de operações.

Variantes de responsabilização

• Ambiente único: Quando uma empresa precisa de apenas um ambiente, normalmente não é necessária uma CCoE.
• Zona de aterragem única: Se um ambiente tiver apenas uma única zona de pouso, os recursos de governança e plataforma provavelmente podem ser combinados em uma equipe.
• Carga de trabalho única: Algumas empresas precisam de apenas uma carga de trabalho, ou algumas cargas de trabalho, em uma única zona de aterrissagem e um único ambiente. Nesses casos, há pouca necessidade de uma separação de funções entre as equipes de governança, plataforma e operações.

Exemplos comuns de carga de trabalho e prestação de contas

Os exemplos a seguir ilustram a hierarquia de portfólio.

Cargas de trabalho COTS

Tradicionalmente, as empresas têm favorecido soluções de software comerciais prontas para uso (COTS) para alimentar os processos de negócios. Essas soluções são instaladas, configuradas e, em seguida, operadas. Há pouca mudança na arquitetura das soluções após a configuração.

Nesses cenários, qualquer adoção de soluções COTS na nuvem termina com uma transição para uma equipe de operações em nuvem. A equipe de operações na nuvem torna-se então a proprietária técnica desse software e assume a responsabilidade pelo gerenciamento de configuração, custo, ciclos de aplicação de patches e outras necessidades operacionais.

Essas cargas de trabalho incluem pacotes de contabilidade, software de logística ou soluções específicas do setor. Na terminologia da Microsoft, os fornecedores desses pacotes são chamados de fornecedores independentes de software (ISVs). Muitos ISVs oferecem um serviço para implantar e manter uma instância de seu pacote de software em suas assinaturas. Eles também podem oferecer uma versão do pacote de software que é executado em seu próprio ambiente hospedado na nuvem, fornecendo uma plataforma como uma alternativa de serviço (PaaS) para a carga de trabalho.

Com exceção das ofertas de PaaS, as equipes de operações na nuvem são responsáveis por garantir os requisitos básicos de conformidade operacional para essas cargas de trabalho. Uma equipe de operações de nuvem deve trabalhar com a equipe de governança de nuvem para alinhar custo, desempenho e outros pilares de arquitetura.

Em desenvolvimento com revisões ativas

Quando uma solução COTS ou oferta de PaaS não está alinhada à necessidade do negócio, ou não existe solução, as empresas criam cargas de trabalho personalizadas. Normalmente, apenas uma pequena porcentagem do portfólio de TI usa essa abordagem de carga de trabalho. Mas essas cargas de trabalho tendem a gerar uma porcentagem desproporcionalmente alta da contribuição da TI para os resultados de negócios, especialmente os resultados relacionados a novos fluxos de receita. Estas cargas de trabalho tendem a adaptar-se bem a novas ideias de inovação.

Dado vários movimentos que estão enraizados em metodologias ágeis e práticas de DevOps, essas cargas de trabalho favorecem um alinhamento de negócios/DevOps em relação ao gerenciamento tradicional de TI. Para essas cargas de trabalho, pode não haver uma transferência para a equipe de operações de nuvem por vários anos. Nesses casos, a equipe de desenvolvimento atua como o proprietário técnico da carga de trabalho.

Devido a extensas restrições de tempo e capital, as opções de desenvolvimento personalizado são muitas vezes limitadas a oportunidades de alto valor. Exemplos típicos incluem inovações de aplicativos, análise profunda de dados ou funções de negócios de missão crítica.

Suporte técnico corretivo ou descontinuação de desenvolvimento

Depois que uma carga de trabalho desenvolvida sob medida atinge o pico de maturidade, a equipe de desenvolvimento pode ser realocada para outros projetos. Nesses casos, a propriedade técnica normalmente faz a transição para uma equipe de operações na nuvem. Quando houver necessidade de pequenas correções, a equipe de operações recrutará desenvolvedores para resolver o erro.

Em alguns casos, a equipe de desenvolvimento se move para um projeto que eventualmente substituirá a carga de trabalho atual. Como alternativa, a equipe pode seguir em frente porque a oportunidade de negócios suportada pela carga de trabalho está sendo eliminada. Nesses cenários de pôr-do-sol, a equipe de operações na nuvem atua como proprietária técnica até que a carga de trabalho não seja mais necessária.

Em ambos os cenários, a equipe de operações de nuvem normalmente serve como proprietário técnico de longo prazo e tomador de decisões. Essa equipe provavelmente recrutará desenvolvedores de aplicativos quando as alterações operacionais exigirem alterações significativas na arquitetura.

Cargas de trabalho de missão crítica

Em todas as empresas, algumas cargas de trabalho são demasiado importantes para o negócio para que falhem. Com essas cargas de trabalho de missão crítica, geralmente há proprietários de operações e desenvolvimento com vários níveis de responsabilidade. Essas equipes devem alinhar as mudanças operacionais e as alterações arquitetônicas para minimizar as interrupções na solução de produção.

Estes cenários exigem uma forte tónica na separação de funções. A equipe de operações geralmente será responsável pelas mudanças operacionais diárias no ambiente de produção. Quando essas alterações operacionais exigirem uma alteração na arquitetura, elas serão concluídas pela equipe de desenvolvimento ou adoção em um ambiente que não seja de produção, antes que a equipe de operações aplique as alterações à produção.

Exemplos de cargas de trabalho de missão crítica com uma separação de funções necessária incluem cargas de trabalho como SAP, Oracle ou outras soluções de planejamento de recursos empresariais (ERP), que abrangem várias unidades de negócios na empresa.

Alinhamento do portfólio estratégico

É importante entender os objetivos estratégicos do esforço de adoção da nuvem e alinhar o portfólio para apoiar essa transformação. Alguns tipos comuns de alinhamento estratégico de portfólio ajudam a moldar a estrutura da hierarquia de portfólio. As seções a seguir fornecem exemplos do alinhamento e efeito do portfólio na hierarquia do portfólio.

Portefólio liderado pela inovação ou pelo desenvolvimento

Algumas empresas, especialmente startups de rápido crescimento, têm uma porcentagem maior do que a média de projetos de desenvolvimento personalizados. Em portfólios de desenvolvimento pesado, o ambiente, a zona de aterrissagem e as cargas de trabalho geralmente são compactados, portanto, pode haver ambientes específicos para cargas de trabalho específicas. O resultado é uma relação de 1:1 entre ambiente, zona de pouso e carga de trabalho.

Como o ambiente hospeda soluções personalizadas, o pipeline de DevOps e os relatórios no nível do aplicativo podem substituir a necessidade de operações e funções de governança. Esses clientes provavelmente reduzirão o foco em operações, governança ou outras funções de suporte. Uma maior ênfase nas responsabilidades das equipes de adoção e automação de nuvem também é típica.

Alinhamento de portfólio: O portfólio de TI provavelmente se concentrará em cargas de trabalho e nos responsáveis pelas cargas de trabalho para orientar decisões críticas de arquitetura. É provável que essas equipes encontrem mais valor nas diretrizes do Azure Well-Architected Framework durante as atividades de adoção e operações.

Definições de limites: Os limites lógicos, mesmo a nível empresarial, irão provavelmente centrar-se na segmentação do ambiente de produção e não produção. Também pode haver uma clara segmentação entre os produtos do portfólio de software da empresa. Às vezes, também pode haver segmentação entre instâncias de desenvolvimento e de clientes hospedados.

Portfólio liderado por operações

As organizações empresariais multinacionais com equipes de operações de TI mais estabelecidas normalmente têm um foco mais forte na governança e nas operações do que no desenvolvimento. Nessas organizações, uma maior percentagem de cargas de trabalho tende a alinhar-se com as categorias COTS ou de correção de avarias, administradas por responsáveis técnicos da equipa de operações na nuvem.

Alinhamento do portfólio: O portfólio de TI será alinhado à carga de trabalho, mas essas cargas de trabalho serão alinhadas às unidades operacionais ou unidades de negócios. Também pode haver organização em torno de modelos de financiamento, indústria ou outros requisitos de segmentação de negócios.

Definições de limites: Áreas de aterragem provavelmente irão agrupar aplicações em arquétipos de aplicações para manter operações semelhantes numa segmentação semelhante. Os ambientes provavelmente se referem a construções físicas como datacenter, nação, região do provedor de nuvem ou outros padrões operacionais da organização.

Portfólio liderado pela migração

À semelhança das carteiras lideradas por operações, uma carteira que é em grande parte construída através da migração será baseada em fatores de negócio específicos que levaram à migração de ativos existentes. Normalmente, o datacenter é o maior fator nesses drivers.

Alinhamento de portfólio: O portfólio de TI pode estar alinhado à carga de trabalho, mas é mais provável que esteja alinhado a ativos. Se as transições para operações de TI aconteceram no histórico da empresa, muitos ativos de uso ativo podem não ser facilmente mapeados para uma carga de trabalho financiada. Nesses casos, muitos ativos podem não ter uma carga de trabalho definida ou um proprietário de carga de trabalho claro até o final do processo de migração.

Definições de limite: zonas de aterrissagem provavelmente agruparão aplicativos em limites que refletem a segmentação local. Embora não seja uma prática recomendada, os ambientes geralmente correspondem ao nome do datacenter local e às zonas de aterrissagem que representam práticas de segmentação de rede. É uma prática melhor aderir à segmentação que se alinha mais estreitamente com um portfólio liderado por operações.

Portfólio orientado pela governança

O alinhamento com as equipes de governança deve acontecer o mais cedo possível. Por meio de práticas de governança e ferramentas de governança de nuvem, os portfólios e os limites ambientais podem equilibrar melhor as necessidades de inovação, operações e esforços de migração.

Alinhamento de portfólio: Os portfólios liderados por governança tendem a incluir pontos de dados que capturam detalhes de inovação e operações, como carga de trabalho, proprietário das operações, classificação de dados e criticidade operacional. Esses pontos de dados criam uma visão completa do portfólio.

Definições de limites: Os limites em um portfólio liderado por governança tendem a favorecer as operações em detrimento da inovação, enquanto usam uma hierarquia orientada por grupos de gerenciamento que mapeia critérios para unidades de negócios e ambientes de desenvolvimento. Em cada nível da hierarquia, um limite de governança de nuvem pode ter diferentes graus de aplicação de políticas para permitir o desenvolvimento e a flexibilidade criativa. Ao mesmo tempo, os requisitos de grau de produção podem ser aplicados às assinaturas de produção para garantir a separação de tarefas e operações consistentes.

Próximos passos

Saiba como produtos do Azure dão suporte à hierarquia de portfólio.