Sobre las malas costumbres y el espagueti

por

Habitualmente cuando me encuentro explicando lo que es SOA suele ayudarme bastante repasar un poco de historia del desarrollo del software, y observar las malas prácticas que se cometen a menudo en los últimos años.

A lo largo de las ultimas 3 décadas, la importancia de los sistemas de información en las organizaciones ha vivido una explosión absolutamente demoledora. Hemos pasado de una informática centralizada, batch y desconectada, a unas organizaciones completamente basadas en las TIC, con sistemas de información distribuidos y masivamente interconectados.

Toda esta transformación no ha llegado sola. En paralelo, catalizando este cambio, hemos visto como evolucionaba el paradigma de desarrollo de software.

La programación estructurada, que permitía un cierto nivel de modularidad, era la norma cuando los requisitos de integración entre los sistemas se resolvían mediante complejos procesos batch que duraban noches y fines de semana.

La arquitectura cliente – servidor comenzó a separar la presentación de los datos, pero la frontera del negocio no estaba clara. Comenzaba a tomar importancia la cuestión de mover información de forma ágil, pero aún la mayoría de los requisitos de integración recaían en el servidor y su potencia de procesamiento masivo de datos en procesos batch.

La abstraccion es la caracteristica mas importante que comparten SOA y OO

La orientación a objetos introdujo un cambio radical en la forma de modelar el software y diseñar los sistemas de información. La capacidad de abstracción, siempre necesaria para un desarrollo de software de calidad, se hizo imprescindible para entender el nuevo modelo y sacarle todo su potencial. La reutilización de piezas de software probadas de forma industrial, perfectamente encapsuladas y autocontenidas, parecía estar al alcance de la mano.

La explosión de internet y la arquitectura de 3 capas en las aplicaciones web supusieron el despegue definitivo de la informática distribuida. Haciendo uso de la orientación a objetos como base para el desarrollo de aplicaciones usando piezas pre-construidas para resolver temas de usabilidad y acceso a datos, las aplicaciones se desarrollaban más rápido y resultaba fácil intercambiar información entre distintos sistemas.

A medida que las necesidades de compartir información fueron aumentando surgieron distintas aproximaciones, por ejemplo RPC para ejecutar procesos remotos entre aplicaciones, o los propios servicios web, introduciendo el importante concepto de contrato (el WSDL) entre proveedor y consumidor del servicio web.

 

Pero no perdamos de vista que todos estos cambios fueron llegando muy rápidamente, sin dar tiempo a las organizaciones a recuperar las inversiones realizadas en la tecnología anterior. Es lógico que se intentara proteger aquellas inversiones tratando de hacer convivir sistemas de información de generaciones muy distantes, y por tanto de tecnologías muy dispares y antiguas, de difícil y costoso mantenimiento.

Pero ¿de qué manera se han ido resolviendo las necesidades de integración de estos sistemas de información a lo largo de los años con la tecnología disponible en cada momento, sin tirar a la basura los sistemas existentes, y tratando de ahorrar costes en cada proyecto?:

– procesos batch
– replicas de tablas
– acceso remoto a bbdd de otro sistema mediante dblink o similar
– apertura de aplicaciones embebidas
– intercambio de ficheros de manera automática
– servicios web propietarios, habitualmente de consulta
– etc

Todos estos métodos de integración presentan grandes inconvenientes cuando hacemos zoom y miramos el mapa de sistemas resultante en la organización, un mapa que visualmente recuerda mucho a un plato de espagueti, que es como se conoce este tipo de escenarios:

  • fuerte acoplamiento, es decir, dependencia entre los sistemas, sus bases de datos, sus tecnologías, sus diseños
  • requerimientos redundantes, inherentes al negocio, que se repiten en distintas áreas funcionales
  • lógica redundante, que reinventa la rueda tratando de resolver los requerimientos similares
  • sobre coste de proyectos, debido a la descoordinación desde un punto de vista organizacional, y al fuerte acoplamiento y su efecto dominó cuando se analizan los impactos de pequeños cambios
  • dependencia de la tecnología, debido al fuerte acoplamiento en la forma de integrar los sistemas
  • saturación de la red, ya que el elevado numero de integraciones punto a punto implica trafico redundante y descargas masivas de información que en realidad son innecesarias

Y entonces, llegó SOA.

La Orientacion a Servicios llego para quedarse

En las próximas entradas iremos profundizando en el impacto de una estrategia SOA en este escenario, y veremos el valor y la importancia que trae al sector de las TIC. Y veremos el importante cambio de enfoque que conlleva y la cantidad de buenas practicas que recupera para el desarrollo de software de calidad.

Te puede interesar

0 comentarios

Trackbacks/Pingbacks

  1. Sobre integraciones, incrustaciones e interoperabilidad - […] de entrar en más detalle sobre lo que SOA aporta al escenario descrito en nuestra anterior entrada, vamos a…

Enviar un comentario

Tu dirección de correo electrónico no será publicada. Los campos obligatorios están marcados con *

Sigueme en las redes

Share This