El desarrollo de aplicaciones de gestión se debate desde hace años entre dos filosofías: los generalistas y los especialistas. Si bien últimamente ha aparecido una nueva categoría: Los frameworks. En la práctica todos desean construir la mejor escalera posible para subir desde la planta baja al primer piso de un edificio.

El framework aporta un nuevo concepto: existen varios escalones que pueden ser considerados ‘estándar’, y otros que pueden ser sustituidos a gusto del cliente, o comprados como un grupo. Por último, sólo algunos escalones deben ser hechos ‘en la obra’ completamente a medida. Esta filosofía tiene como ventaja, contra los programas generalistas monolíticos, que permite una gran adaptación a las necesidades del cliente. Aventaja a los programas especialistas en que habitualmente el framework en lo que respecta al módulo principal tiene un grado de terminación y calidad muy elevado, comparable al de programas generalistas con miles de horas/hombre de desarrollo. Además los framework procuran marcar unas pautas de integración visual y tecnológica a los programas que finalmente se construyen usando sus bien establecidos cimientos.

Sin embargo no todo es color de rosa. El framework no consigue competir con los programas monolíticos ya que en definitiva la escalera la han hecho varias empresas, y cada una de ellas quiere responsabilizarse únicamente de sus escalones lo que genera una tensión importante en el cliente, que no sabe quién es el responsable de que su sistema no funcione. Los escalones ‘estándar’ que se suponen hacen de base para otros no son tan sólidos como se espera, y los desarrollos sobre ellos no siempre tienen el éxito asegurado.

Por otra parte, cuando se compara el framework contra un programa especializado, este último tiene importantes ventajas finales, ya que el framework no deja de tener únicamente unos pocos escalones especializados, mientras que el otro proporciona una escalera completamente adaptada desde el primer peldaño.

El soporte técnico es un punto importante, el framework fracasa estrepitosamente en este punto ante las dos filosofías tradicionales, por un motivo básico: tanto el programa generalista, como el especialista, son soportados por agentes que únicamente tienen que conocer un programa, más o menos grande, pero uno sólo. Mientras que el soporte técnico del framework debe darlo un personal que debe conocer múltiples módulos diferentes y todos los problemas derivados de la interacción entre los diferentes módulos. Además de conocer cómo funciona el código especializado de cada tramo de escalera que han vendido a lo largo de su historia.

Otro punto conflictivo son las actualizaciones. Los modelos tradicionales evolucionan sus productos de forma completa, hay solamente un responsable final. El framework tiene enormes dificultades para evolucionar, cualquier cambio en los escalones bajos de la escalera afecta a toda la escalera. Lo que en muchas ocasiones provoca que el cliente tenga que acabar pagando la evolución tecnológica de los módulos que ha comprado, y el de rehacer los peldaños que se hicieron a su medida.

Finalmente el framework que promete unos costos bajos de propiedad termina fracasando en este aspecto también, no es raro ver propuestas de adaptación de varios miles de horas/hombre, lo que no deja de ser la negación de la filosofía en si misma, y la demostración de que los cimientos y la integración de nuevas características es al final un problema importante. A lo que hay que sumar las miles de horas necesarias para mantener, probar y evolucionar un software que finalmente quiere ser … un programa especializado.

0 comentarios

Dejar un comentario

¿Quieres unirte a la conversación?
Siéntete libre de contribuir!

Deja una respuesta