El modelo de organización impacta la compartición.
- Describe la estructura de los departamentos, unidades y equipos.
- Dirige las actividades hacia objetivos específicos.
- Orienta el flujo de información dentro de la empresa.
Un modelo organizativo describe la estructura de una empresa u organización y dirige diversas actividades para alcanzar un objetivo concreto. También determina el flujo de información dentro de una empresa.
Varios modelos de organización son relevantes para la implementación de prácticas DevOps.
Estos son algunos de los modelos más comunes:
1. Silos funcionales: este modelo organizativo tradicional implica equipos funcionales separados, como los de desarrollo, operaciones, pruebas y control de calidad. Cada equipo trabaja de forma aislada, lo que provoca traspasos y retrasos en el proceso de entrega del software. DevOps pretende acabar con estos silos y promover la colaboración interfuncional.
2. Equipos multifuncionales: En este modelo, los equipos multifuncionales se forman reuniendo a personas de diferentes disciplinas, como desarrolladores, ingenieros de operaciones, probadores y analistas de negocio. Estos equipos trabajan juntos durante todo el ciclo de vida del desarrollo de software, fomentando la colaboración, la Propiedad compartida y una entrega más rápida.
3. Equipos Ágiles: Los equipos Ágiles son equipos autoorganizados e interfuncionales que siguen principios y prácticas ágiles. Trabajan en iteraciones cortas, ofrecen valor incremental y se centran en el cliente. Los Equipos Ágiles suelen incorporar prácticas DevOps en su flujo de trabajo para permitir la integración continua, la entrega continua y la mejora continua.
4. Modelo de Topologías de equipos: El flujo de valor y los equipos definidos de forma similar se centran en la entrega de valor al cliente de principio a fin. Estos equipos son responsables de todos los aspectos del desarrollo y la entrega de software, incluidos el desarrollo, las pruebas, la implantación y las operaciones. Los Equipos de flujo de valor garantizan una colaboración y alineación perfectas en las distintas fases del flujo de valor.
5. Modelo Site Reliability Engineering (SRE): SRE es un modelo organizativo popularizado por Google que combina principios de ingeniería de software y operaciones. Los equipos de SRE se centran en garantizar sistemas fiables y escalables aplicando prácticas de ingeniería de software a las tareas de operaciones. Los equipos de SRE trabajan en estrecha colaboración con los equipos de desarrollo para implantar y mantener sistemas de producción fiables.
6. Scaled Agile Framework (SAFe): SAFe es un modelo organizativo que proporciona orientación para implantar prácticas Ágiles y DevOps a escala. Define funciones, responsabilidades y procesos para el desarrollo de software a gran escala. SAFe incorpora principios DevOps, como equipos multifuncionales, integración continua y despliegue automatizado, para permitir una entrega de valor eficiente.
7. Centro de Excelencia (CoE): Un CoE es un equipo o grupo dedicado que impulsa iniciativas internas de producto dentro de una organización. El CoE proporciona orientación, mejores prácticas, herramientas y marcos para apoyar la adopción de prácticas de productos en diferentes equipos. Actúa como centro de intercambio de conocimientos, formación y fomento de una cultura de colaboración.
Es importante señalar que el modelo organizativo más eficaz para DevOps puede variar en función del contexto específico, el tamaño de la organización y el sector. las organizaciones también pueden adoptar un modelo híbrido o personalizar los modelos existentes para adaptarlos a sus necesidades y requisitos exclusivos. La clave está en promover la Colaboración, eliminar silos y fomentar una cultura de mejora continua y centrada en el cliente.
El enfoque DevOps del modelo organizativo.
Las organizaciones suelen formar equipos del producto autónomos, dotados de competencias diversas para ser autosuficientes. Sin embargo, la reutilización en distintos proyectos o áreas es nula.
Las organizaciones suelen acabar creando equipos del producto para crear equipos independientes y autónomos. Estos equipos tienen todos los conocimientos y habilidades necesarios y pueden ayudar a crear una mejor configuración. Pero este modelo tiene de desventajas.
La reutilización en diferentes proyectos o áreas es nula. Incluso con su independencia, los Equipos del producto siguen necesitando competencias centralizadas que pueden generar despilfarro.
Una configuración de este tipo requiere muchas dependencias, por lo que varios Equipos del producto no pueden funcionar de forma totalmente independiente unos de otros. Crear únicamente Equipos del producto no difiere del escenario de una organización tradicional en la que las personas se distribuyen entre diferentes departamentos en función de su especialidad.
En este tipo de organización, cada departamento trabaja para una funcionalidad específica y tiene una fuerte dependencia de otros departamentos. En tal dependencia, si hay un nuevo requisito o un cambio en la funcionalidad existente de una aplicación, ¿qué sucederá?
Tiene que conectar con cada departamento para discutir los requisitos y plantear la solicitud requerida. Además, tiene que esperar cuando la solicitud pasa de un departamento a otro para su tramitación. A veces, esa espera puede suponer incluso más del 90% de todo el tiempo de tramitación.
Así pues, tomarse DevOps al pie de la letra no es ninguna solución.
En un Entorno DevOps, los Equipos del producto se estructuran en torno a una plataforma de autoservicio, como se muestra en la siguiente figura.
En el modelo organizativo comentado anteriormente, la estructura consistía únicamente en equipos de producto autónomos. Aunque este modelo puede funcionar en determinados contextos, no siempre es eficaz debido a su inherente falta de reutilización y dependencia de capacidades centralizadas, lo que a menudo genera ineficacia y despilfarro. Para superar estos inconvenientes, introducimos un enfoque más eficaz del modelo organizativo, centrado en la colaboración entre Equipos de plataforma y Equipos del producto.
En esta configuración, los Equipos de plataforma se estructuran en torno a una plataforma de autoservicio que ofrece servicios estandarizados integrales a los Equipos del producto.
Esta plataforma (o el Equipo de plataforma) ofrece un amplio conjunto de capacidades de autoservicio estandarizadas a los Equipos del Producto, como la supervisión y la seguridad.
Esta configuración permite a los equipos de Producto operar de forma autónoma colocando su código de aplicación e infraestructura en la plataforma de autoservicio y gestionando completamente sus productos. Por otra parte, el equipo de Plataforma gestiona y supervisa las cualidades del sistema de sus productos independientemente de los productos de aplicación asociados. Este modelo organizativo permite a los equipos asumir la responsabilidad integral de sus productos o servicios. Por tanto, ambos equipos, los de Producto y los de Plataforma, son responsables de las cualidades de sus productos, como la disponibilidad y el rendimiento.
Dado que los equipos del producto utilizan los productos/servicios de la plataforma y son los clientes del equipo de plataforma, es esencial que ambos equipos interactúen entre sí. Aquí es donde las API les ayudan a interactuar entre sí. Se trata de una pieza de software que permite que dos aplicaciones se comuniquen entre sí. Tal configuración de la infraestructura en una organización DevOps resulta en varios beneficios de reutilización, como Microsoft Azure, Amazon Web Services y Google Cloud.