archivo

Archivos diarios: noviembre 11, 2010

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.