Jerarquía de cartera

Para comprender cómo funciona conjuntamente una cartera de cargas de trabajo, recursos y servicios auxiliares, debe establecer una jerarquía de la cartera. 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 ofrece 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 dependen de varias cargas de trabajo para ofrecer funciones empresariales vitales.

Normalmente, una parte interesada empresarial y un líder técnico comparten la responsabilidad del soporte continuo de cada carga de trabajo. En algunas fases del ciclo de vida de la carga de trabajo, esos roles se indican claramente. En fases más operativas del ciclo de vida de una carga de trabajo, esos roles pueden pasarse a un equipo de administración de operaciones compartido 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) se vuelven más complejos y adoptan una estructura matricial.

Las cargas de trabajo y sus recursos auxiliares están en el núcleo de cualquier cartera. Los ámbitos o capas definen cómo se ven esas cargas de trabajo y en qué medida se ven afectadas por la matriz de potenciales equipos de apoyo.

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

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

Al desplegar tu primera carga de trabajo, puede que la carga de trabajo y sus recursos sean el único ámbito definido. Es posible que las otras capas se definan explícitamente a medida que se implementan más cargas de trabajo.

Cartera de TI

Cuando las empresas admiten cargas de trabajo a través de enfoques en matriz o enfoques centralizados, es probable que exista una jerarquía más amplia para admitir esas cargas de trabajo:

• Zonas de aterrizaje: Las zonas de aterrizaje proporcionan a las cargas de trabajo las utilidades básicas e infraestructura compartida necesarias para admitir una o más cargas de trabajo. Las zonas de aterrizaje son tan críticas en la nube que toda la metodología de Ready 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 cartera tecnológica y empresarial.
• Base de plataforma: Esta construcción organizativa 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 general para admitir la cartera completa, es posible que los clientes necesiten varias plataformas en la nube con implementaciones distintas de la base de la plataforma para controlar varias regiones, soluciones híbridas o incluso soluciones multinube.
• Portfolio: Desde una perspectiva tecnológica, la cartera es una colección de cargas de trabajo, activos y recursos de apoyo que se extiende a través de todas las plataformas en la nube. A través de un objetivo empresarial, la cartera es la colección de proyectos, personas, procesos e inversiones que respaldan y administran la cartera tecnológica para impulsar los resultados empresariales. Juntas, estas dos lentes capturan el portafolio.

Responsabilidad e instrucciones de la jerarquía

Un equipo responsable administra cada capa de la jerarquía de cartera. En el diagrama siguiente se muestra la asignación entre el equipo responsable y las instrucciones para apoyar sus decisiones empresariales, decisiones técnicas e implementación técnica.

Nota

Los equipos mencionados en la lista siguiente pueden ser equipos virtuales o individuos. 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 Strategy y Plan para guiar las decisiones que afectan a la cartera general. El equipo de estrategia en la nube es responsable del nivel empresarial de la jerarquía de cartera de nube. El equipo de estrategia en la nube también debe informarse de las decisiones sobre el entorno, las zonas de aterrizaje y las cargas de trabajo de alta prioridad.
• Plataformas en la nube: El equipo de gobernanza de la nube es responsable de los límites de protección que garantizan la coherencia en cada entorno en consonancia con la metodología Govern. El equipo de gobernanza de la nube es responsable de la gobernanza de todos los recursos de todos los entornos. El equipo de gobernanza de la nube debe consultarse sobre los cambios que podrían requerir una excepción o un cambio en las directivas de gobernanza. El equipo de gobernanza de la nube también debe informarse del progreso con la adopción de cargas de trabajo y recursos.
• las zonas de aterrizaje y los fundamentos de la nube: El equipo de la plataforma en la nube es responsable de desarrollar las zonas de aterrizaje y las utilidades de la plataforma que facilitan la adopción. El equipo de automatización de la nube es responsable de automatizar el desarrollo y el soporte continuo de esas zonas de aterrizaje y utilidades de plataforma. Ambos equipos usan la metodología Ready para guiar la implementación. Ambos equipos deben informarse del progreso con la adopción de la carga de trabajo y los cambios en la empresa o el entorno.
• Cargas de trabajo: la adopción ocurre a nivel de carga de trabajo. Los equipos de adopción de la nube usan las metodologías de Migrar y Innovar para establecer procesos escalables para 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 Manage para guiar la administración de operaciones. Ambos equipos deben estar cómodos con microsoft Azure Well-Architected Framework para tomar decisiones arquitectónicas detalladas que afecten a las cargas de trabajo que admiten. Ambos equipos deben informarse de los cambios en las zonas de aterrizaje y los entornos. En ocasiones, ambos equipos pueden contribuir a las características de la zona de aterrizaje.
• Activos: 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 Azure Well-Architected Framework para realizar cambios detallados en los recursos y la arquitectura necesarios para cumplir los requisitos de operaciones.

Variantes de responsabilidad

• entorno único: Cuando una empresa solo necesita un entorno, normalmente no se requiere un CCoE.
• zona de aterrizaje única: Si un entorno solo tiene una sola zona de aterrizaje, es probable que las funcionalidades de gobernanza y plataforma se combinen en un equipo.
• carga de trabajo única: Algunas empresas solo necesitan una carga de trabajo, o algunas cargas de trabajo, en una sola zona de aterrizaje y un único entorno. En esos casos, hay poca necesidad de separar las tareas entre los equipos de gobernanza, plataforma y operaciones.

Ejemplos comunes de carga de trabajo y responsabilidad

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

Cargas de trabajo de COTS

Tradicionalmente, las empresas han preferido soluciones de software comercial de estantería (COTS) para impulsar los procesos comerciales. Estas soluciones se instalan, configuran y luego funcionan. Hay poco cambio en la arquitectura de las soluciones después de la configuración.

En estos escenarios, cualquier adopción en la nube de soluciones COTS finaliza con una transición a un equipo de operaciones en la nube. A continuación, 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 aplicación de revisiones 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 básicos de cumplimiento operativo para esas cargas de trabajo. Un equipo de operaciones en la nube debe trabajar con el equipo de gobernanza de la nube para alinear los costos, el rendimiento y otros pilares de arquitectura.

En desarrollo con revisiones activas

Cuando una solución COTS o una oferta de PaaS no están alineadas con la necesidad empresarial o no existe ninguna solución, las empresas crean cargas de trabajo desarrolladas de forma personalizada. Normalmente, solo un pequeño porcentaje de la cartera de TI usa este enfoque de carga de trabajo. Pero estas cargas de trabajo tienden a impulsar un porcentaje desproporcionadamente alto de la contribución de TI a los resultados empresariales, especialmente los resultados relacionados con los nuevos flujos de ingresos. Estas cargas de trabajo tienden a asignarse bien a nuevas ideas de innovación.

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

Debido a restricciones de tiempo y capital extensas, las opciones de desarrollo personalizado a menudo se limitan a las oportunidades de alto valor. Entre los ejemplos típicos se incluyen las innovaciones de aplicaciones, el análisis profundo de datos o las funciones empresariales críticas.

Resolución de problemas o desarrollo de ocaso

Después de que una carga de trabajo personalizada desarrollada alcance su madurez máxima, es posible que el equipo de desarrollo se reasigne a otros proyectos. En estos casos, la propiedad técnica normalmente pasa a un equipo de operaciones en la nube. Cuando haya necesidad de correcciones pequeñas, el equipo de operaciones inscribirá a los desarrolladores para resolver el error.

En algunos casos, el equipo de desarrollo se mueve a un proyecto que finalmente 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 normalmente actúa como propietario técnico a largo plazo y responsable de la toma de decisiones. Es probable que ese equipo inscriba a los desarrolladores de aplicaciones cuando los cambios operativos requieran cambios importantes en la arquitectura.

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 propietarios de operaciones y desarrollo con varios niveles de responsabilidad. Esos equipos deben alinear los cambios operativos y los cambios arquitectónicos para minimizar las interrupciones en la solución de producción.

Estos escenarios requieren un enfoque sólido en la separación de tareas. El equipo de operaciones generalmente mantendrá la responsabilidad de los cambios operativos diarios en el entorno de producción. Cuando esos cambios operativos requieran un cambio arquitectónico, el equipo de desarrollo o adopción los completará en un entorno que no sea de producción, antes de que el equipo de operaciones aplique los cambios a producción.

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

Alineación de cartera de estrategia

Es importante comprender los objetivos estratégicos del esfuerzo de adopción de la nube y alinear la cartera para respaldar esa transformación. Algunos tipos comunes de alineación estratégica de cartera ayudan a dar forma a la estructura de la jerarquía de carteras. En las secciones siguientes se proporcionan ejemplos de la alineación y el efecto de la cartera en la jerarquía de carteras.

Cartera centrada en la innovación o el desarrollo

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

Dado que el entorno hospeda soluciones personalizadas, la canalización de DevOps y los informes de nivel de aplicación podrían reemplazar la necesidad de operaciones y funciones de gobernanza. Es probable que esos clientes reduzcan el foco en las operaciones, la gobernanza u otros roles auxiliares. También es habitual un énfasis más fuerte en las responsabilidades de los equipos de adopción de la nube y automatización de la nube.

Alineación de la cartera: la cartera de TI probablemente se centrará en las cargas de trabajo y sus responsables para impulsar decisiones críticas de arquitectura. Es probable que esos equipos encuentren más valor en la guía de Azure Well-Architected Framework durante las actividades de adopción y operaciones.

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

Cartera gestionada por operaciones

Las organizaciones empresariales multinacionales con equipos de operaciones de TI más establecidos suelen tener un enfoque más sólido en la gobernanza y las operaciones que en el desarrollo. En estas organizaciones, un porcentaje mayor de las cargas de trabajo normalmente se alinea con las categorías COTS o de mantenimiento correctivo, gestionadas por propietarios técnicos dentro del equipo de operaciones en la nube.

Alineación de la cartera: la cartera de TI se alineará en función de la carga de trabajo, pero esas cargas luego se asociarán a las unidades operativas o a las unidades de negocio. También puede haber organización en torno a los modelos de financiación, el sector u otros requisitos de segmentación empresarial.

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

Cartera influenciada por tendencias migratorias

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

Alineación de la cartera: La cartera de TI podría estar alineada con la carga de trabajo, pero es más probable que esté alineada con los activos. Si se han producido transiciones a 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, es posible que muchos recursos no tengan una carga de trabajo definida o un propietario claro hasta avanzadas fases del proceso de migración.

Definiciones de límites: las zonas de recepción probablemente agruparán las aplicaciones en límites que reflejen la segmentación en las instalaciones. Aunque no es un procedimiento recomendado, los entornos suelen coincidir con el nombre del centro de datos local y las zonas de aterrizaje que representan prácticas de segmentación de red. Es una mejor práctica adherirse a una segmentación que se alinea más estrechamente con una cartera liderada por operaciones.

Cartera liderada por la gobernanza

La alineación con los equipos de gobernanza debe realizarse lo antes posible. Mediante prácticas de gobernanza y herramientas de gobernanza en la nube, carteras y límites ambientales pueden equilibrar mejor las necesidades de innovación, operaciones y esfuerzos de migración.

Alineación de cartera: Las carteras dirigidas por la gobernanza tienden a incluir datos que capturan detalles de innovación y operaciones, como la carga de trabajo, el responsable de operaciones, la clasificación de datos y la criticidad operativa. Estos puntos de datos crean una perspectiva integral de la cartera.

Definiciones de límites: En una cartera guiada por la gobernanza, los límites tienden a favorecer las operaciones sobre la innovación, utilizando una jerarquía controlada por grupos de administración que se alinea con los criterios de las unidades de negocio y los entornos de desarrollo. En cada nivel de la jerarquía, un límite de gobernanza de la nube puede tener distintos grados de aplicación de directivas para permitir el desarrollo y la flexibilidad creativa. Al mismo tiempo, los requisitos de nivel de producción se pueden aplicar a las suscripciones de producción para garantizar la separación de tareas y operaciones coherentes.

Pasos siguientes

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