Muchos recordarán el famoso juego Pitfall, donde un explorador intrépido (conocido como Pitfall Harry) sorteaba toda clase de peligros al recorrer una jungla guindado de una triana en búsqueda de tesoros escondidos. Cocodrilos, insectos, escorpiones, troncos, agujeros. Y todo eso con el tiempo justo (20 minutos).

Tras leer esta descripción, muchos suspiramos porque nos sentimos identificados: cualquier parecido con la experiencia de proyectos en los que hemos participado es pura realidad.

Aclaro (porque hoy día estamos vueltos locos con el tema de licencias) que no son artículos de mi autoría, los traduzco para propagar el conocimiento, para propiciar conversaciones y poner simplemente un grano de arena. Adjunto también los respectivos enlaces de los artículos originales. Recuerdo además que este blog no tiene fines comerciales por tanto no estamos aprovechándonos para ganar dinero a cuesta de otros

Hecho este sano paréntesis, empecemos con el primer pitfall o trampa.

El primer pitfall es propuesto en el artículo Top 10 SOA Pitfalls: #10 – Not Invented Here syndrome.

Pitfall SOA – El Síndrome “No se inventó aquí” o “No lo hicimos nosotros”.

El Síndrome de “No se inventó aquí” o Not Invented Here (NIH)  se presenta en muchas otras áreas o proyectos del mundo IT. Es como una especie de recelo a lo externo o ajeno.

Uno de los principios de SOA es la reutilización de servicios existentes. Si el departamento A desarrolló un servicio Obtener_Datos_Empleado, no tiene sentido que el departamento B desarrolle un servicio Obtener_Edad_Empleado, si en el primero se retorna esta información.

Sin embargo, el departamento B pueda que igual desarrolle su servicio propio por los siguientes motivos:

1- No tienen conocimiento de la existencia del otro servicio web. Es decir, no hay un registro de servicios adecuado.

2- La forma en que diseñaron su aplicación no permite pensar en reutilización.

3- Saben que existen el otro servicio pero decidieron no usarlo. Quizás porque no saben exactamente qué hace este servicio o no confían en otro departamento. Prefieren tener total control sobre la implementación o mantenimiento. En este caso, es evidente el síndrome del NIH y es necesario definir la titularidad de los servicios, quienes son los responsables, y permitir a cada departamento sentir que tienen cierto control.

En otro escenario, es posible que se implementase su propio ESB (Enterprise Service Bus), complicando un poco las cosas. Esto ocurre generalmente por:

1. A inicios del 2000, las empresas con integración a través de mensajes descubrieron la necesidad de servicios genéricos reutilizables (traducción, enrutamiento, transporte, etc). Esto conlleva al desarrollo de un montón de frameworks de mensajería caseros o de particulares, usualmente sobre sistemas de mensajería como MQ Series. Mientras estos frameworks cumplieron su función en ese entonces, su esencia ha propiciado que termine entrelazados con un montón de aplicaciones de la empresa, obstaculizando la introducción de un ESB estándar en la industria.

2. Y aún hoy, se están desarrollando servicios con parecido a un ESB. Muchos arquitectos tienen la sensación de que ESB ha sido impulsada por los vendedores y por tanto menosprecian al ESB, como si fueran sistemas inútiles. Pueda que esa sensación de presión tenga su parte cierta, pero escribir tus propios servicios de enrutamiento, transporte y traducción no parece ser una respuesta muy apropiada, porque de hecho, estás desarrollando igual un ESB, el tuyo!

En ambos casos, terminar esa situación requiere un esfuerzo importante. Estos sistemas propietarios son el centro de tus sistemas, de modo que salir de ellos va tomar tiempo. Por ejemplo, si decidieras comprar un COTS ESB, necesitarías un escenario de migración donde puedas migrar un servicio a la vez, de usar el viejo sistema a usar el nuevo ESB. Necesitarías un puente entre el viejo y el nuevo sistema para la transición. De hecho, no hemos visto funcionar ese escenario ya que el viejo sistema sigue enlazado en alguna esquina de la organización.

La moraleja aqui sería: antes de empezar a escribir tus propios servicios y tu propio ESB, mira lo que hay disponible y ya desarrollado. Tu servicio “temporal” probablemente va existir por mucho más tiempo.

Ese es nuestro primer pitfall en SOA por hoy. Si han estado en esta situación, nos encantaría conocer sus recomendaciones. Si consideran que esto no es una situación de temer, con mucho más interés aún te leeremos

¡¡Hasta el siguiente cocodrilo!!

Mucho se habla sobre el rol del arquitecto empresarial o de soluciones dentro del mundo SOA. ¿Y dónde queda el analista de negocio? SOA exige más de este rol, dándole un protagonismo importante gracias a su conocimiento sobre los procesos de negocio y que agregaría mucho valor dentro de proyectos de esta naturaleza. Demanda que el analista de negocio entienda más sobre la finalidad de los servicios y la tecnología subyacente, para su propio beneficio.

Es todo un reto, que abre nuevas oportunidades dentro de las competencias de este rol. Así como los arquitectos de solución típicos han “evolucionado” hacia una visión más empresarial, SOA necesita gente del negocio que entienda de términos como servicios, BPM, BPEL sin que le tiemblen las manos.

¿Pero hasta qué punto? El rol del analista de negocio tiene ciertos puntos en común con el arquitecto empresarial y suelen trabajar muy cercanamente. Los gerentes y ejecutivos están más familiarizados con el rol del analista de negocios que con el rol de arquitecto empresarial. Pero el analista de negocio hoy día carece de las habilidades técnicas para diseñar la arquitectura de una organización y por enfocarse en las métricas de negocio no tiene la visibilidad de cómo IT participa e impacta en el alcance de esas métricas. Por tanto, es necesario una visión a largo plazo que defina la estrategia corporativa que satisfaga esas necesidades y metas. Y ahí entra el arquitecto empresarial.

El analista de negocio al encontrarse dentro de un proyecto SOA, debe pensar en función de servicios, la especificación de sus respectivos contratos y tener claros cuáles son los principios SOA, sin dejar de lado sus funciones y responsabilidades clásicas.

Para cerrar, invito a analistas de negocio y arquitectos empresariales a que nos den su opinión sobre su rol dentro de las iniciativas SOA en las que han trabajado. ¿Tuvieron que cambiar su forma de trabajar? ¿Cómo sienten que impacta esto al equipo y a su rol?

Les dejo algunos de los artículos consultados para entender los nuevos retos para los analistas de negocio (en inglés):

The New Business Analist talks SOA (inglés)

Página web (especie de Comunidad) dedicada enteramente a Analistas de Negocio dentro de SOA  http://www.soabusinessanalyst.com/

The Business Analyst vs. the Enterprise Architect

Who should lead SOA? Enterprise architects or business analysts?

Les recomiendo leer el artículo de Joe McKendrick [inglés SOA, Roman, Greek, or Modern: you don't 'do' architecture http://bit.ly/4oUu0e] y sobre todo que reflexionen si SOA es algo que se compra con un producto ¿por qué todavía no se ha visto el ROI? o si es algo que se hace, ¿por qué no lo compilamos, ejecutamos y ya está? Algo falta. Este tema tiene mucha tela que cortar, el primer paso es cuestionarnos lo obvio.

Gartner nos plantea SOA como “una relación de servicios y consumidores de servicios, ambos suficientemente amplios para representar una función de negocios completa”.

Microsoft por su lado, habla de “una filosofía de diseño que permite un mejor alineamiento de las Tecnologías de Información (TI) con las necesidades de negocio, permitiendo responder de forma más rápida y adaptarse adecuadamente a las presiones del mercado”.

Servicios y Negocio.

IBM complementa “servicios independientes con interfaces invocables bien definidas, que pueden ser llamadas en secuencias definidas para formar procesos de negocios”.

Ahora además hablamos de interfaces y procesos de negocio.

Si vemos en la Wikipedia: “concepto de arquitectura de software que define la utilización de servicios para dar soporte a los requisitos del negocio.”

Arquitectura de Software.

Según Thomas Erl, es un término que ha sido usado para muchas cosas. Pueden ver más en What is SOA, además de otros contenidos excelentes.

Un artículo sobre SOA en el mundo real: Real World SOA (2006) [pdf, inglés].

En la Red en la que colaboro, DBAccess, el grupo de Arquitectos especialistas en SOA, lo describimos de la siguiente manera:

Estilo de diseño de Arquitectura de Solución, basado en la definición y construcción de servicios reutilizables que sustentan funciones del Negocio. Los servicios encapsulan el acceso a la información y la lógica de Negocio permitiendo que las aplicaciones se integren bajo una visión organizacional e independiente de las tecnologías utilizadas. El esquema de diseño e integración está enmarcado por una serie de políticas que gobiernan su uso y evolución en el tiempo (DBAccess).

Negocio, Procesos, Servicios, Interfaces, Arquitectura.

Reusabilidad, encapsulamiento, integración, independencia, gobernabilidad, evolución.

¿Qué es SOA?

Durante el mismo, fue elaborado y publicado el Manifiesto SOA (inglés). El artículo de Anne Thomas Manes “SOA is Dead: Long Live Services” (Enero 2009) movió varios cimientos en la forma en cómo se estaba percibiendo y aplicando SOA y el resultado es este Manifiesto.

Las prioridades que debe tener SOA en la organización:
* Valor de negocio por encima de estrategia técnica.
* Metas estratégicas por encima de beneficios específicos a proyectos.
* Interoperabilidad intrínseca por encima de integración personalizada.
* Servicios compartidos sobre implementaciones especificas a ciertos propósitos.
* Flexibilidad por encima de optimización.
* Refinamiento evolutivo por encima de la perfección inicial.

Se especificaron los principios de SOA, más que como unos principios de diseño, representan una guía para entender el valor principal de la orientación a servicios.

En cuanto a los principios, algunos que me gustaría resaltar:
* Respetar la estructura de poder y social de la organización
* El alcance de adopción SOA puede variar. Mantener esfuerzos manejables y dentro de límites o fronteras significativos o representativos.
* SOA puede realizarse a través de una numerosa variedad de tecnologías y estándares.
* Identificar servicios con la colaboración de los interesados (stakeholders) en el negocio y la tecnología.
* Reducir las dependencias implícitas y publicar todas las dependencias externas para incrementar la robustez y reducir el impacto del cambio.

El resto de los principios:
* Reconocer que SOA requiere cambios en muchos niveles.
* Los productos y estándares no van a darte SOA o implementar el paradigma orientado a servicios por ti.
* Establecer un conjunto uniforme de estándares empresariales y políticas basadas en la Industria, y estándares de la comunidad.
* Demandar uniformidad hacia el exterior y permitir la diversidad interiormente en la organización.
* Maximizar el uso de servicios al considerar el alcance actual y futuro de utilización.
* Verificar que los servicios satisfagan los requerimientos y metas del negocio.
* Evolucionar los servicios y su organización en respuesta al uso real.
* Separar los diferentes aspectos de un sistema que cambian a diferentes medidas.
* En cada nivel de abstracción, organizar cada servicio alrededor de una unidad o funcionalidad manejable y cohesiva.

En la elaboración del manifiesto participaron expertos como Thomas Erl, Joe McKendrick, David Chappell, y muchos otros cuyo trabajo y planteamientos son bastante reconocidos en el área.

La fuente original en inglés es Manifesto SOA. Aquí un artículo sobre el mismo que incluye el video de la presentación (en Inglés).

Síguenos en Twitter @soavignon y nuestro blog.

Estamos conformándonos en los medios sociales !Tendrás pronto más noticias de nosotros!