La adopción de un IDP requiere una estrategia pragmática
Incluso antes de adquirir o instalar una plataforma, una de las primeras preguntas que uno se hace es: ¿cuál proceso debería ser con el que comience? La pregunta puede llevar a un flujo de ideas que puede variar de lo que uno considera que es una plataforma, qué los compañeros de trabajo esperan de una plataforma, qué piensa aquellos que financian la iniciativa y también los whitepapers publicados, como la de la CNCF.
Los planteamientos de lo que queremos llevar se encuentran basados en los flujos de trabajo que se tienen en la empresa: Despliegues CI/CD, gestión de la nube, accesos, Kubernetes, entre otros. Estos mismos flujos de trabajo puede que estén en mayor o menor medida con una calidad que nos permita adoptarlos rápidamente y otros que habrá que trabajarlos desde cero. En base a los criterios que se elijan, uno se puede encontrar o implementar un poco de los siguientes dos caminos:
- Se revisa el flujo actual del mecanismo anterior: capacidad y comportamiento, dónde nace, quién aprueba, cómo se puede acoplar a un golden path, para convertirlo en un engranaje dentro de la plataforma, estandarizando y permitiendo que con el cambio se pueda mejorar el procedimiento original, y con ello el comportamiento de todo el sistema.
- Llevarse el proceso tal cual existe, y solo hacer los mínimos ajustes para que se pueda contar con él dentro de la plataforma, logrando obtener una oleada de colonos y casos de uso.
No tiene que ser una dicotomía; puede que se logre mejorar un paso del proceso. El arte es encontrar qué mejorar e implementar ahora y qué llevarte para después, dependiendo en gran parte del objetivo que se busque lograr.
Uno de los grandes beneficios de una plataforma es poder brindarle una mayor independencia a un desarrollador, que pueda ejecutar él mismo sus propias operaciones y que no tenga que depender de otros roles. Para lograr esto, se debe disponer de un ingeniero de plataforma que entienda el proceso, pueda abstraerlo e integrarlo en el sistema, o lleve el comportamiento actual, y mantener el flujo que siempre ha sido. En ambas vías, se ocupa un recurso para que pueda realizar la tarea mientras otras oportunidades quedan en la espera.
Ya que el capital humano y el tiempo son finitos, hay que negociar qué se puede traer o no rápidamente, con el beneficio por implementar un nuevo mecanismo a la empresa que promete integrar y facilitarle la vida a los desarrolladores y también la espera por un retorno de inversión.
Dependiendo de la cantidad de usuarios con la que se empiece, y sobre todo si la membresía de cada usuario se paga, el uso de la plataforma deberá ser justificado, y un número mayor de casos de uso puede girar la balanza a beneficio de la plataforma, permitiendo que más roles se sumen y a su vez desbloqueando más casos de uso. También la optimización de flujos de trabajo, puede llevar un anterior proceso que es lento a uno que apenas dure segundos, otorgándole gravitas a la plataforma.
La decisión consta de si se quiere crear un nuevo blueprint^1, o se busca habilitar workflows^2 en el IDP. Modificar un workflow puede ser realizado velozmente; modificar un blueprint, no. Dependerá de cuántos otros blueprints estén en aquel momento relacionados y cuánta data deberá ser migrada y transformada. Una acumulación de blueprints mal conceptualizados, a largo plazo, puede causar más deuda técnica acumulativa. De igual manera, un workflow de tu IDP podría incluso no tener asociado un blueprint y solo disponibilizar el flujo a través de regex que luego se puede reemplazar por un selector de una entidad de un blueprint construido de manera armoniosa en el sistema.
Incluso solo con workflows, puedes crear un feedback loop positivo: Workflows que cubran casos de uso existentes permiten que ingresen nuevos usuarios a la plataforma, aquello crea nuevas oportunidades y permite habilitar más workflows que traerán nuevos usuarios. Los blueprints pueden en pararelo irse trabajando para estandarizar y permitir que todos los procesos se integren y no sea solo una página con un botón ejecutar, aquello lo puede hacer GitHub o GitLab.
En base a
^1: Kind en Backstage ^2: Aproximadamente, Software Template en Backstage.