Zoológico tecnológico en proyectos: qué es, causas y soluciones

Qué es un zoológico tecnológico en un proyecto

Zoológico tecnológico es una situación en la que un proyecto o empresa utiliza una cantidad excesiva de herramientas heterogéneas que resuelven la misma tarea. Por ejemplo, tres clientes HTTP diferentes (Alamofire, OkHttp, Ktor), dos gestores de estado (Redux, MobX) y tres bases de datos (Realm, CoreData, SQLite).

La diferencia entre un zoológico y una elección deliberada de diferentes herramientas para diferentes tareas es la ausencia de una estrategia. Si el equipo A elige React Native, el equipo B elige Flutter y el equipo C elige Kotlin Multiplatform sin una decisión común — eso es un zoológico. La diversidad en sí misma no es dañina; lo dañino es su naturaleza descontrolada.

Cada nuevo stack en un proyecto aumenta la carga cognitiva para los desarrolladores. Para trabajar de manera efectiva, uno debe recordar los matices de todas las tecnologías utilizadas. Según Google (2024), el cambio de contexto entre diferentes stacks reduce la productividad del desarrollador en un 23% en comparación con trabajar en un entorno tecnológico unificado.

Causas de un zoológico tecnológico

Decisiones descentralizadas son la causa principal. Cada equipo elige tecnologías para su proyecto sin tener en cuenta la estrategia general. El equipo de backend usa Kotlin, el equipo de ML usa Python, el equipo móvil usa Flutter. Individualmente, las decisiones son correctas, pero juntas crean un zoológico.

Fusiones y Adquisiciones (M&A) — cuando una empresa adquiere otra, los stacks tecnológicos se fusionan. Dos sistemas resuelven los mismos problemas de manera diferente. Ejemplo: después de adquirir una startup, una gran empresa obtiene su stack Ruby on Rails, aunque el estándar interno es Java Spring. Surge la pregunta: reescribir o mantener dos stacks en paralelo.

Cambio de tecnologías de moda — cada ciclo de hype agrega un nuevo stack. En 2015, todos escribían en AngularJS, en 2017 — en React, en 2020 — en Svelte. Sin disciplina, un proyecto acumula capas de diferentes épocas. Los módulos heredados que funcionan pero no tienen soporte agregan heterogeneidad sin la posibilidad de eliminarla rápidamente.

Por qué un zoológico es peligroso para el equipo y el negocio

La incorporación de nuevos desarrolladores se convierte en aprender 5+ tecnologías diferentes en lugar de una. En lugar de una semana para integrarse al proyecto, un recién llegado pasa un mes dominando todas las herramientas utilizadas. El tiempo hasta la productividad crece proporcionalmente al número de stacks en el proyecto.

Cambio de contexto — un desarrollador que trabaja con 3+ stacks durante el día gasta hasta un 30% del tiempo restaurando el contexto después de cada cambio. Según la Universidad de California (2023), después de cada cambio se necesitan 23 minutos para volver al nivel de productividad original. Con 5 cambios por día — casi 2 horas perdidas.

Riesgos de seguridad — cada stack requiere actualizaciones, monitoreo de vulnerabilidades y conocimiento de mejores prácticas. Un equipo no puede ser experto en todas las tecnologías simultáneamente. La fatiga de dependencias — cuando el número de bibliotecas utilizadas supera la capacidad del equipo para rastrearlas y actualizarlas — es una amenaza directa a la seguridad del producto.

Complejidad de infraestructura — CI/CD necesita configurarse para cada stack. Diferentes sistemas de compilación (Gradle, CocoaPods, npm, pip), diferentes requisitos de entorno. El equipo de infraestructura gasta recursos manteniendo pipelines heterogéneos en lugar de mejorarlos.

Cómo diagnosticar el problema en un proyecto

Inventario del stack — compila una lista completa de las tecnologías utilizadas: lenguajes, frameworks, bases de datos, CI/CD, sistemas de monitoreo. Para cada tecnología, anota la cantidad de proyectos/módulos, el nivel de soporte y la cantidad de desarrolladores competentes en ella a nivel profesional.

Technology Radar — un método de ThoughtWorks que divide las tecnologías en 4 cuadrantes: Adopt, Trial, Assess, Hold. Adopt — stacks recomendados, Trial — experimentales, Assess — en evaluación, Hold — no recomendados para su uso. Ejemplo: Flutter en Adopt, React Native en Hold — los equipos entienden qué elegir.

Métrica de costo de mantenimiento — estima cuántas horas de ingeniería se gastan en mantener cada stack por mes. Si un stack consume el 10% de los recursos pero se usa en el 2% de los módulos — es candidato para ser reemplazado. Un mapa de calor del stack con ejes "cantidad de proyectos" vs "complejidad de mantenimiento" muestra claramente las áreas problemáticas.

Métodos para estandarizar el stack tecnológico

Architecture Decision Records (ADR) — documentación de decisiones arquitectónicas con justificación de las elecciones tecnológicas. Cada ADR contiene contexto, alternativas consideradas y argumentos para la elección. Michael Nygard (2022) popularizó este enfoque, y hoy ADR es un estándar para equipos que controlan la diversidad tecnológica.

Technology Review Board — un comité de desarrolladores líderes que aprueba nuevas tecnologías en el proyecto. Las decisiones se toman según criterios: compatibilidad con el stack existente, soporte de la comunidad, costo de migración, disponibilidad de talento. Spotify ha utilizado un comité similar desde 2018.

Puerta de entrada para nuevos proyectos — una regla: cualquier nuevo servicio o módulo utiliza solo el stack aprobado. Las excepciones son posibles mediante ADR con justificación. Ejemplo: un nuevo microservicio puede escribirse en Kotlin solo si el equipo demuestra que Java no es adecuado para esta tarea. El uso sin barreras de cualquier tecnología está prohibido.

Reducción gradual de la diversidad de stacks

Fase 1: Congelación — se detienen los nuevos proyectos en stacks no soportados. Se establece una fecha de fin de vida útil para cada stack en el cuadrante Hold. La nueva funcionalidad se escribe solo en stacks aprobados. Los módulos heredados continúan funcionando pero no se amplían.

Fase 2: Consolidación — se elige una herramienta para cada tarea. Un cliente HTTP, un gestor de estado, una base de datos. Los módulos en stacks alternativos se programan para migración por prioridad. El patrón Strangler Fig es el método principal para el reemplazo sin tiempo de inactividad del sistema.

Fase 3: Migración — cada sprint, el equipo asigna el 20% del tiempo para reescribir módulos críticos de stacks obsoletos a los aprobados. La arquitectura objetivo se documenta y no cambia sin una decisión del comité. El proceso toma de 6 a 24 meses dependiendo de la escala del zoológico.

Ejemplo: Migración de clientes HTTP

// Before: 3 different HTTP clients in one project
class HttpClientResolver {
    def resolve(moduleName) {
        switch(moduleName) {
            case "payments": return new OkHttpClient()
            case "chat": return new KtorClient()
            case "analytics": return new RetrofitClient()
        }
    }
}