Años de soluciones informáticas desligadas de la estrategia corporativa, los procesos de negocio o algún marco arquitectónico general han dejado su huella en el panorama corporativo. La arquitectura actual de TI es vista como una colección de aplicaciones1 que, dada la relativa poca importancia que le presta a los procesos de negocio, terminó creando silos de aplicaciones segregados dentro del mapa arquitectónico de la empresa. Este simple evento justificó la proliferación de soluciones EAI (Integración de Aplicaciones Empresariales, por sus siglas en inglés) que como indica Gian Trotta2 y Anne Thomas Manes3 del Burton Group, no han más que empeorado la realidad ya de por sí compleja de los departamentos de TI, sin contar los millones de dólares echados a esa hoguera y verdaderas historias de terror, como la de Hershey Food Corp3.

Estos silos que mencionaba se evidencian en las islas de datos y automatización que vemos hoy en día. En cuanto a las islas de datos cada aplicación que se instala trae consigo una definición propia de diversos objetos empresariales (como el concepto “precio” que para una aplicación puede ser el precio neto y para otra contemplar el impuesto), lo que por lo general implica una traducción de los datos en los mensajes enviados entre aplicaciones, en una clara contraposición a un modelo semántico de datos4 indispensable para el éxito de una SOA5. Las islas de automatización se hacen evidentes cuando un usuario tiene que saltar entre varias aplicaciones ya sea para duplicar parte de un proceso o para completarlo, lo que causa la fragmentación de los procesos de negocio.

Este relativo desorden es producto de una falta de governance (traducido como gobierno de ahora en adelante) en la gestión de TI.

SOA y el gobierno de TI

Si el gobierno de TI, definido este como el conjunto de procesos, políticas, responsabilidades, etc. de elementos de TI que administrados de alguna forma permiten alcanzar la estrategia planteada por la organización, es tan importante, ¿cómo lograrlo? En primera instancia diremos que la solución yace en la arquitectura pues esta es la que nos provee ese framework general de la infraestructura de TI y su uso dentro de la organización. Sin visibilidad el control simplemente no es posible y una de las cosas que facilita una arquitectura es esto. A este respecto la Arquitectura Empresarial ha surgido en los últimos tiempos como una opción para administrar dicho framework (entre otras cosas), sin embargo, al ser una práctica relativamente inmadura se queda corta en el manejo de los desafíos planteados para el gobierno de TI e incluso a veces sufre del “síndrome de torre de marfil” y no produce resultados prácticos. Esto no indica para nada que debamos dejarla de lado y más bien debe complementarse con técnicas, herramientas, etc. más probadas.

Como indicamos en artículos anteriores SOA es un estilo arquitectónico que trata con servicios a nivel empresarial. SOA nos provee un enfoque hacia la Arquitectura Empresarial al abstraer diversos elementos de TI en forma de servicios fuertemente ligados a procesos de negocio. La aplicación de SOA al gobierno de TI, el llamado gobierno de SOA, nos facilita ese control y visibilidad necesarios a la vez que promueve la agilidad del negocio, aunque como veremos más adelante, el gobierno de TI tiene un alcance más amplio que el gobierno de una SOA. Esa misma relación con los procesos de negocio hace que SOA también facilite el gobierno corporativo6, del cual el gobierno de TI es parte.

¿Cómo se define entonces el gobierno de SOA? Dado que estamos frente a un tema relativamente nuevo y en desarrollo no hay una definición universalmente aceptada del término. Gartner lo define como “asegurar y validar que los activos y artefactos dentro de la arquitectura están actuando como se espera y manteniendo un cierto nivel de calidad”7. Anne Thomas Manes lo define3 como “los procesos que una empresa pone en funcionamiento para asegurarse que las cosas son hechas correctamente, esto es, en concordancia con las mejores prácticas, principios arquitectónicos, regulaciones de la industria, leyes y otros factores determinantes”. Ian Charlesworth, analista de Ovum, nos da la siguiente definición8 “el gobierno de SOA implementa el marco de referencia de las políticas, procesos y rendición de cuentas requeridos para asegurar una implantación y una administración exitosa de una SOA, en apoyo a las necesidades principales y objetivos del negocio”.

Sin embargo, la mejor definición es la dada9 por Booby Woolf, arquitecto de IBM. Empieza definiendo el gobierno de TI como “la aplicación de gobierno a una organización de TI, sus personas, procesos e información para guiar la forma en la que esos activos apoyan las necesidades del negocio”.

Con esa base define el gobierno de SOA como “una especialización del gobierno de TI que pone las decisiones claves del gobierno de TI dentro del contexto del ciclo de vida de los componentes, servicios y procesos de negocio. El desktop support y el almacenamiento de datos son dos elementos del gobierno de TI que claramente no vemos directamente en una SOA, por poner un ejemplo de la diferencia de alcances.

Aunque vemos algunos elementos comunes en las definiciones anteriores lo cierto del caso es que el término ha sido adaptado a conveniencia por los vendedores de herramientas, la prensa y los analistas tecnológicos, lo que ha contribuido a la confusión existente.

Elementos necesarios para el gobierno de SOA

Roman Stanek señala10 tres elementos fundamentales en el gobierno de SOA: las políticas, los contratos, el ciclo de vida de desarrollo y los metadatos, los cuales resumiré a continuación.

El gobierno de algo no es posible sin un conjunto de Políticas y/o reglas que delimite el comportamiento esperado. Estas políticas se componen, en el caso de una solución SOA, de reglas configurables y condiciones que afectan los servicios durante el diseño y la ejecución de los mismos. Phillip Windley va más allá7 y además plantea la definición de políticas para la instalación de los servicios, como sería el caso de forzar la interoperación de servicios a ser instalados en producción por medio del estándar WS-I.

En cuanto a los Contratos Stanek señala que estos son importantes para la administración de la relación entre las partes involucradas en un servicio al proveer una declaración libre de ambigüedades sobre la forma en la que ambas partes van a interactuar, a través de, por ejemplo, Acuerdos de Nivel de Servicio. En relación al gobierno él los cataloga como mecanismos claves para la comunicación y el reforzamiento de políticas.

Con respecto al ciclo de vida él establece, contrario a otras propuestas que se indican más adelante, que la única forma de alcanzar la promesa de SOA es haciendo una administración de los servicios y demás artefactos de una SOA a través de todo el ciclo de vida, es decir, en forma integral. Una revelación interesante es que contrario a lo que uno podría creer en el gobierno de una SOA hay dos ciclos de vida distintos involucrados:

• El ciclo de vida de los servicios individuales (diseño, construcción, instalación), es decir, con un enfoque en los proveedores de servicio
• El ciclo de vida de la red de servicios (donde los servicios son accedidos y utilizados), es decir, enfocado en los consumidores

Sobre Herramientas existe la tendencia a dividir el gobierno de SOA (y con ello las herramientas utilizadas) en dos estadios del ciclo de vida de una solución SOA: el tiempo de diseño y el tiempo de ejecución. Uno de los defensores de esta tesis es David Linthicum, reconocido experto en el tema de SOA de ZapThink. Él nos dice que en el primer estadio11 veríamos elementos como un registro/ repositorio del diseño, administración, políticas, seguridad y pruebas de servicios; herramientas que ayuden en el diseño de los servicios; herramientas de implantación y por último herramientas para las pruebas de servicios. En el segundo aunque no hay estándares definidos sí hay patrones que están emergiendo y acá algunos elementos señalados son el descubrimiento y entrega de servicios, seguridad, manejo de errores y auditoría.

En una opinión contraria Gartner indica12 que esta separación tiene una intención meramente de mercadeo por medio de la cual los diferentes vendedores de soluciones tratan de diferenciarse de los competidores, causando una falsa impresión de la necesidad de la división e indican que esto definitivamente no obedece a requerimientos del mundo real dadas por el usuario. En ese mismo estudio Gartner concluye que no es posible la existencia de una única plataforma que contenga todos los elementos necesarios para el gobierno dado que las políticas y las reglas están detalladas en arquitecturas empresariales, herramientas de modelado de procesos, engines de reglas de negocio y hasta el código, fuera del alcance de estas plataformas. Es por esto que dividen las herramientas necesarias para el gobierno en tres tipos: registros y repositorios (para el almacenamiento de las políticas y otros elementos), tecnologías de validación y pruebas (además de probar los servicios se debe contemplar las pruebas de las políticas de seguridad y desempeño, entre otros) y tecnologías para la administración de políticas (soluciones que proveen la tecnología para crear, descubrir, referenciar y algunas veces forzar las políticas relacionadas a los activos SOA).

Conclusión

Como indica Anne Manes7 la mayoría de las organizaciones fallarán en sus implantaciones de SOA si no implementan la forma correcta de gobierno. Complementando esta idea podemos decir que la complejidad real de SOA no está en la tecnología, donde ya hay desarrollados muchos estándares de la industria, herramientas, etc. El desafío real está en el cambio que ésto implica tanto para la organización como para el departamento de TI. Para hacer este cambio efectivo es indispensable cambiar el comportamiento y es allí donde el gobierno tiene su verdadero impacto.

En una siguiente entrega estaremos revisando con más detalle el ciclo de vida de un servicio y delinearemos la extraña relación de amor y odio entre SOA y la Arquitectura Empresarial.

1 http://www.ibm.com/developerworks/architecture/library/ar-soastyle/
2 http://www.ebizq.net/topics/int_sbp/features/3463.html
3 http://www.intelligententerprise.com/showArticle.jhtml?articleID=164301126&pgno=1
4 http://www.ibm.com/developerworks/webservices/library/ar-soadecomp/index.html
5 http://www.crmbuyer.com/story/58979.html
6 http://en.wikipedia.org/wiki/Corporate_governance
7 http://akamai.infoworld.com/pdf/special_report/2006/04SRsoagov.pdf
8 http://www.soainstitute.org/articles/article/article/soa-governance.html
9 http://www.ibm.com/developerworks/library/ar-servgov/
10 http://www.looselycoupled.com/opinion/2006/stanek-gov0517.html
11 http://weblog.infoworld.com/realworldsoa/archives/2008/02/defining_soa_
go.html?source=rss
12 http://www.webservices.