Adobe Ethos: liderazgo de producto para una plataforma interna de desarrollo

Situación: flujos fragmentados de desarrollo y operación

La infraestructura cloud proporciona cómputo y almacenamiento. Una plataforma interna de desarrollo también debe responder a preguntas organizativas: cómo iniciar un servicio, qué proceso de despliegue seguir, quién da soporte y quién resuelve un hallazgo de seguridad. Las respuestas fragmentadas crean dependencias entre producto, infraestructura, seguridad y operaciones.

Ethos conectó estas responsabilidades en Adobe. El modelo publicado ofrecía acceso directo a la plataforma y un proceso de despliegue más estandarizado. Lo utilizaban equipos de Creative Cloud, Document Cloud y Experience Cloud. La introducción de Adobe Tech Blog explica este modelo.

Tarea: tratar el flujo de desarrollo como un producto

Fui Lead PM / Group Product Manager de esta plataforma. El caso describe el trabajo de la plataforma y del equipo.

La pregunta de producto es dónde la estandarización evita trabajo repetido y dónde los equipos necesitan control. Una plataforma útil debe conectar los despliegues habituales y conservar la responsabilidad sobre cada servicio. La adopción, la carga de soporte y el diagnóstico de un despliegue fallido forman parte de la misma decisión que la infraestructura.

Enfoque: conectar entrega, controles y responsabilidad

• Un flujo de servicio completo: La arquitectura conecta la entrada del desarrollador, el control de versiones, la entrega automatizada y la ejecución. Cada transición requiere que el equipo entienda qué ocurre después, qué ha fallado y quién puede resolverlo.
• Seguridad dentro del despliegue: Adobe documentó imágenes base reforzadas, permisos de compilación, comprobaciones de vulnerabilidades, integración de secretos y políticas de red. Los controles forman parte del proceso; los equipos de servicio siguen siendo responsables de corregir los problemas. La descripción de seguridad de Adobe detalla la implementación.
• Responsabilidad por debajo de la cuenta cloud: La infraestructura compartida puede ocultar quién responde por una carga de trabajo. El relato de OpSec describe la atribución y validación del alta, desarrolladas con Ethos y el registro de servicios, para dirigir los hallazgos a sus responsables. El relato de OpSec en Adobe Tech Blog explica el problema y la respuesta.
• Una interfaz coherente con contribuciones distribuidas: Una presentación de Adobe en PlatformCon describe la unificación de interfaces internas y la participación de ingenieros de distintos equipos. La coherencia de uso y el proceso de contribución pasan a formar parte de la plataforma. La presentación en PlatformCon documenta ese trabajo.

Resultados: entrega compartida y responsabilidad identificable

• Plataforma operativa: El resumen de la charla de Adobe en PlatformCon describe la infraestructura Ethos existente en varias regiones y su ampliación a una plataforma de desarrollo más extensa. Operar infraestructura y ampliar la experiencia de desarrollo son etapas distintas.
• Experiencia de desarrollo unificada: La presentación en PlatformCon describe el paso de seis aplicaciones web internas a una interfaz que admite contribuciones de toda Adobe.
• Hallazgos de seguridad con destinatario: El caso de OpSec documenta el trabajo de atribución necesario para dirigir los hallazgos al equipo de producto o servicio responsable, en lugar de dirigirse solo al proveedor de la plataforma.

Son resultados publicados de la plataforma y del equipo. El diagrama reconstruye el modelo documentado; no es un inventario actual de los sistemas de Adobe. Estas fuentes no ofrecen mediciones comparables del antes y el después en costes, tiempo de entrega o disponibilidad.

Lecciones para invertir en una plataforma

• Evaluar el recorrido completo: Un portal resulta útil cuando el proceso desde crear un servicio hasta diagnosticar un incidente funciona entre los sistemas implicados.
• Hacer visible la responsabilidad: La ejecución centralizada no elimina la responsabilidad de la aplicación. La definición del servicio necesita contexto suficiente para soporte, permisos y correcciones.
• Elegir las abstracciones: Un proceso predeterminado con soporte reduce decisiones, pero los equipos necesitan una vía clara para requisitos que no encajan en él.
• Medir el resultado buscado: El tiempo de incorporación, las dificultades del despliegue, la demanda de soporte y la responsabilidad sobre hallazgos son preguntas útiles. El número de clústeres o visitas al portal no las responde.

Estas son mis conclusiones sobre el modelo operativo. El informe del taller IDP en Adobe Tech Blog amplía el debate sobre flujos de desarrollo, descubrimiento de recursos y medición del éxito.

Fuentes y reconocimiento

La fuente principal es el artículo Ethos y la transformación cloud-native de Adobe, publicado en Adobe Tech Blog. El diagrama es una nueva síntesis de las descripciones públicas, no una reproducción de la imagen del artículo.

Las demás fuentes aparecen junto a las afirmaciones correspondientes. Describen aspectos distintos de la plataforma; las propuestas de la comunidad no se presentan como capacidades ya implementadas en Ethos.