Framework corporativo: pan para hoy y hambre para mañana

¿Qué es exactamente un framework de desarrollo corporativo? En esencia, se trata de un marco de trabajo, un conjunto de librerías, herramientas, plantillas y convenciones creadas y mantenidas internamente por el departamento de arquitectura (o algún otro ente con un grado alto de expertise) de una gran empresa o administración pública, con el objetivo de estandarizar la forma en la que se construye el software dentro de la organización. Suele ser una capa de abstracción construida por encima de tecnologías estándar del mercado, que busca empaquetar la conexión a bases de datos, la seguridad, el logging o la auditoría para que los equipos de desarrollo no tengan que preocuparse por esos detalles de infraestructura.

Ventajas que nos venden: El pan para hoy

Cuando desde las altas esferas técnicas (o a veces de gestión) se propone la creación de un framework corporativo, la presentación suele estar llena de promesas brillantes. Se nos vende la reutilización de código como la panacea: "no reinventemos la rueda en cada proyecto". Se prioriza la homogeneización, asegurando que todas las aplicaciones de la compañía tendrán la misma estructura, lo que teóricamente permite que un desarrollador salte del Proyecto A al Proyecto B con una curva de aprendizaje cercana a cero.

Un ejemplo claro y público de esta filosofía lo podemos encontrar en la administración, como el Framework de desarrollo para microservicios de la Junta de Andalucía (ADA Fwk MS). Sobre el papel, la idea es fantástica: ofrecer un ecosistema donde el andamiaje está resuelto y el desarrollador solo tiene que preocuparse por la lógica de negocio. Es un inicio rápido, seguro y estandarizado. Es el "pan para hoy".

Desventajas a medio/largo plazo: el hambre para mañana

Sin embargo, tras más de 20 años en este sector, he visto nacer, crecer y morir a algunos de estos frameworks, incluso he participado en su implemenación, en la creación de lo que empieza como un acelerador pero que casi siempre acaba convirtiéndose en un lastre. 

 

Las señales de que algo no va según lo planeado no tardan en aparecer, pero algunas personas (más bien de la dirección) no son capaces de ver con claridad y normalmente se dejan pasar hasta que se convierten en verdaderos problemas. Yo mismo no he sido capaz, hasta que he alcanzado un grado de experiencia, de percibir algunas de estas  señales que son grandes desventajas de la implantación de estos marcos de trabajo corporativo. Algunas de las cuales resumo a continuación:

• El framework sobre otros frameworks (y el infierno de las versiones): Muchos de estos desarrollos corporativos no son más que un "wrapper" o envoltorio sobre tecnologías consolidadas como Spring Boot, Angular o React. ¿El problema? El mercado avanza a una velocidad vertiginosa, pero el equipo interno que mantiene el framework corporativo tiene una capacidad limitada. Como resultado, la organización se queda atrapada en versiones obsoletas. Spring Boot saca una nueva versión mayor, pero tú no puedes actualizar porque el framework corporativo aún no es compatible, exponiendo a la compañía a vulnerabilidades de seguridad y privando a los equipos de nuevas funcionalidades. 

• Acoplamiento forzado y el peso de las dependencias (el síndrome del elefante): Al adoptar el framework corporativo, generalmente te obligan a bregar con dependencias que no necesitas. Esto significa que tu pequeño microservicio —que a lo mejor solo necesita exponer un endpoint REST básico— termina heredando transitivamente librerías para generar PDFs, clientes SOAP legacy, drivers obsoletos de bases de datos y motores de plantillas que jamás vas a usar. Este acoplamiento a dependencias innecesarias no solo engorda los entregables (los famosos JARs o contenedores hipertrofiados en Java) y penaliza los tiempos de arranque (algo fatal en entornos cloud modernos), sino que aumenta drásticamente la superficie de ataque. De repente, tu aplicación tiene que ser parcheada de urgencia por una vulnerabilidad crítica en una librería de procesamiento XML que tu código ni siquiera necesita, pero que el framework te ha obligado a tragar.  También se podría mencionar en este apartado ese gran problema de diseño que te obliga a implementar métodos si heredas de alguna clase del framework; esos @Override con return null que tanto y tanto he visto, porque en tu proyecto nunca jamás se va a llamar a ese metodo o función pero que por obligación alguien debió implementar y encima devolviendo nulo.

• Documentación deficiente y la muerte de la "Developer Experience" (DX): En el mundo real, si tengo un problema con Spring o Angular, lo busco en Google, en StackOverflow o pregunto a la IA y tengo cientos de respuestas. Si tengo un problema con el FrameworkCorp 3.1, dependo de una wiki interna que probablemente lleve dos años sin actualizarse. Y eso en el mejor de los casos. En lugar de acelerar el desarrollo, pasamos horas depurando código ofuscado o librerías internas mal documentadas. El resultado es exactamente el contrario al perseguido: la experiencia y la moral del desarrollador caen en picado.

• Minimización del progreso y fuga de talento: Al obligar a los desarrolladores a usar este marco de trabajo corporativo, se les aísla del mercado real. Dejan de aprender los estándares, patrones y frameworks modernos que demanda la industria para convertirse en "expertos" en una herramienta que solo existe en las cuatro paredes de esa empresa. El talento inquieto se frustra y desaparece.

• El mismo martillo para todos los clavos: Es la famosa Ley de Maslow o Golden Hammer. Como hemos invertido cientos de miles de euros en crear este framework, ahora hay que usarlo para todo. ¿Una API compleja y transaccional? Framework corporativo. ¿Un microservicio ligero o un simple script de integración? Framework corporativo. Se fuerzan soluciones antinaturales solo por cumplir con la norma.

• Un corsé para la innovación: Estos frameworks suelen ser muy rígidos. Si el proyecto requiere una base de datos NoSQL exótica o una librería de procesamiento asíncrono que no estaba prevista por los arquitectos originales, integrarla se convierte en una pesadilla burocrática y técnica. El framework encorseta las soluciones y asfixia la creatividad de los ingenieros.

• Estandarización de las malas prácticas por falta de formación: Se tiende a pensar que el framework "lo da todo hecho" y que es "a prueba de tontos". Esto lleva a las empresas a recortar en formación de calidad. Se limitan a decir: "usa el framwork corporativo, ya te lo da hecho". La realidad es que acabas teniendo 50 aplicaciones construidas con el mismo patrón deficiente, propagando las mismas inconsistencias arquitectónicas a gran escala. Una arquitectura (por muy buena que parezca) nunca podrá sustituir a un equipo de desarrolladores bien formados en principios SOLID, Clean Code y diseño de software.

   

Opinión final

Y aquí es donde llega el apogeo de la polémica, ya que entiendo que mi opinión no es compartida por algunos grupos de personas. Lo cual es muy respetable. Las opiniones tampoco deberían ser corporativas ni derivadas de un marco de trabajo.

 

No creo que la intención detrás de los frameworks corporativos sea mala; nacen de una necesidad real de gobernar el caos en grandes organizaciones. Sin embargo, el coste de mantenimiento y la inmensa deuda técnica, o más que deuda técnica, me ha gustado mucho algo que leí sobre la gestión del coste basal del software como el gasto mínimo para que el sistema siga funcionando. Y si no se gestiona, crece hasta consumir toda la energía del equipo. Llegando a no compensar los beneficios inicialmente previstos.

La abstracción es una herramienta poderosa pero, como decía Joel Spolsky, todas las abstracciones no triviales tienen fugas (leaky abstractions). Cuando esa abstracción te aísla del estándar del mercado, te condena a la obsolescencia.

El mero planteamiento de querer generar un marco de trabajo corporativo es una idea obsoleta. Hace 20 (o 30) años podía tener algún sentido, y no dudo que en aquella época se lograron casos de éxito, pero hoy en día, a la velocidad y grado de madurez existente en las herramientas que proporciona el mercado y sobre todo basadas en software libre, lo considero un gran atraso.

Desde mi experiencia, el enfoque moderno no debería ser crear un "framework dictatorial", sino proporcionar plantillas, librerías pequeñas y modulares (sin acoplamiento fuerte) y guías de estilo claras. Y sobre todo, la mejor inversión que puede hacer una empresa no es empaquetar código para que sus empleados piensen menos, sino invertir en la formación de calidad para esos empleados con el objetivo de que piensen mejor. Eso sí es pan para hoy, y un banquete para mañana.