Noticias ASPA
Es habitual que por parte del departamento de Sistemas de una compañía se generen muchas discusiones sobre la manera «correcta» de implementar una arquitectura orientada a servicios (Service Oriented Architecture ó SOA), pero la realidad nos muestra que la mejor manera de adoptar SOA es convencer a «la parte empresarial» de nuestra compañía de las ventajas de esta arquitectura para el negocio. Debemos ser realistas y aceptar que las Tecnologías de la información son sólo una herramienta o un facilitador para que el negocio alcance sus objetivos.
De hecho, ya que las TI son la herramienta para gestionar la información de la empresa, siempre acaban reflejando la situación de la misma. Es decir, la información de la empresa estará mejor ó peor en función de la forma de gestionar el negocio, por tanto, hay una influencia directa del negocio en las TI.
Y esto significa que desde el lado del departamento de Sistemas de Información es posible encontrar una buena arquitectura y lanzarse a utilizarla, sin embargo, si nos ponemos a resolver los problemas de TI sin resolver primero los problemas del negocio, es probable
que fracasemos.
Todos estamos familiarizados con los típicos “problemas imposibles de TI” que todo el mundo se esfuerza en resolver desde el lado de sistemas: el propio departamento, los proveedores de soluciones, los proveedores de servicios de implantación… Pero ¿Alguna vez nos paramos a pensar porque nos encontramos con estos problemas? Si alguna vez lo hacemos tal vez nos demos cuenta de que el problema “irresoluble” que tenemos en TI, es en realidad un reflejo de un problema del negocio. Si este es el caso, no importa que arquitectura de TI acabemos eligiendo. La solución al problema está en rediseñar primero los procesos de negocio.
Esto es fácilmente entendible si acudimos al recurso que utilizan algunos autores de comparar la arquitectura de sistemas de una empresa con la planificación urbana de una ciudad. Por ejemplo, si en una ciudad se ha decidido construir el aeropuerto en una ubicación errónea, cuando se realice la planificación del tráfico de mercancías y personas, la ubicación de los edificios y complejos de oficinas, y el trazado de vías férreas y autopistas, no importa las vueltas que le demos al diseño, la solución nunca será optima, porque la ubicación del aeropuerto no lo es. Si, utilizando esta analogía, comparamos el tráfico de personas y edificios con el tráfico de información del sistema, los edificios con las aplicaciones, y las carreteras y vías férreas con la infraestructura, entenderemos porqué solo cambiando la ubicación del aeropuerto (los procesos de negocio) se puede optimizar los sistemas.
El problema al que se enfrentan hoy las empresas respecto a SOA, es que SOA es una arquitectura “técnica” impulsada por el departamento de sistemas, pero a menudo sin consultar al lado del negocio de la empresa. Lo irónico del asunto es que realmente la arquitectura SOA puede ayudar a las empresas a rediseñar los procesos de negocios evitando los “problemas irresolubles” de sistemas, que son los que a su vez impiden tener éxito al implantar una arquitectura SOA.
Esta paradoja nos indica que los proyectos de implantación de SOA deben estar íntimamente ligados a las necesidades del negocio y que junto al equipo de sistemas, debe contarse con un equipo de la parte de negocio que apoye el cambio y que aproveche la implantación de la nueva arquitectura para rediseñar procesos allí donde fuera necesario. Solo así se garantiza el éxito de un proyecto SOA.
