Recientemente he comenzado a leer este libro y la verdad es que quisiera recomendarlo. Tanto para quienes estén por arrancar con un proyecto SOA como para quienes ya estén plenamente involucrados con este tipo de arquitectura, como es mi caso. La verdad es que me siento representado por las vivencias del autor y me parece importante compartir algunas conclusiones iniciales.

Aclaro que en esta primera parte solo me voy a referir a temas conceptuales y de gestión, no a detalles técnicos ni tecnologías específicas.

Que es SOA?

En este caso coincido totalmente cuando el autor dice que hay infinidad de definiciones y lo principal es quedarse con la idea importante de SOA.

SOA es un paradigma para el diseño de la arquitectura de nuestros sistemas que permite orquestar y mantener grandes sistemas distribuidos. Para entender SOA hay que entender las características de los grandes sistemas, donde tenemos que luchar con los viejos sistemas legados, la mayoría de los cuales inicialmente van a seguir operativos. No podemos hacer todo desde cero desde el comienzo y por esto vamos a tener que trabajar en conjunto las plataformas viejas y temas de compatibilidad.

Por qué SOA?

SOA permite que los sistemas de la organización sean flexibles mientras crecen,  interoperar y orquestarse de forma más sencilla.  Esto es referido tanto a los sistemas internos de la organización como con sistemas externos como ser clientes, proveedores, gobierno, etc.

Determinadas  organizaciones cuentan con sistemas grandes, complejos y heterogéneos, es decir,  utilizan una variedad de tecnologías diferentes  y con mucha longevidad. Eventualmente el costo de mantenimiento ya sea para incorporar nuevas funcionalidades como para interconectarse con otros sistemas se hace muy grande. Principalmente debido a la cantidad de “conexiones” que estos sistemas utilizan para interactuar con otros o para implementar diferentes funcionalidades y  donde cada uno puede usar tecnologías muy diferentes.

Conceptos

El autor presenta como los elementos más importantes:

• Los Servicios, son unidades que contienen funcionalidad de negocio, construidos sobre los principios y  pilares de este estilo de arquitectura y que pueden ser implementados con diferentes tecnologías y plataformas.

• Una infraestructura específica, llamada Enterprise Service Bus (ESB). El ESB está formado por la infraestructura que permite a los sistemas interoperar. Si bien parece complicado, en realidad es simplemente una abstracción, es una línea base, común para interconectar nuestros servicios y consumirlos.   Son los puntos de conexión a nuestros servicios, sus detalles tecnológicos, interfaces, seguridad, framework, etc. En otras palabras, soporta los conceptos de interoperabilidad y desacople. El desacople es un concepto que permite reducir las dependencias entre los sistemas para disminuir los efectos de las modificaciones y de los fallos. Para lograrlo, se debe pagar un precio  que consiste en aumentar la complejidad. Esto se traduce en más dificultad de desarrollo, mantenimiento y debug.

Figure 1 Enterprise Service Bus

• Políticas y procesos, que permiten crear y mantener estos servicios que pueden ser heterogéneos y que tienen diferentes “owners”.

No se debe perder de vista que cuando trabajamos con SOA,  tenemos una arquitectura que abarca servicios, infraestructura de redes, servidores, seguridad, políticas y procesos para su gestión, etc. Todo esto debe estar a la medida del desafío.

Hay que tener en cuenta que una arquitectura distribuida es compleja por sí misma y abarca muchas disciplinas de IT. Es por esto que considero importantísimo a la hora de aplicar SOA hacer una clara definición de los roles, equipos involucrados y políticas de colaboración.

No sólo vamos a tener equipos de desarrollo, es necesario tener un equipo de arquitectura encargado del ESB, un equipo que se ocupe de definir políticas y procesos,  un equipo de infraestructura (Administradores de servidores, redes y seguridad). También se debe definir los referentes tecnológicos (Conocedores de las plataformas, lenguajes de programación, etc.) y los sponsors (Gerentes, Líderes de proyecto, etc.), que son quienes nos brindan los recursos (tiempo y dinero).

Un concepto interesante que introduce el autor es el de owner, como el  equipo que  dueño del servicio está encargado de su desarrollo, que aplica las políticas y que utiliza los procesos definidos. Cada owner maneja diferentes presupuestos, tiempos, visiones e intereses que hay que considerar. Y es necesario que estos owners colaboren con otros para poder orquestar y ampliar las funcionalidades de sus sistemas. Esta colaboración no sólo abarca a los owners si no también al equipo de arquitectura y al personal de infraestructura. Por esto las políticas y los procesos son iguales o más importantes que el conocimiento de la tecnología.

Como dice el autor “…Una vez que se comprende como implementar SOA, no es difícil,  pero toma tiempo y coraje (OK, entonces es difícil). Cuesta mucho esfuerzo ayudar a la gente a que comprenda el paradigma (comenzando por uno mismo) y si no estás dispuesto a hacer el esfuerzo fallarás…”

Gobernance

El autor destaca los siguientes puntos para la administración SOA:

• Se necesita tener un equipo central para determinar los aspectos generales de SOA  de la organización. El objetivo debe ser lograr la descentralización de los sistemas grandes.

• Se debe contar con el personal adecuado y con experiencia en sistemas grandes, de manera que puedan tomar decisiones prácticas relacionadas con ellos. Los requerimientos de los equipos de negocio son quienes lo conducen y deben considerarse como sus proveedores.

• No eNo es necesario considerar desde el comienzo la administración de los servicios. Se puede pensar cómo administrarlos cuando se logren tener muchos en funcionamiento. Es decir, no es necesario crear o pensar en toda la infraestructura desde un inicio si no que deben crecer juntos.

• El  CEO y del CIO (Chief Information Officer) deben apoyar el concepto de SOA. Es decir, se debe contar con el apoyo de la dirección de la organización y de la gerencia de sistemas, para tomar las decisiones adecuadas y que provean el suficiente tiempo y dinero. Tener suficientes fondos a corto plazo no es lo importante. Se necesita dinero a largo plazo dado que cortar el presupuesto de SOA cuando se ha hecho la mitad de las tareas es una receta para el desastre.

Primeras conclusiones

SOA es un paradigma que tiene que ayudar a la gente de IT a ser flexibles, esto significa brindar soluciones a los requerimientos del negocio oportunamente. Mantener e integrar sistemas grandes y heterogéneos, y sistemas legados hasta que sean reemplazados. Para lograr esto la organización se debe alinear y también los roles, procesos, etc. ya que todos estos aspectos están relacionados.an>

SOA no es una herramienta o receta que se pueda aplicar para “hacer que todo funcione”. Es un paradigma que se debe desarrollar y aplicar en la organización en su conjunto.