Construir un IDP consiste en decidir qué no optimizar
Incluso antes de adquirir o instalar una plataforma, una de las primeras preguntas que uno se hace es: ¿con qué proceso debería comenzar? Lo que queremos incorporar a la plataforma parte de los flujos de trabajo de la empresa, como despliegues CI/CD, gestión de la nube, accesos, Kubernetes, entre otros. Algunos de estos flujos ya tendrán la madurez suficiente para incorporarlos rápidamente; otros exigirán trabajo desde cero. Según los criterios que elijamos, podemos movernos entre dos estrategias:
- El equipo de plataforma revisa el proceso existente —su capacidad y comportamiento, dónde nace, quién aprueba, cómo integrarlo en un golden path— para convertirlo en un engranaje de la plataforma, estandarizarlo y, cuando sea posible, mejorar también el proceso original, y con ello el comportamiento de todo el sistema.
- El equipo también puede incorporar el proceso tal como existe, y solo hacer los mínimos ajustes para que se pueda contar con él dentro de la plataforma, para atraer una primera oleada de usuarios y casos de uso.
No tiene que ser una dicotomía: podemos mejorar solo una parte del proceso. El arte es encontrar qué mejorar e implementar ahora y qué dejar para después, dependiendo en gran parte del objetivo que se busque lograr.
Uno de los grandes beneficios de una plataforma es dar mayor autonomía al desarrollador para que pueda ejecutar sus propias operaciones y no tenga que depender de otros roles. Para lograrlo, un ingeniero de plataforma debe entender el proceso, abstraerlo e integrarlo en el sistema, o trasladar el comportamiento actual y conservar el flujo existente. Ambos caminos consumen capacidad del equipo de plataforma, mientras otras oportunidades esperan.
Dado que la capacidad del equipo y el tiempo son finitos, el equipo debe decidir qué incorporar ahora y qué posponer, con el beneficio por implementar un nuevo mecanismo a la empresa que promete integrar y facilitarles la vida a los desarrolladores y también la espera por un retorno de inversión.
Según cuántos usuarios adopten inicialmente la plataforma, y sobre todo si la membresía de cada usuario se paga, el equipo deberá justificar el coste de la plataforma, y un número mayor de casos de uso puede inclinar la balanza a favor 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 convertir un proceso antes lento en uno que tome apenas segundos, otorgándole gravitas a la plataforma.
La decisión es si queremos crear un nuevo blueprint1, o habilitar workflows2 en el IDP. Un workflow suele ser más sencillo de modificar que un blueprint. Dependerá de cuántos otros blueprints estén en aquel momento relacionados y cuántos datos tendremos que migrar y transformar. Una acumulación de blueprints mal conceptualizados, a largo plazo, puede causar más deuda técnica. De igual manera, un workflow de tu IDP podría incluso no tener asociado un blueprint y solo exponer el flujo mediante una expresión regular 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 reinforcing feedback loop3: 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. En paralelo, el equipo puede trabajar los blueprints para estandarizar y permitir que todos los procesos se integren y no sea solo una página con un botón ejecutar; aquello lo hace GitHub o GitLab.
Si implementar un workflow toma tres semanas y, a través de un flujo claro de aprobaciones y combinaciones de pasos ya existentes, reducimos su lead time de diez días a dos, aunque el proceso no sea el ideal, habremos reducido el lead time un 80 %. Con 500 ejecuciones mensuales, se conseguiría una reducción acumulada de 4.000 días de lead time al mes. En cambio, si un ingeniero de plataforma se dedica tres meses a reestructurar todo el proceso y consigue una mayor reducción en días, de diez a uno, se logra una reducción del 90 %, obteniendo únicamente 500 días adicionales de reducción acumulada de lead time al mes.
Asumiendo que, durante aquellos tres meses, con el mismo costo de tres semanas por workflow y el mismo ahorro de lead time, el mismo ingeniero podría haber construido al menos tres casos de uso adicionales, estos representarían 12.000 días de reducción acumulada de lead time al mes. Por una reducción adicional de 500 días, el coste de oportunidad perdido fue de 12.000 días de reducción acumulada al mes, es decir, 24 veces mayor.
Como una persona a la que le gusta mucho hacer lo mejor posible su trabajo, puedo entender que nos puede doler un poco aceptar que el proceso no esté refinado o que no se haya podido optimizar en el procedimiento. Al integrarlo en el IDP, podemos pulirlo en la medida de lo posible, pero al mismo tiempo una plataforma requiere empezar a funcionar y generar valor; daremos más autonomía al desarrollador mejorando cuatro procesos parcialmente que optimizando uno solo al máximo.