Llevo metido en el desarrollo profesional de aplicaciones para grandes empresas más de 13 años, siempre en el mundo java, y en todo este tiempo creo que puedo sacar una conclusión: cada vez es más complejo desarrollar una aplicación o servicio de negocio.

¿Y por qué es así? Evidentemente no se debe a una única causa y supongo que cada uno de nosotros tendrá una idea diferente sobre las mismas. En realidad creo que hay muchas causas, tantas que no van a caber en este post, así que haré una segunda parte más adelante.

Ahí van unas cuantas causas:

El legacy.

Hay una ley no escrita en la informática:

Cuesta mucho que nazca un nuevo sistema o aplicación, pero cuesta mucho más que se muera

A poco que escarbemos en la superficie de una gran empresa, empezarán a aparecer todo tipo de tecnologías, productos, lenguajes, sistemas operativos, hardware… Todos ellos diferentes y a menudo incompatibles entre sí. Cada uno de ellos de una época histórica distinta y diseñado con una mentalidad diferente.

Cada uno de ellos guarda una parte del patrimonio de software de la empresa. Patrimonio que hay que seguir utilizando y explotando ya que su sustitución por una nueva solución tendría un coste prohibitivo (entre otras cosas porque es muy complejo construirlo).

Evidentemente cuantas más tecnologías tengamos que usar y cuanto más heterogéneas, mas complejo es trabajar con ellas (y más caro).

La interconexión de sistemas

En este momento ya no nos podemos conformar con un montón de aplicaciones silo aisladas, que no se comunican entre sí. Tenemos que buscar la colaboración entre todas ellas para proporcionar a la empresa nuevas funcionalidades de más alto valor añadido. En definitiva, tenemos que hacer que decenas de aplicaciones, cada una construida de manera diferente, se hablen entre sí.

¿Cómo conectamos todo esto e intentamos que todas las piezas heterogéneas trabajen entre sí? Este es uno de los mayores dolores se cabeza de un arquitecto T.I.

Afortunadamente, ahora tenemos mecanismos como los servicios web y los servicios REST que son estándar aunque no tienen por qué ser sencillos precisamente. Pero todavía persisten programas realizados con tecnología de hace 30 y más años que ni siquiera pueden invocar o ser invocados por servicios web. Se imponen entonces un encaje de bolillos difícil de hacer y sobre todo difícil de mantener.

El paso de aplicaciones silo a orientadas a Servicio

Indudablemente cuando sólo tenías que preocuparte de tu propia aplicación, y tú te lo guisabas y te lo comías, todo era más sencillo. No dependías de nadie aparte de tu equipo.

Únicamente necesitabas saber como construir las pantallas, codificar la lógica de negocio y acceder a bases de datos. Nada de acceso a sistemas externos, integración con otras aplicaciones, y por supuesto nada de multi dispositivo…

Para aplicar SOA es necesario un cambio de mentalidad en la concepción y diseño mismo de las aplicaciones, transformándolas en verdaderos servicios. Transmitir este cambio en una organización grande es muy complejo y costoso, puede suponer meses o incluso años.

Excesiva complejidad y mala calidad de los entornos de desarrollo

El entorno integrado de desarrollo estrella de IBM por poner un ejemplo, y ya hace 4 años de esto, pesaba 10Gb y necesitaba 4 Gb de RAM para funcionar ¿A donde vamos a parar?.

Y no solo eso, tanto él como el eclipse sobre el que se basa está plagado de bugs que hacen que la experiencia del desarrollo sea una pesadilla. Hemos llegado al punto de no creernos nada de lo que dice la documentación. No se puede dar nada por cierto hasta que lo pruebas por tú mismo. ¿Se puede ser productivo así?

Un cambio en un solo fichero puede ocasionar que no funcione nada

Una de las cosas que cuesta entender, sobre todo para las personas que vienen de entornos tradicionales como el Host es que ¿cómo es posible que con un sólo cambio en un fichero deje de funcionar toda la aplicación?.

En todas las guías de buenas prácticas, se repite una y otra vez aquello de DRY (Don’t repeat yourself), es decir, no tengas el código (ni los ficheros de propiedades) duplicados, tenlos en un sólo sitio y referenciarlos desde donde lo quieras usar.

Esto está muy bien para mejorar la mantenibilidad de la aplicación pero es un peligro para la estabilidad de la misma. En este artículo del blog tenéis una reflexión sobre esto haciendo una comparación (salvando las distancias) del código con los seres vivos: ¿por qué los seres vivos no se cuelgan?.

Iniciativas como OSGI tratan de paliar este problema haciendo posible construir una aplicación de forma modular de forma que se pueden arrancar, parar y actualizad el código de estos módulos sin afectar al resto de la aplicación. Sin embargo es posible que la adopción en un entorno productivo en una gran empresa puede representar muchos meses sino muchos años.

Creo que habría que revisar esta práctica del DRY, y ver aquellos sitios en los que es conveniente duplicar artefactos para mejorar la estabilidad y el desacoplamiemto aunque empeoremos la mantenibilidad.

Aumento del número de artefactos desplegables y mayor coordinación necesaria entre ellos

Cuanto más desacoplada esté una aplicación y mayor uso haga de la orientación a servicios más artefactos será necesario desplegar. En una aplicación silo por ejemplo, pude valer con un único desplegable (pantallas, lógica de negocio y lógica de acceso a datos).

En SOA sin embargo la cosa se complica, podemos tener la aplicación (o aplicaciones) de frontal en un desplegable, los servicios compuestos en otro desplegable para el ESB, la lógica de negocio en forma de servicios de bajo nivel en otro. A su vez estos servicios y pantallas dependerán de otros servicios que ni siquiera son de nuestra aplicación y viceversa, otras pantallas y servicios de otras aplicaciones dependerán de nuestros servicios.

Esta claro que es necesario un gran esfuerzo de coordinación para desplegar la solución. Y cuando más se complica una cosa, más posibilidad hay de errores.

Seguro que tu has pasado por estos problemas y por muchos otros ¿Que añadirías a la lista? ¿Alguna propuesta para evitar caer en estos problemas?