Hierarquia de portfólio

Para entender como um portfólio de cargas de trabalho, ativos e serviços de suporte funcionam juntos, você precisa estabelecer uma hierarquia de portfólio. Este artigo fornece definições claras para os níveis da hierarquia de portfólio, juntamente com diretrizes para que as equipes cumpram as expectativas de cada nível. Neste artigo, cada nível da hierarquia também é chamado de escopo.

Cargas de Trabalho

Uma coleção de tecnologias que fornece um 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 da mesma forma. A maioria das empresas depende de várias cargas de trabalho para fornecer funções comerciais vitais.

Normalmente, um stakeholder de negócios 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 declaradas. 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 de nuvem. À medida que o número de cargas de trabalho aumenta, as funções (declaradas ou implícitas) tornam-se mais complexas e mais matrizes.

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 exibidas e até que ponto elas são afetadas pela matriz de equipes de suporte potenciais.

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 dá suporte a uma carga de trabalho ou a uma solução.
• Carga de Trabalho : A menor unidade de suporte de TI para a empresa. Uma carga de trabalho é uma coleção de ativos de infraestrutura, aplicativos e dados que dão suporte a uma meta comercial comum ou à execução de um processo comercial comum.

Quando você estiver implantando sua primeira carga de trabalho, a carga de trabalho e os respectivos ativos poderão ser o único escopo definido. As outras camadas podem ser definidas explicitamente à 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 matrizes ou abordagens centralizadas, uma hierarquia mais ampla provavelmente existe para dar suporte a essas cargas de trabalho:

• Zonas de destino: as zonas de destino fornecem cargas de trabalho com os utilitários fundamentais necessários, ou encanamento compartilhado, que são necessários para dar suporte a uma ou mais cargas de trabalho. As zonas de destino são tão críticas na nuvem que toda a metodologia Ready do Cloud Adoption Framework se concentra em zonas de destino. Para obter uma definição mais detalhada, consulte O que é uma zona de destino?
• Utilitários fundamentais: esses serviços de TI compartilhados são necessários para que as cargas de trabalho operem no portfólio de tecnologia e de negócios.
• Base da plataforma: esse constructo organizacional centraliza as soluções fundamentais e ajuda a garantir que esses controles sejam impostos para todas as zonas de destino.
• plataformas de nuvem: Dependendo da estratégia geral para dar 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 multinuvem.
• Portfólio: Por meio 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. Por meio de uma lente de negócios, o portfólio é a coleção de projetos, pessoas, processos e investimentos que dão suporte e gerenciam o portfólio de tecnologia para impulsionar os resultados dos negócios. Juntas, essas duas lentes captam todo o portfólio.

Responsabilização e orientação hierárquica

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 as diretrizes para dar suporte a suas decisões de negócios, decisões técnicas e implementação técnica.

Nota

As equipes mencionadas na lista a seguir podem ser equipes virtuais ou indivíduos. Para algumas variantes dessa hierarquia, algumas das equipes responsáveis podem ser recolhidas, conforme descrito posteriormente nas variantes de responsabilidade.

• Portfólio: A equipe de estratégia de nuvem e o CCoE (centro de excelência em nuvem) usam as metodologias Estratégia e Plano para orientar decisões que afetam o portfólio geral. A equipe de estratégia de nuvem é responsável pelo nível empresarial da hierarquia de portfólio de nuvem. A equipe de estratégia de nuvem também deve ser informada das decisões sobre o ambiente, as zonas de destino e as cargas de trabalho de alta prioridade.
• Plataformas de nuvem: a equipe de governança de nuvem é responsável pelas proteções que garantem a consistência em cada ambiente em alinhamento com a metodologia de Governança. 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 as alterações que podem exigir uma exceção ou alteração nas políticas de controle. A equipe de governança de nuvem também deve ser informada sobre o progresso com a adoção de cargas de trabalho e ativos.
• Zonas de destino e base de nuvem: A equipe da plataforma de nuvem é responsável pelo desenvolvimento das zonas de destino e dos utilitários de plataforma que dão suporte à adoção. A equipe de automação de nuvem é responsável por automatizar o desenvolvimento e suporte contínuo para essas zonas de destino 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 com a adoção da carga de trabalho e quaisquer alterações na empresa ou no ambiente.
• Cargas de trabalho: a adoção ocorre no nível da carga de trabalho. As equipes de adoção de nuvem usam as metodologias de Migração e Inovação para estabelecer processos escalonáveis para acelerar a adoção. Após a conclusão da adoção, a propriedade das cargas de trabalho provavelmente será transferida para uma equipe de operações de nuvem que usa a metodologia Gerenciar para orientar o gerenciamento de operações. Ambas as equipes devem estar confortáveis em usar o Microsoft Azure Well-Architected Framework para tomar decisões de arquitetura detalhadas que afetam as cargas de trabalho que dão suporte. Ambas as equipes devem ser informadas de alterações em zonas de destino e ambientes. Ocasionalmente, elas podem contribuir com os recursos da zona de destino.
• Ativos: Ativos normalmente são responsabilidade da equipe de operações de nuvem. Essa equipe usa a linha de base de gerenciamento na metodologia Gerenciar para orientar as decisões de gerenciamento de operações. Ele também deve usar o Assistente do Azure e o Azure Well-Architected Framework para fazer alterações detalhadas de recursos e arquitetura necessárias para fornecer os requisitos de operações.

Variantes de responsabilidade

• ambiente único: Quando uma empresa precisa de apenas um ambiente, um CCoE normalmente não é necessário.
• zona de destino única: Se um ambiente tiver apenas uma única zona de destino, os recursos de governança e plataforma provavelmente poderão ser combinados em uma equipe.
• Carga de trabalho única: algumas empresas precisam apenas de uma ou algumas cargas de trabalho, em uma só zona de destino e em um só ambiente. Nesses casos, há pouca necessidade de separação de tarefas entre as equipes de governança, plataforma e operações.

Exemplos comuns de carga de trabalho e responsabilidade

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

Cargas de trabalho do COTS

Tradicionalmente, as empresas têm favorecido soluções de software comerciais prontas para uso (COTS) para impulsionar processos empresariais. Essas soluções são instaladas, configuradas e operadas. Há pouca alteração na arquitetura de soluções após a configuração.

Nesses cenários, qualquer adoção de nuvem de soluções COTS termina com uma transição para uma equipe de operações de nuvem. Em seguida, a equipe de operações de nuvem se torna o proprietário técnico desse software e assume a responsabilidade pelo gerenciamento de configuração, custo, ciclos de aplicação de patch e outras necessidades operacionais.

Essas cargas de trabalho incluem pacotes de contabilidade, software logístico ou soluções específicas do setor. Na terminologia da Microsoft, os fornecedores desses pacotes são chamados de ISVs (fornecedores de software independentes). 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 alternativa de PaaS (plataforma como serviço) à carga de trabalho.

Com exceção das ofertas de PaaS, as equipes de operações de nuvem são responsáveis por garantir 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 custos, desempenho e outros pilares de arquitetura.

Em desenvolvimento com as revisões ativas

Quando uma solução COTS ou oferta de PaaS não está alinhada à necessidade de negócios ou não existe uma 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 impulsionar uma porcentagem desproporcionalmente alta da contribuição da TI para os resultados dos negócios, especialmente os resultados relacionados a novos fluxos de receita. Essas cargas de trabalho tendem a alinhar-se bem com novas ideias inovadoras.

Considerando 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 de TI tradicional. Para essas cargas de trabalho, pode não haver uma entrega para a equipe de operações de nuvem por vários anos. Nesses casos, a equipe de desenvolvimento serve como o proprietário técnico da carga de trabalho.

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

Desenvolvimento de interrupção/reparo ou desativação

Depois que uma carga de trabalho desenvolvida personalizada atingir o pico de maturidade, a equipe de desenvolvimento poderá ser reatribuída a outros projetos. Nesses casos, a propriedade técnica normalmente faz a transição para uma equipe de operações de nuvem. Quando houver a necessidade de pequenas correções, a equipe de operações inscreverá desenvolvedores para resolver o erro.

Em alguns casos, a equipe de desenvolvimento passa 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 compatível com a carga de trabalho está sendo eliminada gradualmente. Nesses cenários de descontinuação, a equipe de operações de nuvem atua como proprietário técnico 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ão. Essa equipe provavelmente inscreverá desenvolvedores de aplicativos quando as alterações operacionais exigirem alterações significativas na arquitetura.

Cargas de trabalho críticas

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

Esses cenários exigem um foco forte na separação de tarefas. A equipe de operações geralmente manterá a responsabilidade por alterações operacionais diárias no ambiente de produção. Quando essas alterações operacionais exigirem uma alteração arquitetônica, elas serão concluídas pela equipe de desenvolvimento ou adoção em um ambiente de não produção, antes que a equipe de operações aplique as alterações à produção.

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

Alinhamento de portfólio de estratégia

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

Portfólio liderado por inovação ou desenvolvimento

Algumas empresas, especialmente startups de rápido crescimento, têm uma porcentagem maior que a média de projetos de desenvolvimento personalizados. Em portfólios com desenvolvimento intenso, o ambiente, a zona de destino e as cargas de trabalho costumam ser compactados, ou seja, pode haver ambientes específicos para cargas de trabalho específicas. O resultado é uma taxa de 1:1 entre ambiente, zona de destino 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 ênfase mais forte nas responsabilidades das equipes de adoção de nuvem e automação de nuvem também é típica.

Alinhamento do portfólio: o portfólio de TI provavelmente se concentrará nas cargas de trabalho e nos proprietários da carga de trabalho para impulsionar decisões de arquitetura críticas. É 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 limite: Os limites lógicos, mesmo em um nível empresarial, provavelmente se concentrarão na segmentação de ambiente de produção e não produção. Também pode haver uma segmentação clara entre os produtos no portfólio de software da empresa. Às vezes, também pode haver segmentação entre o desenvolvimento e as instâncias de cliente hospedadas.

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, normalmente, um percentual mais alto de cargas de trabalho se alinha às categorias de COTS ou de interrupção/reparo, mantidas por proprietários técnicos da equipe de operações de nuvem.

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

Definições de limite: as zonas de destino provavelmente agruparão aplicativos em arquétipos de aplicativo para manter operações semelhantes em uma segmentação semelhante. Os ambientes provavelmente se referirão a constructos físicos, como datacenter, nação, região de provedor de nuvem ou outros padrões operacionais da organização.

Portfólio impulsionado pela migração

Semelhante aos portfólios liderados por operações, um portfólio que é construído em grande parte por meio da migração será baseado em drivers de negócios específicos que levaram à migração de ativos existentes. Normalmente, o datacenter é o maior fator nesses drivers.

Alinhamento do portfólio: o portfólio de TI pode estar alinhado à carga de trabalho, mas é mais provável que ele esteja alinhado a ativos. Se as transições para operações de TI tiverem acontecido no histórico da empresa, muitos ativos de uso ativo podem não ser facilmente mapeados para uma carga de trabalho financiada. Nesse 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: as zonas de destino 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 destino que representam as práticas de segmentação de rede. É uma prática melhor aderir à segmentação que se alinha mais com um portfólio liderado por operações.

Portfólio orientado pela governança

O alinhamento às 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, portfólios e limites ambientais podem equilibrar melhor as necessidades de inovação, operações e esforços de migração.

Alinhamento de portfólio: 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 de operações, classificação de dados e criticidade operacional. Esses pontos de dados criam uma exibição bem arredondada do portfólio.

Definições de limite: os limites de um portfólio orientado por governança tendem a favorecer as operações em detrimento da inovação, usando uma hierarquia orientada por grupo de gerenciamento que é mapeada para os critérios de 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 imposição de políticas para permitir o desenvolvimento e a flexibilidade criativa. Ao mesmo tempo, os requisitos de nível de produção podem ser aplicados às assinaturas de produção para garantir separação de tarefas e operações consistentes.

Próximas etapas

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