Alcenit Insights

El Dream Team para SOA

La asignacin de roles y el entrenamiento son claves para el xito en los nuevos paradigmas.
por Jaime Oviedo Silva, MSE

Hoy son cada vez ms las organizaciones que entienden cmo la adopcin de una arquitectura orientadas a servicios (SOA) puede contribuir directamente a mejoras operativas, ventajas competitivas y a un aumento de su capacidad para acomodar los cambios de su entorno. Sin embargo, tambien hay una creciente cantidad de fracasos, problemas y descontento por las organizaciones que deciden adoptar el paradigma. Este artculo se centra en un error comn en la adopcin de SOA, y que puede daar fuertemente sus posibilidades de xito: La subestimacin del esfuerzo requerido para adquirir las competencias tcnicas y conceptuales necesarias para aplicar SOA correctamente. Usualmente, las organizaciones asignan los roles SOA a personas que cumplen roles similares para otros tipos de iniciativas. Por ejemplo, es comn que un arquitecto de software pase a ser un arquitecto SOA, ya que para la construccin de una adecuada arquitectura de un sistema orientado a servicios, los conocimientos avanzados en ingeniera de software

esperables de un arquitecto de software resultan un prerequisito irrenunciable. Lo mismo sucede para el responsable de gobierno TI, que pasa a ser responsable de gobierno SOA: al ser el gobierno SOA una especializacin del gobierno TI, conocimientos de modelos como por ejemplo ITIL, resultan centrales y un excelente punto de partida. Lamentablemente, el esfuerzo de la organizacin para apoyar la transicin muchas veces se queda ah: en un cambio de nombre para el rol. Se le entrega a la persona asignada la responsabilidad de desarrollar los conocimientos necesarios para ser competente en el nuevo rol, y se asume que podr hacerlo de manera transparente y oportuna, subestimando fuertemente el esfuerzo, tiempo y conocimientos requeridos. A modo de ejemplo, un arquitecto de software, especialista en sistemas de arquitecturas multicapas Web o cliente servidor, y que slo ha construido sistemas en base a paradigmas como la orientacin a objetos o la programacin estructurada, va a requerir de varios meses (incluso aos) y de un alto esfuerzo para poder disear correctamente arquitecturas orientadas a servicios. Esto se debe a cambios en: El tipo y cantidad de tecnologas nuevas involucradas El tipo de abstraccin con el que se trabaja Los principios y fundamentos conceptuales que norman la construccin de aplicaciones.

Lamentablemente, el esfuerzo de la organizacin para apoyar la transicin muchas veces se queda ah: en un cambio de nombre para el rol.

Respecto al primer punto, se debe considerar que los estndares creados para la construccin de aplicaciones durante la primera y sobre todo durante la segunda generacin en SOA son muchos: si en la primera generacin de SOA, bastaba con saber WSDL, SOAP, XSD/XML y opcionalmente UDDI, en la segunda generacin aparecen un conjunto relevante de estndares WS-*, que hoy superan los veinte. Adems, en ambientes donde se requiere de interoperar con mltiples entidades externas, el conocer los perfiles WS-I es altamente recomendable.
Copyright 2013 Alcenit Corporation. All rights reserved.

www.alcenit.com

Alcenit Insights

2 se opt por una arquitectura tan compleja, cuando exista una forma ms sencilla y probablemente ms econmica de hacer las cosas. Si bien los problemas relacionados con una inadecuada transicin de roles que se acaban de describir se centraron en el rol del arquitecto SOA, existen problemas similares para cada uno de los roles SOA, que de no ser abordados oportunamente, comenzarn a perjudicar las posibilidades de xito de la iniciativa incluso en etapas tan tempranas como la de identificacin del portafolio de servicios, y podran tener daos colaterales en otras iniciativas, como por ejemplo la adopcin del paradigma BPM.

Si bien no es necesario que un arquitecto conozca el detalle cada uno de los estndares SOA de primera y segunda generacin, si debe conocer lo suficiente como para poder razonar a nivel arquitectnico en torno a ellos (por lo menos en torno a los ms usados, como WS-BPEL, WS-Policy, WS-Security, etc.). La carencia de estos conocimientos muy probablemente lleve a la implementacin redundante de mecanismos ya abordados por las especificaciones. Una segunda arista de este problema es que el arquitecto debe conocer las caractersticas serie de componentes de middleware que generalmente se asocian a las implementaciones de SOA, como por ejemplo los buses de servicios, motores de reglas, motores de orquestacin, gestores de polticas de servicios Web, registros de servicios, etc. Este conocimiento no slo es necesario para el adecuado uso de las piezas de middleware, sino tambin para proteger a la organizacin del constante bombardeo publicitario que los grandes productores de software han montado en torno a ellos, y que lleva a gran cantidad de organizaciones a comprar productos que no necesitan. Respecto al segundo punto, los cambios tambin son relevantes: El arquitecto debe tomar un conocimiento que le permita identificar servicios que tengan relevancia y trazabilidad a nivel de negocio, lo que implica un conocimiento e internalizacin mayor de los objetivos y guas centrales del negocio de la organizacin. Adems, las implementaciones SOA modernas generalmente buscan la

La internalizacin de los principios y conceptos asociados a SOA es un proceso que requiere maduracin
automatizacin de procesos de negocio, y no se limitan a soportar funcionalidades puntuales, requiriendo que el arquitecto entienda estos procesos y sepa concebir el sistema en funcin de orquestaciones y coreografas de servicios. Por ltimo, el tercer punto es el que probablemente lleve de manera ms subrepticia al fracaso de la iniciativa SOA en el logro de sus objetivos de mediano y largo plazo. La internalizacin de los principios y conceptos asociados a SOA es un proceso que requiere maduracin, y esta es clave para que los sistemas logren las caractersticas de calidad que se esperan de ellos. Los saltos dados por las organizaciones a SOA, sin una adecuada transicin de sus arquitectos, podran en el futuro derivar en sistemas que si bien usan tecnologa SOA y estan alineados con los objetivos del negocio, se hayan concebidos con base en los principios de otro paradigma (orientacin a objetos, a eventos, funcional, etc.). El desempeo y la usabilidad de estos sistemas probablemente ser peor a la de un sistema de la misma funcionalidad, pero construido con otra arquitectura, y dificilmente le dar a la organizacin los beneficios esperados de la adopcin de SOA. Esto inevitablemente levantar cuestionamientos acerca de por qu

Jaime Oviedo Silva, MSE Fellow Consultant de Alcenit, el Ing. Oviedo es Arquitecto Senior de Software y cuenta con ms de diez aos de experiencia en gestin de grandes proyectos de TI en Amrica Latina y USA. Actualmente es Gerente de TI de uno de los proyectos de desarrollo de software ms grandes de Amrica Latina en el Ministerio de Economa de Chile. Es Mster en Ingeniera de Software por la Carnegie Mellon University, certificado en CMMI y experto en BPM, SOA, concepcin de estrategias de TI, gobierno de TI, implementacin del modelo CMMI, el Proceso de Software de Equipos (TSP), gestin de software centrada en riesgos, seguridad de aplicaciones y, por supuesto, arquitectura de software. Alcenit Corporation se asegura que sus clientes obtengan el valor esperado de su inversin en tecnologa. Como Partner del Software Engineering Institute, nuestro mayor valor agregado es la gestin del cambio organizacional y el uso de buenas prcticas basadas en marcos internacionalmente reconocidos, como COBIT, CMMI e ITIL.

Copyright 2013 Alcenit Corporation. All rights reserved.

www.alcenit.com