Hierarquia do portefólio

Para compreender como um portfólio de cargas de trabalho, recursos e serviços de suporte funcionam em conjunto, tem de estabelecer uma hierarquia de portefólio. Este artigo fornece definições claras para os níveis da hierarquia de portefólio, juntamente com orientações para que as equipas cumpram as expectativas de cada nível. Ao longo deste artigo, cada nível da hierarquia também é denominado âmbito.

Cargas de Trabalho

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

Normalmente, um interveniente empresarial e um líder técnico partilham 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 equipa de gestão de operações partilhadas ou para uma equipa de operações na cloud. À medida que o número de cargas de trabalho aumenta, as funções (indicadas ou implícitas) tornam-se mais complexas e mais matrizadas.

As cargas de trabalho e os respetivos recursos de suporte estão no centro de qualquer portefólio. Os âmbitos ou camadas definem a forma como essas cargas de trabalho são vistas e até que ponto são afetadas pela matriz de potenciais equipas de suporte.

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

• Recurso: A unidade mais pequena de função técnica que suporta uma carga de trabalho ou solução.
• Carga de trabalho: A unidade mais pequena de suporte de TI para a empresa. Uma carga de trabalho é uma coleção de recursos de infraestrutura, aplicações e dados que suportam um objetivo empresarial comum ou a execução de um processo de negócio comum.

Quando estiver a implementar a sua primeira carga de trabalho, a carga de trabalho e os respetivos recursos podem ser o único âmbito definido. As outras camadas podem ser explicitamente definidas à medida que são implementadas mais cargas de trabalho.

Portefólio de TI

Quando as empresas suportam cargas de trabalho através de abordagens matrizadas ou abordagens centralizadas, é provável que exista uma hierarquia mais ampla para suportar essas cargas de trabalho:

• Zonas de destino: As zonas de destino fornecem cargas de trabalho com os utilitários fundamentais necessários, ou canalização partilhada, que são necessários para suportar uma ou mais cargas de trabalho. As zonas de destino são tão críticas na cloud que toda a metodologia Ready do Cloud Adoption Framework se concentra nas zonas de destino. Para obter uma definição mais detalhada, consulte O que é uma zona de destino?
• Utilitários fundamentais: Estes serviços de TI partilhados são necessários para que as cargas de trabalho funcionem no portefólio de tecnologia e negócios.
• Base da plataforma: Esta construção organizacional centraliza as soluções fundamentais e ajuda a garantir que esses controlos são impostos para todas as zonas de destino.
• Plataformas na cloud: Consoante a estratégia geral para suportar o portefólio completo, os clientes podem precisar de várias plataformas na cloud com implementações distintas da base da plataforma para governar várias regiões, soluções híbridas ou até mesmo soluções multicloud.
• Portefólio: Através de uma lente tecnológica, o portefólio é uma coleção de cargas de trabalho, recursos e recursos de suporte que abrangem todas as plataformas da cloud. Através de uma lente de negócio, o portefólio é a coleção de projetos, pessoas, processos e investimentos que suportam e gerem o portfólio de tecnologia para impulsionar os resultados empresariais. Em conjunto, estas duas lentes capturam o portfólio.

Responsabilidade e orientação da hierarquia

Uma equipa responsável gere cada camada da hierarquia de portefólio. O diagrama seguinte mostra o mapeamento entre a equipa responsável e a documentação de orientação para suportar as suas decisões empresariais, decisões técnicas e implementação técnica.

Nota

As equipas mencionadas na lista seguinte podem ser equipas virtuais ou indivíduos. Para algumas variantes desta hierarquia, algumas das equipas responsáveis podem ser fechadas, conforme descrito mais adiante nas variantes de responsabilidade.

• Portefólio: A equipa de estratégia da cloud e o centro de excelência da cloud (CCoE) utilizam as metodologias de Estratégia e Plano para orientar decisões que afetam o portefólio global. A equipa de estratégia da cloud é responsável pelo nível empresarial da hierarquia de portefólio da cloud. A equipa de estratégia da cloud também deve ser informada das decisões sobre o ambiente, as zonas de destino e as cargas de trabalho de alta prioridade.
• Plataformas na cloud: A equipa de governação da cloud é responsável pelas disciplinas que garantem a consistência em cada ambiente em conformidade com a metodologia de Governação . A equipa de governação da cloud é responsável pela governação de todos os recursos em todos os ambientes. A equipa de governação da cloud deve ser consultada relativamente a alterações que possam exigir uma exceção ou alteração às políticas de governação. A equipa de governação da cloud também deve ser informada do progresso da carga de trabalho e da adoção de recursos.
• Zonas de destino e base da cloud: A equipa da plataforma cloud é responsável pelo desenvolvimento das zonas de destino e dos utilitários de plataforma que suportam a adoção. A equipa de automatização da cloud é responsável por automatizar o desenvolvimento e o suporte contínuo para essas zonas de destino e utilitários de plataforma. Ambas as equipas utilizam a metodologia Ready (Pronto ) para orientar a implementação. Ambas as equipas devem ser informadas do progresso com a adoção da carga de trabalho e quaisquer alterações à empresa ou ao ambiente.
• Cargas de trabalho: A adoção ocorre ao nível da carga de trabalho. As equipas de adoção da cloud utilizam as metodologias de Migração e Inovação para estabelecer processos dimensionáveis para acelerar a adoção. Após a conclusão da adoção, a propriedade das cargas de trabalho é provavelmente transferida para uma equipa de operações da cloud que utiliza a metodologia Gerir para orientar a gestão de operações. Ambas as equipas devem estar confortáveis em utilizar o Microsoft Azure Well-Architected Framework para tomar decisões de arquitetura detalhadas que afetam as cargas de trabalho que suportam. Ambas as equipas devem ser informadas das alterações às zonas de destino e aos ambientes. As duas equipas podem ocasionalmente contribuir para as funcionalidades da zona de destino.
• Recursos: Normalmente, os recursos são da responsabilidade da equipa de operações da cloud. Essa equipa utiliza a linha de base de gestão na metodologia Gerir para orientar as decisões de gestão de operações. Também deve utilizar o Assistente do Azure e o Azure Well-Architected Framework para fazer alterações detalhadas de recursos e arquiteturas necessárias para cumprir os requisitos de operações.

Variantes de responsabilidade

• Ambiente único: Quando uma empresa precisa apenas de um ambiente, normalmente não é necessário um CCoE.
• Zona de destino única: Se um ambiente tiver apenas uma única zona de destino, é provável que as capacidades de governação e plataforma possam ser combinadas numa única equipa.
• Carga de trabalho única: Algumas empresas precisam apenas de uma carga de trabalho, ou algumas cargas de trabalho, numa única zona de destino e num único ambiente. Nesses casos, há pouca necessidade de separação de deveres entre as equipas de governação, plataforma e operações.

Exemplos comuns de carga de trabalho e responsabilidade

Os exemplos seguintes ilustram a hierarquia de portefólio.

Cargas de trabalho COTS

Tradicionalmente, as empresas têm favorecido soluções de software comercialmente off-the-shelf (COTS) para alimentar processos de negócio. Estas soluções são instaladas, configuradas e, em seguida, operadas. Há poucas alterações na arquitetura das soluções após a configuração.

Nestes cenários, qualquer adoção da cloud de soluções COTS termina com uma transição para uma equipa de operações na cloud. Em seguida, a equipa de operações da cloud torna-se o proprietário técnico desse software e assume a responsabilidade pela gestão da configuração, dos custos, dos ciclos de aplicação de patches e de outras necessidades operacionais.

Estas cargas de trabalho incluem pacotes de contabilidade, software de logística ou soluções específicas do setor. Na terminologia da Microsoft, os fornecedores destes pacotes são denominados fornecedores independentes de software (ISVs). Muitos ISVs oferecem um serviço para implementar e manter uma instância do respetivo pacote de software nas suas subscrições. Também podem oferecer uma versão do pacote de software que é executada no seu próprio ambiente alojado na cloud, fornecendo uma alternativa de plataforma como serviço (PaaS) à carga de trabalho.

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

Em desenvolvimento com revisões ativas

Quando uma solução COTS ou oferta PaaS não está alinhada com a necessidade empresarial ou não existe nenhuma solução, as empresas criam cargas de trabalho personalizadas desenvolvidas. Normalmente, apenas uma pequena percentagem do portefólio de TI utiliza esta abordagem de carga de trabalho. No entanto, estas cargas de trabalho tendem a gerar uma percentagem desproporcionalmente elevada da contribuição das TI para os resultados empresariais, especialmente os resultados relacionados com novos fluxos de receitas. Estas cargas de trabalho tendem a mapear bem para novas ideias de inovação.

Tendo em conta vários movimentos enraizados em metodologias ágeis e práticas de DevOps, estas cargas de trabalho favorecem um alinhamento de negócios/DevOps em vez da gestão de TI tradicional. Para estas cargas de trabalho, pode não haver uma entrega para a equipa de operações da cloud durante vários anos. Nesses casos, a equipa de desenvolvimento serve como proprietária técnica da carga de trabalho.

Devido ao tempo extenso e às restrições de capital, as opções de desenvolvimento personalizadas estão muitas vezes limitadas a oportunidades de alto valor. Os exemplos típicos incluem inovações de aplicações, análise de dados profundas ou funções empresariais fundamentais para a missão.

Interrupção/correção ou desenvolvimento do pôr-do-sol

Depois de uma carga de trabalho personalizada ter atingido o pico de maturidade, a equipa de desenvolvimento poderá ser reatribuída a outros projetos. Nestes casos, a propriedade técnica normalmente transita para uma equipa de operações da cloud. Quando há necessidade de pequenas correções, a equipa de operações vai pedir aos programadores que resolvam o erro.

Em alguns casos, a equipa de desenvolvimento muda para um projeto que irá eventualmente substituir a carga de trabalho atual. Em alternativa, a equipa pode seguir em frente porque a oportunidade de negócio suportada pela carga de trabalho está a ser gradualmente eliminada. Nestes cenários de pôr-do-sol, a equipa de operações da cloud serve como proprietário técnico até que a carga de trabalho deixe de ser necessária.

Em ambos os cenários, a equipa de operações da cloud serve normalmente como proprietário técnico e decisor a longo prazo. Essa equipa irá provavelmente recrutar programadores de aplicações quando as alterações operacionais exigirem alterações de arquitetura significativas.

Cargas de trabalho críticas

Em todas as empresas, algumas cargas de trabalho são demasiado importantes para que a empresa falhe. Com estas cargas de trabalho críticas para a missão, existem normalmente proprietários de operações e desenvolvimento com vários níveis de responsabilidade. Essas equipas devem alinhar as alterações operacionais e as alterações arquitetónicas para minimizar as interrupções na solução de produção.

Estes cenários requerem um forte foco na separação de deveres. Geralmente, a equipa de operações irá responsabilizar-se pelas alterações operacionais diárias no ambiente de produção. Quando essas alterações operacionais exigirem uma alteração arquitetónica, serão concluídas pela equipa de desenvolvimento ou adoção num ambiente de não produção, antes de a equipa de operações aplicar as alterações à produção.

Exemplos de cargas de trabalho críticas para a missão com uma separação necessária de deveres incluem cargas de trabalho como sap, Oracle ou outras soluções de planeamento de recursos empresariais (ERP), que abrangem várias unidades de negócio na empresa.

Alinhamento do portefólio de estratégia

É importante compreender os objetivos estratégicos do esforço de adoção da cloud e alinhar o portefólio para suportar essa transformação. Alguns tipos comuns de alinhamento de portefólio estratégico ajudam a moldar a estrutura da hierarquia de portefólio. As secções seguintes fornecem exemplos do alinhamento e efeito do portefólio na hierarquia de portefólio.

Portefólio liderado por inovação ou desenvolvimento

Algumas empresas, especialmente startups em rápido crescimento, têm uma percentagem superior à média de projetos de desenvolvimento personalizados. Em portefólios pesados de desenvolvimento, o ambiente, a zona de destino e as cargas de trabalho são frequentemente comprimidos, pelo que podem existir ambientes específicos para cargas de trabalho específicas. O resultado é uma proporção de 1:1 entre o ambiente, a zona de destino e a carga de trabalho.

Uma vez que o ambiente aloja soluções personalizadas, o pipeline de DevOps e os relatórios ao nível da aplicação podem substituir a necessidade de operações e funções de governação. É provável que esses clientes reduzam o foco nas operações, governação ou outras funções de suporte. Uma ênfase mais forte nas responsabilidades das equipas de adoção da cloud e automatização da cloud também é típica.

Alinhamento do portefólio: O portefólio de TI irá provavelmente focar-se em cargas de trabalho e proprietários de cargas de trabalho para impulsionar decisões de arquitetura críticas. É provável que essas equipas encontrem mais valor na documentação de orientação 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, provavelmente irão focar-se na segmentação do ambiente de produção e não produção. Também pode haver uma segmentação clara entre produtos no portefólio de software da empresa. Por vezes, também pode haver segmentação entre o desenvolvimento e as instâncias de cliente alojadas.

Portefólio liderado por operações

Normalmente, as organizações multinacionais empresariais com equipas de operações de TI mais estabelecidas têm um foco mais forte na governação e nas operações do que no desenvolvimento. Nestas organizações, uma percentagem mais elevada de cargas de trabalho alinha-se normalmente com as categorias COTS ou break/fix, mantidas pelos proprietários técnicos na equipa de operações da cloud.

Alinhamento do portefólio: O portefólio de TI estará alinhado com a carga de trabalho, mas essas cargas de trabalho estão alinhadas com unidades operacionais ou unidades empresariais. 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: As zonas de destino provavelmente agruparão aplicações em arquétipos de aplicações para manter operações semelhantes numa segmentação semelhante. Os ambientes provavelmente referir-se-ão a construções físicas como datacenter, país, região fornecedor de cloud ou outras normas operacionais da organização.

Portefólio liderado por migração

À semelhança dos portefólios liderados por operações, um portefólio criado em grande parte através da migração basear-se-á em fatores empresariais específicos que conduziram à migração de ativos existentes. Normalmente, o datacenter é o maior fator nesses controladores.

Alinhamento do portefólio: O portefólio de TI pode estar alinhado com a carga de trabalho, mas é mais provável que o recurso esteja alinhado. Se as transições para operações de TI tiverem ocorrido no histórico da empresa, muitos ativos de utilização ativa poderão não ser facilmente mapeados para uma carga de trabalho financiada. Nestes casos, muitos recursos podem não ter uma carga de trabalho definida ou limpar o proprietário da carga de trabalho até ao final do processo de migração.

Definições de limites: As zonas de destino provavelmente agruparão aplicações em limites que refletem a segmentação no local. Embora não seja uma melhor prática, os ambientes correspondem frequentemente ao nome do datacenter no local e às zonas de destino que representam práticas de segmentação de rede. É uma melhor prática aderir à segmentação que se alinha mais de perto com um portefólio liderado por operações.

Portefólio liderado pela governação

O alinhamento com as equipas de governação deve ocorrer o mais cedo possível. Através de práticas de governação e ferramentas de governação da cloud, as carteiras e os limites ambientais podem equilibrar melhor as necessidades de inovação, operações e esforços de migração.

Alinhamento do portefólio: Os portefólios liderados pela governação tendem a incluir pontos de dados que captam detalhes de inovação e operações, tais como carga de trabalho, proprietário de operações, classificação de dados e importância operacional. Estes pontos de dados criam uma vista bem arredondada do portefólio.

Definições de limites: Os limites num portefólio liderado pela governação tendem a favorecer as operações sobre a inovação, ao mesmo tempo que utilizam uma hierarquia orientada por grupos de gestão que mapeia critérios para unidades de negócio e ambientes de desenvolvimento. Em cada nível da hierarquia, um limite de governação da cloud pode ter diferentes graus de imposição de políticas para permitir o desenvolvimento e flexibilidade criativa. Ao mesmo tempo, os requisitos de nível de produção podem ser aplicados às subscrições de produção para garantir a separação de deveres e operações consistentes.

Passos seguintes

Saiba como os produtos do Azure suportam a hierarquia de portefólio.