Ninguna organización decide un día tener siete lenguajes, cuatro bases de datos y tres formas distintas de desplegar. Se llega ahí por acumulación de decisiones razonables: cada equipo eligió en su momento la herramienta que mejor resolvía su problema. El coste no está en ninguna de esas decisiones por separado; está en la suma, y no aparece en ninguna estimación.
Dónde se paga
En la incorporación de personas. Con un stack coherente, alguien nuevo es productivo en semanas. Con seis stacks, es productivo en el suyo y sigue siendo inútil en los demás, lo que a efectos prácticos convierte a la organización en varias organizaciones pequeñas.
En las guardias. Este es el coste más severo y el menos visible. Una rotación de guardias solo funciona si quien está de turno puede intervenir en cualquier sistema. Con tecnologías dispares, la guardia se fragmenta en varias rotaciones pequeñas, y las rotaciones pequeñas queman a la gente.
En la seguridad. Cada tecnología tiene su ciclo de actualizaciones, sus vulnerabilidades y sus prácticas de fortificación. Mantener seis al día no cuesta seis veces más que una: cuesta más, porque el conocimiento no se transfiere.
En la dependencia de personas concretas. Cuando un componente crítico está escrito en algo que domina una sola persona, la organización tiene un riesgo operativo con nombre propio. Cuando esa persona se va de vacaciones, se nota; cuando se va de la empresa, se sufre.
Lo que no queremos decir
Estandarizar no significa imponer una única herramienta para todo. Esa postura produce el problema contrario: equipos forzando tecnologías que no encajan y construyendo soluciones peores para cumplir una norma.
Tampoco significa congelar el catálogo. Una organización que no incorpora nada nuevo en cinco años acumula una obsolescencia que acaba pagando de golpe, y además pierde capacidad de atraer talento.
El planteamiento que funciona
Lo que mejor resultado nos da es explicitar tres categorías y revisarlas periódicamente.
- Por defecto. Un conjunto reducido de tecnologías que se usan salvo que haya un motivo. Están documentadas, hay plantillas, y cualquiera del equipo puede intervenir en ellas.
- Permitidas con justificación. Opciones válidas para casos concretos, que requieren argumentar por qué la opción por defecto no sirve. La justificación no es burocracia: es lo que evita que la elección sea por preferencia personal.
- En evaluación. Tecnologías que se están probando en algo acotado y sin criticidad, con fecha para decidir si suben a permitidas o se descartan. Sin esa fecha, todo se queda en evaluación para siempre.
La clave está en quién decide y cada cuánto se revisa. Si el catálogo lo fija un comité que se reúne dos veces al año, los equipos lo esquivarán. Si lo mantiene gente que además construye, y se revisa cada trimestre, se respeta.
Qué hacer con lo que ya está fuera del catálogo
La respuesta casi nunca es migrarlo todo. Reescribir un servicio que funciona para que encaje en el estándar es de las inversiones con peor retorno que existen.
El criterio razonable es dejar de crecer en lo no estándar y migrar solo cuando ya hay que tocar el componente por otro motivo: una reescritura necesaria, un cambio de requisitos, un fin de soporte. Así la convergencia ocurre a coste marginal en vez de como proyecto.
Y hay una excepción que sí justifica migrar por sí sola: cuando una tecnología concentra riesgo operativo en una única persona. Ahí el coste de no hacer nada es más alto que el de migrar.
¿Vuestro stack ha crecido sin control? Hablemos de por dónde empezar a ordenarlo →
Sigue leyendo
- Plataforma interna de desarrollo: cuándo compensa montarla
- ¿Multi-cloud o un solo proveedor? Cómo decidirlo sin dogmas
Puedes ver todo lo que hacemos en servicios, o echar un vistazo a los tipos de proyecto que solemos abordar.