frameworks

No es la primera vez que me encuentro ante un nuevo proyecto en el que el cliente te exige utilizar ciertas tecnologías para sus desarrollos internos. Se trata de una compañía que tiene su propio departamento para satisfacer las necesidades software de la empresa (web corporativa, intranets, canal de pedidos, gestión de tickets e incidencias, etc.); ahora necesitan externalizar algunos trabajos.

No es que usen esas tecnologías porque sí, sino que es la misma política de empresa la que en su día decidió apostar por ellas y no salir de ahí salvo por un motivo bien justificado. De ese modo, todas las aplicaciones internas tienen cierta coherencia.

Esa decisión puede ser muy arriesgada: ¿y si basamos todos los desarrollos en este motor de base de datos que termina cayendo en desuso o cuya licencia sube de precio escandalosamente? ¿Y si usamos este framework para las interfaces de usuario web y con el tiempo surgen otros mucho mejores y productivos?

¿Acaso alguien tiene una bola de cristal y puede predecir las necesidades de la empresa a años vista? Puff...

Trabajar realizando proyectos software que deben tener una vida muy larga es en ocasiones gestionar muchísima incertidumbre en cuanto a la elección de las mejores tecnologías para ese proyecto.

Yo lo digo a menudo, y no me cansaré de repetirlo: es casi más importante usar bien una librería o framework que usar todo lo último porque sí. 

Por poner un sencillo ejemplo, me encanta Angular, es increíblemente productivo y te permite desacoplar muchos elementos de las interfaces de usuario para poder crear tests sobre ellos. Sin embargo, la nueva release Angular 2 es un mundo aparte en relación a la anterior versión y por tanto, si has hecho algo en los últimos años con Angular 1.x, pues ya sabes que o tendrás que continuar con ello mucho tiempo o tienes que plantear una migración, si te interesa, a la nueva versión. Y cómo no, desde el punto de vista empresarial, esa migración cuesta dinero...

Si el éxito de una compañía consiste, en parte, en mitigar y reducir riesgos, entonces definir el conjunto de tecnologías que usa para sus desarrollos internos puede tener sentido. Este enfoque no es único para grandes corporaciones, de ningún modo, cualquier organización de cualquier tamaño puede implementar esta política.

¿Qué ventajas puede aportar tener lo que podríamos llamar un framework corporativo?

Se me ocurren las siguientes:

• No hay curva de aprendizaje para los nuevos desarrollos: el equipo de trabajo ya domina las tecnologías que se usan.
• Al estar basado todo en las mismas librerías, lenguajes, etc., es más posible poder reutilizar componentes ya desarrollados para el resto de proyectos o aplicaciones.
• El mantenimiento de las distintas aplicaciones es (o debería ser) menor, si se ha definido una forma común a la hora de realizar los desarrollos.
• Es más sencillo plantear los flujos de trabajo, ya que éstos en ocasiones dependen de las tecnologías que se usan.

En el caso de este nuevo cliente, utiliza ExtJS, PL/SQL (bases de datos Oracle) y C# para todos o casi todos los desarrollos, además de procedimientos claramente definidos para la especifación, validación y puesta en producción de los nuevos desarrollos.

A la hora de definir un framework corporativo no hay que juzgar los gustos particulares de cada uno, sino evaluar si todo lo que se quiere usar encaja o no con las necesidades presentes y futuras de la compañía.

En el otro lado de la balanza están otras empresas que utilizan tal dispersión de tecnologías para sus desarrollos que finalmente el mantenimiento de todo termina siendo un gran obstáculo. Basta con ponerse en el lugar de alguien nuevo que llega al equipo de trabajo y que tenga que asumir diez tecnologías diferentes en lugar de un grupo reducido y coherente de ellas...