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 de sua hierarquia de portfólio, juntamente com diretrizes para que as equipes entreguem as expectativas para 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 ou uma equipe de operações de nuvem compartilhada. Conforme aumenta o número de cargas de trabalho, as funções (declaradas ou implícitas) se tornam mais complexas e mais definidas em matriz.

As cargas de trabalho e os respectivos 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 os negócios. Uma carga de trabalho é uma coleção de infraestrutura, aplicativos e ativos de 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 explicitamente definidas à medida que mais cargas de trabalho são implantadas.

Portfólio de TI

Quando as empresas dão suporte à cargas de trabalho por meio de abordagens em matriz ou abordagens centralizadas, provavelmente, há uma hierarquia mais ampla 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 Pronto do Cloud Adoption Framework se concentra nas zonas de destino. Para obter uma definição mais detalhada, confira 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 controlar 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 ao portfólio de tecnologia e o gerenciam para gerar resultados de negócios. Juntas, essas duas lentes capturam o portfólio.

Responsabilidade e diretrizes da hierarquia

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 às decisões de negócios, às decisões técnicas e à implementação técnica.

Observação

As equipes mencionadas na lista a seguir podem ser equipes virtuais ou pessoas. 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 na nuvem. Ela também deve ser informada sobre 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 disciplinas que garantem a consistência em cada ambiente em alinhamento com a metodologia de governança . Ela é responsável para 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 possam exigir uma exceção ou uma mudança nas políticas de governança. Ela também deve ser informada sobre o progresso com a adoção de ativos e de carga de trabalho.
• Zonas de destino e base de nuvem: a equipe da plataforma de nuvem é responsável por desenvolver as zonas de destino e os utilitários de plataforma que dão suporte à adoção. A equipe de automação de nuvem é responsável por automatizar o desenvolvimento das zonas de destino e dos utilitários da plataforma e o suporte contínuo a eles. Ambas as equipes usam a metodologia Pronto para orientar a implementação. Elas devem ser informadas sobre o progresso com a adoção da carga de trabalho e sobre as alterações na empresa ou no ambiente.
• Cargas de trabalho: a adoção ocorre na carga de trabalho. As equipes de adoção da nuvem usam as metodologias Migrar e Inovar 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. As duas equipes devem estar familiarizadas com o Microsoft Azure Well-Architected Framework para tomar decisões detalhadas de arquitetura que afetam as cargas de trabalho às quais elas dão suporte. As duas equipes devem ser informadas sobre as alterações em ambientes e em zonas de destino. Elas podem ocasionalmente contribuir com os recursos da zona de destino.
• Ativos: normalmente, os ativos são a 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. Ela também deve usar o Assistente do Azure e o Azure Well-Architected Framework para fazer alterações detalhadas de recursos e arquitetura que sejam necessárias para atender aos requisitos de operações.

Variantes de responsabilidade

• Ambiente único: quando uma empresa precisa ter apenas um ambiente, um CCoE normalmente não é necessário.
• Zona de destino única: se um ambiente tiver uma só zona de destino, as funcionalidades de governança e de plataforma provavelmente poderão ser combinadas 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 destino e em um único ambiente. Nesses casos, há pouca necessidade de uma separação de tarefas entre as equipes de governança, de plataforma e de 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 dado preferência a soluções de software COTS (commercial off-the-shelf) para capacitar processos de negócios. Essas soluções são instaladas, configuradas e, em seguida, operadas. Há pouca alteração na arquitetura de soluções após a configuração.

Nesses cenários, qualquer adoção da nuvem de soluções COTS termina com uma transição para uma equipe de operações de nuvem. A equipe de operações de nuvem torna-se o proprietário técnico desse software e assume a responsabilidade por gerenciar a configuração, o custo, os 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 ISVs (fornecedores independentes de software). Muitos ISVs oferecem um serviço para implantar e manter uma instância do pacote de software nas suas assinaturas. Eles também podem oferecer uma versão do pacote de software que é executada em um ambiente próprio 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 os pilares de custo, desempenho e outros tipos de arquitetura.

Em desenvolvimento com as revisões ativas

Quando uma solução COTS ou uma oferta de PaaS não está alinhada com a necessidade comercial ou não existe nenhuma 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 um percentual desproporcionalmente alto de contribuição da TI para os resultados de negócios, especialmente resultados relacionados a novos fluxos de receita. Essas cargas de trabalho tendem a ser mapeadas bem para novas ideias de inovação.

Devido a vários movimentos baseados em metodologias Agile e práticas de DevOps, essas cargas de trabalho favorecem um alinhamento de negócios/DevOps em detrimento do 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 extensas de tempo e capital, as opções de desenvolvimento personalizadas geralmente são limitadas a oportunidades de alto valor. Entre os exemplos típicos estão inovações de aplicativos, análise profunda de dados ou funções comercialmente críticas.

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

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

Em alguns casos, a equipe de desenvolvimento passa para um projeto que, por fim, 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 gradualmente. Nesses cenários de pôr do sol, a equipe de operações de nuvem serve como o proprietário técnico até que a carga de trabalho não seja mais necessária.

Nos dois cenários, a equipe de operações de nuvem costuma servir como o proprietário técnico e o tomador de decisões de longo prazo. Essa equipe provavelmente convocará desenvolvedores de aplicativos quando as alterações operacionais exigirem mudanças de arquitetura significativas.

Cargas de trabalho críticas

Em todas as empresas, algumas cargas de trabalho são muito importantes para a empresa e não permitem falhas. Com essas cargas de trabalho críticas, em geral, há operações e proprietários de desenvolvimento com vários níveis de responsabilidade. Essas equipes devem alinhar as alterações operacionais e as mudanças de arquitetura para minimizar as interrupções na solução de produção.

Esses cenários exigem um grande foco 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 de arquitetura, elas serão concluídas pela equipe de desenvolvimento ou de adoção em um ambiente de não produção, antes que a equipe de operações aplique as alterações à produção.

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

Alinhamento do portfólio de estratégias

É 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 na estrutura da hierarquia do portfólio. As seções a seguir fornecem exemplos de alinhamento e efeito do portfólio na hierarquia de portfólio.

Portfólio orientado por desenvolvimento ou por inovação

Algumas empresas, especialmente startups de rápido crescimento, têm um percentual maior que a média de projetos de desenvolvimento personalizados. Em portfólios pesados de desenvolvimento, o ambiente, a zona de destino e as cargas de trabalho geralmente são compactados, portanto, 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 de nível de aplicativo podem substituir a necessidade de funções de governança e operações. 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 da nuvem e de 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 de operações.

Definições de limite: os limites lógicos, até mesmo, em um nível empresarial, provavelmente se concentrarão na segmentação de produção e de 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 as instâncias de clientes de desenvolvimento e hospedadas.

Portfólio orientado por operações

As organizações empresariais multinacionais com equipes de operações de TI mais estabelecidas normalmente têm um maior foco em governança e operações do que no desenvolvimento. Nessas organizações, um percentual maior de cargas de trabalho normalmente se alinha às categorias COTS ou break/fix, mantidas por proprietários técnicos dentro 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 às unidades operacionais ou às unidades de negócios. Também pode haver uma organização em relação aos modelos de financiamento, ao setor ou a outros requisitos de segmentação de negócios.

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

Portfólio orientado por migração

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

Alinhamento do portfólio: o portfólio de TI pode estar alinhado à carga de trabalho, porém, é mais provável que ele esteja alinhado ao ativo. Se houve alguma transição para as operações de TI na história da empresa, muitos ativos de uso ativos podem não ser mapeados com facilidade para uma carga de trabalho financiada. Nesses casos, muitos ativos podem não ter uma carga de trabalho definida ou não ter o proprietário da carga de trabalho definido até o final do processo de migração.

Definições de limite: as zonas de destino provavelmente agruparão os aplicativos em limites que reflitam a segmentação local. Embora essa não seja uma melhor prática, os ambientes costumam 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 é respeitar uma segmentação que se alinhe mais estreitamente a um portfólio orientado por operações.

Portfólio orientado por governança

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

Alinhamento do portfólio: os portfólios orientados por governança tendem a incluir pontos de dados que capturam a inovação e os detalhes de operações, como carga de trabalho, proprietário das operações, classificação de dados e importância operacional. Esses pontos de dados criam uma exibição abrangente 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ítica 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 os produtos do Azure dão suporte à hierarquia de portfólio.