Jerarquía de la cartera

Para comprender cómo funcionan conjuntamente la cartera de cargas de trabajo, los recursos y los servicios auxiliares, debe establecer una jerarquía de carteras. En este artículo se proporcionan definiciones claras para los niveles de la jerarquía de cartera, junto con instrucciones para que los equipos cumplan las expectativas de cada nivel. En este artículo, cada nivel de la jerarquía también se conoce como ámbito.

Cargas de trabajo

Una colección de tecnologías que proporciona un valor empresarial definido se denomina carga de trabajo. La colección puede incluir aplicaciones, servidores o máquinas virtuales, datos, dispositivos y otros recursos agrupados de forma similar. La mayoría de las empresas recurren a varias cargas de trabajo para proporcionar funciones empresariales esenciales.

Normalmente, un responsable de la empresa y un líder técnico se reparten el apoyo continuo de cada carga de trabajo. En algunas fases del ciclo de vida de la carga de trabajo, estos roles están claramente definidos. En otras fases operativas del ciclo de vida de una carga de trabajo, esos roles se pueden transferir a un equipo de administración de operaciones común o a un equipo de operaciones en la nube. A medida que aumenta el número de cargas de trabajo, los roles (indicados o implícitos) son más complejos o están más estructurados en matrices.

Las cargas de trabajo y sus recursos de apoyo se sitúan en el centro de cualquier cartera. Los ámbitos o niveles definen cómo se ven esas cargas de trabajo y hasta qué punto se ven afectadas por la matriz de los posibles equipos de apoyo.

Aunque los términos pueden variar, todas las soluciones de TI incluyen recursos y cargas de trabajo:

• Recurso: la unidad más pequeña de función técnica que respalda una carga de trabajo o solución.
• Carga de trabajo: la unidad más pequeña de soporte de TI para la empresa. Una carga de trabajo es una colección de recursos de infraestructura, aplicaciones y datos que respaldan un objetivo empresarial común o la ejecución de un proceso de negocio común.

Al implementar la primera carga de trabajo, esta y sus recursos pueden ser el único ámbito definido. El resto de niveles se pueden definir explícitamente a medida que se implementan más cargas de trabajo.

Cartera de TI

Cuando las empresas admiten cargas de trabajo mediante enfoques con matrices o enfoques centralizados, es probable que exista una jerarquía más amplia para admitir estas cargas de trabajo:

• Zonas de aterrizaje:las zonas de aterrizaje ofrecen a las cargas de trabajo las utilidades fundamentales o la infraestructura compartida necesarias que se requieren para admitir una o varias cargas de trabajo. Las zonas de aterrizaje son un componente esencial en la nube; tanto, que toda la metodología de preparación de Cloud Adoption Framework se centra en las zonas de aterrizaje. Para obtener una definición más detallada, consulte ¿Qué es una zona de aterrizaje?
• Utilidades fundamentales: estos servicios de TI compartidos son necesarios para que las cargas de trabajo funcionen dentro de la tecnología y la cartera empresarial.
• Base de plataforma: esta construcción de la organización centraliza las soluciones fundamentales y ayuda a garantizar que esos controles se aplican a todas las zonas de aterrizaje.
• Plataformas en la nube: en función de la estrategia global para apoyar toda la cartera, es posible que los clientes necesiten varias plataformas en la nube con implementaciones distintas de la base de plataforma para controlar varias regiones, soluciones híbridas o incluso soluciones de varias nubes.
• Cartera: desde un punto de vista tecnológico, la cartera es una colección de cargas de trabajo y recursos de apoyo que abarca todas las plataformas en la nube. Desde un punto de vista empresarial, la cartera es la colección de proyectos, personas, procesos e inversiones que respaldan y administran la cartera tecnológica para promover los resultados empresariales. Juntos, los dos puntos de vista permiten capturar la esencia de la cartera.

Instrucciones y responsabilidad de la jerarquía

Un equipo responsable se encarga de administrar cada nivel de la jerarquía de la cartera. En el diagrama siguiente se muestra la correlación entre el equipo responsable y las instrucciones para respaldar sus decisiones técnicas y empresariales, y su consiguiente implementación técnica.

Nota

Los equipos que se mencionan en la lista siguiente podrían ser equipos virtuales o personas individuales. En ciertas variantes de esta jerarquía, algunos de los equipos responsables se pueden reducir tal y como se describe en las variantes de responsabilidad que se indican a continuación.

• Cartera: el equipo de estrategia en la nube y el centro de excelencia en la nube (CCoE) usan las metodologías de estrategia y planeamiento para fundamentar las decisiones que afectan a la cartera de forma global. El equipo de estrategia en la nube es responsable del nivel empresarial de la jerarquía de la cartera de la nube. También se debe informar a este equipo sobre las decisiones relacionadas con el entorno, las zonas de aterrizaje y las cargas de trabajo de prioridad alta.
• Plataformas en la nube: el equipo de gobernanza de la nube es responsable de las disciplinas que garantizan la coherencia en cada entorno en consonancia con la metodología de gobernanza. El equipo de gobernanza de la nube es responsable de la gobernanza de todos los recursos en todos los entornos. Hay que consultar al equipo de gobernanza de la nube en relación con aquellos cambios que puedan requerir una excepción o un cambio en las directivas de gobierno. El equipo de gobernanza de la nube también debe estar informado del progreso con respecto a la carga de trabajo y a la adopción de recursos.
• Zonas de aterrizaje y base de la nube: el equipo de plataforma en la nube es responsable de desarrollar las zonas de aterrizaje y las utilidades de plataforma que respaldan la adopción. El equipo de automatización en la nube es responsable de automatizar el desarrollo y el apoyo continuo a esas zonas de aterrizaje y utilidades de la plataforma. Ambos equipos usan la metodología de preparación para guiar la implementación. Ambos equipos deben estar informados del progreso con la adopción de la carga de trabajo y cualquier cambio en la empresa o el entorno.
• Cargas de trabajo: la adopción se produce en el nivel de carga de trabajo. Los equipos de adopción de la nube usan las metodologías de migración e innovación para establecer procesos escalables con el fin de acelerar la adopción. Una vez completada la adopción, es probable que la propiedad de las cargas de trabajo se transfiera a un equipo de operaciones en la nube que use la metodología de administración para dirigir la administración de las operaciones. Ambos equipos deben estar familiarizados con el Marco de buena arquitectura de Microsoft Azure para tomar decisiones arquitectónicas detalladas que afecten a las cargas de trabajo que admiten. Ambos equipos deben estar informados de los cambios en los entornos y las zonas de aterrizaje. Ambos equipos pueden colaborar ocasionalmente en las características de la zona de aterrizaje.
• Recursos: los recursos suelen ser responsabilidad del equipo de operaciones en la nube. Ese equipo usa la línea de base de administración de la metodología de administración para guiar las decisiones de administración de operaciones. También debe usar Azure Advisor y el Marco de buena arquitectura de Azure para realizar los cambios detallados en los recursos y la arquitectura necesarios para cumplir con los requisitos de las operaciones.

Variantes de responsabilidad

• Entorno único: cuando una empresa solo necesita un entorno, normalmente no es necesario un CCoE.
• Zona de aterrizaje única: si un entorno tiene una sola zona de aterrizaje, es probable que las funcionalidades de gobernanza y plataforma se puedan combinar en un solo equipo.
• Carga de trabajo única: algunas empresas solo necesitan una carga de trabajo, o algunas cargas de trabajo, en una única zona de aterrizaje y un único entorno. En estos casos, no es necesario separar las tareas entre los equipos de gobernanza, plataforma y operaciones.

Ejemplos comunes de carga de trabajo y responsabilidad

En los siguientes ejemplos se muestra la jerarquía de la cartera.

Cargas de trabajo de soluciones de software comerciales

Tradicionalmente, las empresas han favorecido soluciones de software comerciales (COTS) para potenciar los procesos empresariales. Estas soluciones se instalan, se configuran y, luego, se utilizan. Hay pocos cambios en la arquitectura de soluciones después de la configuración.

En estos casos, cualquier adopción en la nube de soluciones de software comerciales termina con una transición a un equipo de operaciones en la nube. Entonces, el equipo de operaciones en la nube se convierte en el propietario técnico de ese software y asume la responsabilidad de administrar la configuración, el costo, los ciclos de revisión y otras necesidades operativas.

Estas cargas de trabajo incluyen paquetes de contabilidad, software de logística o soluciones específicas del sector. En la terminología de Microsoft, los proveedores de estos paquetes se denominan proveedores de software independientes (ISV). Muchos ISV ofrecen un servicio para implementar y mantener una instancia de su paquete de software en las suscripciones. También pueden ofrecer una versión del paquete de software que se ejecuta en su propio entorno hospedado en la nube, lo que proporciona una alternativa de plataforma como servicio (PaaS) a la carga de trabajo.

A excepción de las ofertas de PaaS, los equipos de operaciones en la nube son responsables de garantizar los requisitos operativos de cumplimiento básicos de las cargas de trabajo. Un equipo de operaciones en la nube debe trabajar con el equipo de gobernanza de la nube para acordar los costos, el rendimiento y el resto de pilares de la arquitectura.

En desarrollo con revisiones activas

Cuando una solución de COTS o una oferta de PaaS no está en sintonía con la necesidad empresarial, o no existe ninguna solución, las empresas crean cargas de trabajo desarrolladas a nivel personalizado. Normalmente, solo un pequeño porcentaje de la cartera de TI utiliza este enfoque de carga de trabajo. Sin embargo, estas cargas de trabajo tienden a impulsar un porcentaje desproporcionadamente elevado de la contribución de TI a los resultados empresariales, especialmente los resultados relacionados con nuevos flujos de ingresos. Estas cargas de trabajo tienden a asignarse bien a nuevas ideas de innovación.

Dados los diversos movimientos que se basan en metodologías ágiles y prácticas de DevOps, estas cargas de trabajo priorizan una alineación empresarial/DevOps sobre la administración de TI tradicional. En el caso de estas cargas de trabajo, puede que no haya una transferencia al equipo de operaciones en la nube durante varios años. En estos casos, el equipo de desarrollo actúa como el propietario técnico de la carga de trabajo.

Como consecuencia del tiempo prolongado y las limitaciones de capital, las opciones de desarrollo personalizado a menudo se limitan a oportunidades de valor elevado. Algunos ejemplos típicos son las innovaciones de aplicaciones, el análisis profundo de los datos o las funciones empresariales críticas.

Resolución de problemas o desarrollo de ocaso

Una vez que una carga de trabajo con desarrollo personalizado alcanza el punto máximo de madurez, el equipo de desarrollo se puede reasignar a otros proyectos. En estos casos, la propiedad técnica normalmente se transfiere a un equipo de operaciones en la nube. Cuando se necesiten pequeñas correcciones, el equipo de operaciones asignará a los desarrolladores la resolución de tales errores.

En algunos casos, el equipo de desarrollo pasa a trabajar en un proyecto que más adelante reemplazará la carga de trabajo actual. También es posible que el cambio del equipo se deba a que la oportunidad empresarial respaldada por la carga de trabajo se esté eliminando gradualmente. En estos escenarios "de ocaso", el equipo de operaciones en la nube actúa como propietario técnico hasta que la carga de trabajo ya no se necesita.

En ambos escenarios, el equipo de operaciones en la nube suele ejercer como propietario técnico a largo plazo y responsable de la toma de decisiones. Ese equipo recurrirá probablemente a desarrolladores de aplicaciones cuando los cambios operativos requieran cambios en la arquitectura significativos.

Cargas de trabajo críticas

En todas las organizaciones, hay algunas cargas de trabajo que por su gran importancia empresarial no pueden sufrir ningún error. Con estas cargas de trabajo críticas, normalmente hay operaciones y propietarios de desarrollo con varios niveles de responsabilidad. Esos equipos deben armonizar los cambios operativos y los cambios arquitectónicos para minimizar las interrupciones en la solución de producción.

Estos escenarios requieren que se preste especial atención a la separación de obligaciones. El equipo de operaciones normalmente mantendrá la responsabilidad de los cambios operativos cotidianos en el entorno de producción. Si esos cambios operativos requieren un cambio en la arquitectura, el equipo de desarrollo o adopción lo completará en un entorno de no producción para que a continuación el equipo de operaciones aplique los cambios en producción.

Entre los ejemplos de cargas de trabajo críticas con una separación obligatoria de tareas se incluyen las cargas de trabajo como SAP, Oracle u otras soluciones de planeación de recursos empresariales (ERP), que abarcan varias unidades de negocio de la empresa.

Alineación de la cartera de estrategias

Es importante comprender los objetivos estratégicos del esfuerzo de adopción de la nube y la adaptación de la cartera para respaldar esa transformación. Algunos tipos comunes de alineación estratégica de la cartera ayudan a moldear la estructura de la jerarquía de cartera. En las secciones siguientes se proporcionan ejemplos de la alineación de la cartera y su repercusión en la jerarquía de esta.

Cartera orientada a la innovación o el desarrollo

Algunas empresas, especialmente las startups de rápido crecimiento, tienen un porcentaje superior al promedio de proyectos de desarrollo personalizados. En las carteras con importantes cargas de desarrollo, el entorno, la zona de aterrizaje y las cargas de trabajo se suelen comprimir; por lo que puede haber entornos específicos para cargas de trabajo específicas. El resultado es una relación 1:1 entre el entorno, la zona de aterrizaje y la carga de trabajo.

Como el entorno hospeda soluciones personalizadas, la canalización DevOps y los informes en el nivel de aplicación podrían sustituir la necesidad de funciones operativas y de gobernanza. Es probable que esos clientes presten menor atención a las operaciones, la gobernanza u otros roles de respaldo. También se suele hacer mayor hincapié en las responsabilidades de la adopción de la nube y de los equipos de automatización de la nube.

Alineación de cartera: la cartera de TI probablemente se centrará en las cargas de trabajo y los propietarios de cargas de trabajo para impulsar decisiones de arquitectura críticas. Es probable que estos equipos encuentren más valor en las instrucciones del Marco de buena arquitectura de Azure durante las actividades de adopción y operaciones.

Definiciones de límite: los límites lógicos, incluso en un nivel empresarial, se centrarán probablemente en la segmentación de entornos de producción y de no producción. También puede haber una segmentación clara entre productos de la cartera de software de la empresa. En ocasiones, también puede haber segmentación entre el desarrollo y las instancias de clientes hospedadas.

Cartera orientada a operaciones

Las organizaciones empresariales multinacionales con equipos de operaciones de TI más establecidos generalmente se centran en mayor medida en la gobernanza y las operaciones que en el desarrollo. En estas organizaciones, un porcentaje mayor de cargas de trabajo se alinea normalmente con las categorías de COTS o resolución de problemas, mantenidas por los propietarios técnicos dentro del equipo de operaciones en la nube.

Alineación de cartera: la cartera de TI se alineará con la carga de trabajo, pero estas cargas de trabajo se alinearán con unidades operativas o unidades de negocio. También se puede organizar en torno a los modelos de financiación, industria o según otros requisitos de segmentación empresarial.

Definiciones de límite: las zonas de aterrizaje probablemente agruparán las aplicaciones en arquetipos de aplicaciones para mantener operaciones similares en una segmentación similar. Es probable que los entornos se refieran a construcciones físicas como el centro de datos, la nación, la región de proveedores de la nube u otros estándares de organización operativa.

Cartera orientada a la migración

De forma similar a las carteras orientadas a operaciones, una cartera que se cree en gran medida a través de la migración se basará en controladores empresariales específicos que lleven a la migración de los recursos existentes. Normalmente, el centro de datos es el factor más importante en esos controladores.

Alineación de cartera: la cartera de TI se puede adaptar a la carga de trabajo, pero es más probable que se adapte a los recursos. Si se han producido transiciones a las operaciones de TI en el historial de la empresa, es posible que muchos recursos de uso activo no se asignen fácilmente a una carga de trabajo financiada. En estos casos, muchos recursos podrían no tener una carga de trabajo definida o un propietario de la carga de trabajo claro hasta el final del proceso de migración.

Definiciones de límite: las zonas de aterrizaje probablemente agruparán las aplicaciones en límites que reflejan la segmentación local. Aunque no es un procedimiento recomendado, los entornos a menudo coinciden con el nombre del centro de datos local y las zonas de aterrizaje que representan las prácticas de segmentación de la red. Es recomendable adherirse a una segmentación que se adapte mejor con una cartera orientada hacia las operaciones.

Cartera orientada a gobernanza

La alineación con los equipos de gobernanza debe llevarse a cabo lo antes posible. Con el uso de procedimientos y herramientas de gobernanza en la nube, carteras y límites para los entornos puede equilibrar mejor las necesidades de innovación, operaciones y esfuerzos de migración.

Alineación de cartera: las carteras orientadas a la gobernanza tienden a incluir puntos de datos que capturan los detalles de la innovación y las operaciones, como la carga de trabajo, el propietario de las operaciones, la clasificación de datos y la importancia operativa. Estos puntos de datos crean una vista completa de la cartera.

Definiciones de límite: los límites de una cartera orientada a la gobernanza tienden a favorecer las operaciones sobre la innovación al usar una jerarquía impulsada por un grupo de administración que se asigna a los criterios de las unidades de negocio y los entornos de desarrollo. En cada nivel de la jerarquía, un límite de gobernanza en la nube puede tener diferentes grados de aplicación de directivas para permitir el desarrollo y la flexibilidad creativa. Al mismo tiempo, se pueden aplicar requisitos en el nivel de producción a las suscripciones de producción para garantizar la separación de las tareas y la coherencia de las operaciones.

Pasos siguientes

Más información sobre cómo respaldan los productos de Azure la jerarquía de la cartera.