Desarrollo de software: La necesaria evolución hacia un framework único
Dicen que los conversos son los más radicales, tal vez sea ese el motivo.
Cuando empecé en esto (tampoco hace tanto) era partidario de dar una cierta libertad a los proveedores siempre y cuando la tecnología de desarrollo utilizada fuera Java que era nuestra apuesta en ese sentido.
Poco después me di cuenta de que ese modelo no es sostenible en una organización como la nuestra donde tenemos en producción una gran cantidad de aplicaciones y tenemos continuamente proyectos en desarrollo y mantenimiento. Nos encontrábamos con aplicaciones desarrolladas con distintos frameworks (unos estándares, otros artesanales) cuando no sin ninguno, con distintas políticas en relación a la configuración, al uso de librerías dependientes, nomenclatura de componentes, etc… que dificultaban enormemente la idea de unificar mantenimientos y su posible industrialización, así como el proceso de implantación (prácticamente cada sistema tenía su propio manual de instrucciones) y el posterior proceso de mantenimiento de la infraestructura de servidores de aplicaciones.
Todo eso dio lugar a la decisión de restringir los desarrollos al uso de determinados frameworks e implementaciones de los distintos componentes de la arquitectura basados en soluciones consideradas estándar de mercado y libres, de esta forma nos damos cabida a soluciones propietarias y artesanales, acotamos las posibles alternativas en el diseño y construcción de la aplicación y además aprovechamos para introducir una serie de buenas prácticas.
Y en ese camino estamos, teniendo en cuenta que desde que se tomó esa decisión se ha ido restringiendo paulatinamente las distintas posibilidades que se daban y esa será la tendencia en un futuro, seguir creando restricciones para disminuir las alternativas posibles a la hora de elegir diferentes implementaciones de los distintos componentes que conforman la arquitectura.
Una de las primeras preguntas que surgen alrededor de esto es cómo plasmar en las reglas de desarrollo la evolución de los frameworks y componentes especificados así como la aparición de otras alternativas emergentes.
Cuando se opta por una estrategia restrictiva es lógico que todo no sean ventajas, hay inconvenientes y uno de ellos es que la incorporación de modificaciones en el modelo elegido no se puede realizar de forma inmediata sino que los cambios deben hacerse de forma escalonada siendo los escalones más grandes para cambios importantes en el modelo. Si optásemos por cambios continuos no conseguiríamos esa estabilidad que necesitamos a nivel de arquitectura.
Otro aspecto que podría resultar un inconveniente es que el hecho de restringir las soluciones implicará que los proveedores se tengan que adaptar a nuestro framework cuando lo mismo están especializados en otros frameworks o componentes en el que tienen más experiencia y son más productivos, pudiéndose ver afectada la calidad final de los trabajos. En cualquier caso, las ventajas de que todos los que trabajen para nosotros lo hagan con un modelo común superará esos inconvenientes relacionados con la adaptación.
¿Cuál debería ser nuestro siguiente paso si tuviéramos los medios necesarios (de momento no los tenemos? Pues orientar todavía más el proceso de desarrollo a través de una serie de herramientas que lo automaticen que irían desde el uso de un generador de código base para el framework, la incorporación de intérpretes de modelos UML que permitan la incorporación de lógica de negocio, así como la incorporación de facilidades para el diseño de la capa de presentación. De esta forma los proveedores se tendrían que adaptar al uso de esas herramientas (facilitando su proceso de aprendizaje sobre nuestro framework) y el resultado final sería todavía más homogéneo ya que los distintos componentes generan código minimizándose en lo posible (en unos casos será más y en otros menos) la intervención humana en la codificación.
La generación de código implica soluciones más generales en el código resultante por lo que se podrían ver afectadas algunas métricas de calidad. Cuando se opte por estrategias de este tipo es necesario tener un equipo de personas dedicadas al perfeccionamiento de los distintos componentes utilizados en el proceso de construcción.
Jummp 
Hola Jesús, me parece muy interesante el aporte que haces sobre la estandarización de los marcos de desarrollo de una organización, al fin y al cabo el coste del mantenimiento y de integración de aplicaciones se dispara cuando conviven desarrollos con gran variedad de arquitecturas y tecnologías. Pese a esta decisión, que como ya digo, me parece acertada, no soy partidario de una restricción extrema que deje al proveedor nada más que un solo camino para realizar un desarrollo, ya que nos podemos encontrar con ese camino no sea el más adecuado y en cambio sea el obligatorio; consiguiendo con esto que la unificación no convenza a ninguno de las partes.
Sobre la generación de código, parece ser que poco a poco se está imponiendo lo que se conoce como MDD/MDA que no es más que definir modelos que representen la realidad del problema y seguir la traza de abstracción entre modelos intermedios hasta llegar a la aplicación generada. La recomendaciones de los expertos van más allí de la simple generación de clases a través de diagramas UML, si no que animan a subir de nivel y crear diagramas propios (con su iconografía, elementos, etc) con los que se puedan modelar realmente la realidad de una organización o empresa.
Por último, destacar que en este ámbito ya hay instituciones que están apostando por el MDA, como es la Comunidad Valenciana a través de su herramienta MOSKitt, y que hará que poco a poco el desarrollo de software se centre más en la validez de los requisitos y sus modelos que en aspectos técnicos de implementación.
Un saludo.
Hola Edu. Agradezco mucho tu comentario y estoy de acuerdo en todo menos una cosa:
Es cierto que cuando se restringe el framework se tiene que optar por una solución (que en realidad son un compendio de soluciones entre las cuales constituyen el marco de desarrollo) y que esa solución puede ser errónea o más que errónea tal vez no sea la mejor para determinados tipos de desarrollo, pero la flexibilización o no del mismo no es un tema que se deba discutir con proveedores (en todo caso con el proveedor o proveedores que te han ayudado, si ha sido necesario, a definirlo) ya que es una decisión estratégica. Los proveedores entran y salen, la organización prevalece.
Lo importante es que siempre antes de realizar una contratación los posibles proveedores conozcan las reglas del juego y que ellos decidan si les conviene o no.
Habrá circunstancias, desarrollos concretos que sean excepciones y donde se flexibilice el framework, nada puede estar por encima del sentido común, ahora bien, esto exige responsabilidad por parte de quien toma las decisiones porque dar cabida a criterios arbitrarios abre una grieta que después puede convertirse en un gran agujero.
Gran idea. Lo único que se necesita es alguien con el valor y la capacidad dentro de la organización como para querer aplicarla, con la inyección presupuestaria que ello implica…
Eso sí, si se hace bien, puede resultar muy rentable, puesto que se reduciría notablemente el gasto en mantenimiento correctivo y las negociaciones con los proveedores sobre qué entra en el mismo.
Has tocado un aspecto clave y es que se crea en que esto puede producir buenos resultados y se invierta en esto. Desde mi punto de vista, una organización lo suficientemente grande puede amortizar esto en un tiempo razonable y a partir de ahí disfrutar de sus beneficios.
Pero esta solución no es solo aplicable a clientes, también lo es para proveedores. A veces los clientes te obligan a seguir un camino, en otras el camino es muy ancho o te dejan bastante libertad para elegir el framework de desarrollo, es en estas circunstancias donde la automatización del proceso de desarrollo a partir de modelos marca la diferencia para un proveedor. También puede darse el caso de que tengas uno o más clientes importantes y decidas invertir en frameworks y sistemas generadores de código que mejoren la productividad del proceso de desarrollo.