Fugas y Ficciones

Jimena siempre fue una niña super tecnológica. A los dos años ya encendía ella sola el toca discos y con el mando a distancia pasaba las canciones hasta llegar a su favorita.

A los 4 comenzó a usar el ordenador, el de su padre. Estaba aprendiendo a escribir y le parecía totalmente mágico aquel aparecer de las letras negras sobre el fondo blanco.

- ¿Mamá, barco se escribe con la b grande o la pequeña?

- Con la grande, Jimena.

- ¿La de dos barrigas?

Cuando descubrió el Google Earth se quedó fascinada, podía pasarse horas y horas navegando, haciendo girar el globo terráqueo. Se paraba en la Acrópolis o en las Galápagos y preguntaba:

- Papá, ¿aquí que pone?

Resulta que Jimena lleva recorridos 39 mil quilómetros en su vida (sólo tiene 5 años) y su padre le ha prometido que muy pronto le regalará una bola del mundo de verdad, para ella sola. Jimena se muere de ganas.

¿Dónde está Jimena?

Un día Raquel, su profesora, le encargó que averiguara cosas de Kinshasa, que en el colegio era el día de la solidaridad y entre todos iban a fabricarles una escuela a los niños de allí.

Así que Jimena llegó a casa y le preguntó a papá que dónde estaba aquella cosa, Kinshasa.

- Yo creo que está en Kenia, Jimena, pero vamos a buscarlo.

No estaba en Kenia, sino en la República Democrática del Congo. ¡Papá!

Papá tenía mucho lío, así que dejó sola a Jimena y ella se fue por el Google Earth hasta Kinshasa, sin que nadie se diera cuenta. Allí recorrió el bulevar Lumumba, se paseó por La Gombe, llegó hasta la orilla del río Congo y cogió unas flores para su madre, amarillas y blancas.

También recogió unas cuantas palabras en Lingala, como en su día hiciera Moratinos:

- “Nkombo na ngai Jimena”, que como os podréis imaginar, significa “Me llamo Jimena”.

Volvió para la cena, sin que hubiera tiempo de asustarse, que Jimena siempre ha sido una niña muy buena.

Y menos mal que se llevó la cámara, que si no, nadie se lo hubiera creído. Se trajo unas fotos estupendas - yo le ayudé a ponerlas en su pared- pero lo raro es que no les dio mucha importancia, ¿por qué?.

Lo supe esa noche, al acostarla, después de rezar con ella:

- Papá, yo creo que en Kinshasa nos están engañando un poco.

- ¿Por qué lo dices, Jimena?

- Porque no son pobres

- ¿Cómo?

- Sí, que tienen rascacielos, yo los he visto.

To ko monana sina! (Nos vemos pronto)

Si alguien necesita más vocabulario en Lingala, puede empezar por aquí: Lingala para principiantes

Continuamos hoy con la descripción de las características de cada uno de los componentes de la arquitectura SOA.

Bus de servicios (ESB).

Un bus de servicios (Enterprise Service Bus – ESB) es un software catalogado dentro de la categoría de ‘middleware’ que proporciona herramientas de base para integrar sistemas y aplicaciones, construyendo arquitecturas mas complejas.

El bus de servicios utiliza un motor de mensajes (o servidor de mensajes) basados en XML y proporciona, además, una capa de abstracción entre los proveedores y consumidores de servicios.

Asimismo, lleva a cabo la integración de todos los sistemas de manera distribuida, eliminando las tradicionales interfaces punto a punto. De esta manera, cada aplicación establece una única comunicación física con el bus, en lugar de n conexiones con las n aplicaciones con las que necesita intercambiar datos o procesos.

Conectores

El bus de servicios suele acompañarse de un extenso catálogo de conectores o adaptadores que permiten resolver problemas de conectividad, incluyendo comunicaciones bidireccionales, gestión de transacciones y generación automática de estructuras de metadatos, que facilitan el intercambio de información.

Los conectores se usan para implementar las interfaces de integración entre el Bus de Servicios y los distintos sistemas de la empresa (bases de datos, aplicaciones empaquetadas o sistemas legacy) y para establecer colaboraciones online con partners de negocio (B2B) usando estándares de mercado como EDI, EDI/AS2, RosettaNet, UCCNet o HIPAA.

Registro de servicios (UDDI)

El registro de los servicios se lleva a cabo en un directorio mediante el protocolo UDDI (Universal Description, Discovery and Integration) que facilita su publicación y búsqueda.

El Registro incluye una descripción completa de los servicios y de los datos y parámetros necesarios para acceder a ellos, de modo que puedan ser fácilmente reutilizados.

En él se gestiona el ciclo de vida completo de los servicios incluyendo los procedimientos de aprobación, notificación de cambios y gestión de calidad.

Asimismo, sirve como punto central y único para la gestión de todos los elementos que conforman una arquitectura SOA.

Orquestación de servicios en procesos de negocio (BPM)

El componente BPM realiza, dentro de una arquitectura SOA, la comunicación entre los procesos de negocio y los procesos tecnológicos.

A continuación se detalla este procedimiento, que se estructura en dos fases:

Primera fase: Modelado de negocio

En esta fase se diseñan o modelan los procesos desde el punto de vista del negocio, lo que incluye las siguientes actividades:

1. Definición de todas las tareas del proceso, tanto automáticas como manuales. Estas tareas pueden llevar asociados distintos parámetros de negocio, tales como duración, coste, rol necesario para su ejecución, etc.
2. Definición del flujo lógico que encadena las tareas definidas.
3. Introducción de la información necesaria para la ejecución de las actividades del proceso.

Segunda fase: Ensamblado de los procesos de negocio con los servicios

En esta fase se realiza el ensamblado de cada tarea del proceso de negocio con el servicio responsable de su ejecución.

4. En primer lugar se identifican los servicios necesarios para la ejecución de las distintas tareas.
5. A continuación se buscan en el registro y se comprueba que son reutilizables. En caso contrario será necesario desarrollarlos.
6. Por último se “ensamblan” los servicios a las tareas, mediante la interfaz WSDL.

Seguimiento de la actividad de la empresa (BAM)

El componente BAM es una plataforma de gestión de eventos que agrega, correlaciona, estructura y presenta los datos relevantes del negocio en tiempo real.

Los productos BAM permiten definir y visualizar las métricas más apropiadas para el seguimiento de las operaciones de la empresa, así como los indicadores clave de rendimiento (Key Performance Indicators – KPIs).

A partir de estos parámetros, podemos evaluar el rendimiento y la eficacia de nuestros procesos de negocio, detectando posibles acciones de mejora.

Asimismo, las herramientas BAM proporcionan cuadros de mando avanzados y paneles interactivos para la monitorización y gestión de los procesos y actividades de negocio, que permiten la identificación de cuellos de botella y facilitan la toma de decisiones.

Bueno, pues hasta aquí hemos llegado. Espero que hayáis disfrutado del viajes y ¡Hasta la próxima!

Como ya hemos visto, la arquitectura SOA propone organizar los recursos tecnológicos como si fueran servicios, de manera que se pueda disponer de ellos sin atender a su lógica interna y facilitando su reutilización.

Hoy nos vamos a centrar en los tres principios fundamentales en los que se basa esta arquitectura:

1. Clara separación entre la lógica de negocio y los sistemas tecnológicos que le dan soporte.

2. Lógica de negocio modular, cada uno de los módulos constituye un “servicio” y dispone de procedimientos de acceso y uso claramente definidos.

3. Por último, cualquier aplicación o servicio, ‘debidamente cualificado/identificado’, puede utilizar otro servicio en tiempo real, mediante el procedimiento o interfaz apropiados.

Para entendermejor estos principios, veamos un ejemplo:

Consideremos un proceso de negocio simple, como la consulta de saldo en una cuenta corriente bancaria. Los pasos que vamos a considerar son la identificación del cliente, la consulta de saldo propiamente dicha y la presentación del resultado.

1. El primero de nuestros principios, la separación entre el negocio y los sistemas implica que el proceso debe ser independiente del canal por el que esté accediendo el cliente, de modo que los pasos lógicos sean los mismos si consulta por internet o si accede a un cajero automático. Fijaos que siguiendo este principio, la aparición de un nuevo canal de comunicación con los clientes no supone rehacer todo el trabajo.
2. Que la lógica de negocio sea modular significa que los distintos pasos sean independientes entre sí, o estén “desacoplados” en la jerga informática, de modo que la identificación del cliente esté claramente separada de la consulta del saldo. De nuevo si yo añado un paso no tengo que rehacer todo mi proceso. Por ejemplo, si quiero informar al cliente de que existe una comisión y confirmar que la acepta, sólo tengo que añadir un módulo a mi proceso, pero no tengo que modificar los ya existentes.
3. El último de nuestros principios, que los módulos o servicios sean accesibles, garantiza la reutilización de los mismos en múltiples procesos. Volviendo a nuestro ejemplo, la identificación del cliente es un servicio que necesitaremos muchas otras veces, y que, una vez construido, podremos reutilizar, con el consiguiente ahorro de tiempo y esfuerzo.

Y nada más por hoy, dejamos para el próximo día los distintos componentes necesarios para construir una arquitectura SOA.

Vamos con las cuestiones que teníamos pendientes.

La primera cuestión que teníamos era: ¿Es SOA un modelo realmente maduro como para invertir en él?

Para mí la respuesta es clara, el modelo SOA está realmente maduro, es decir, organizar los recursos tecnológicos como si fueran servicios es una buena idea. De hecho ya tenemos un número importante de empresas que han adoptado dicha arquitectura.

Sin embargo, el tema no está tan claro si hablamos de la tecnología necesaria para dar soporte al modelo SOA. Como veremos más adelante, la arquitectura SOA está formada por distintos elementos, y no todos ellos están igualmente soportados.

La segunda de nuestras cuestiones era: Si todavía no está maduro, ¿Cuándo lo estará, es decir, cuándo se podrá invertir en él minimizando los riesgos?

Aquí debemos puntualizar que SOA no es un sistema informático más, sino la organización de todos los sistemas de información (recordemos nuestra definición de arquitectura), es decir, un largo camino. Teniendo esto en cuenta podemos afirmar que ya podemos invertir en SOA minimizando los riesgos, siempre que vayamos andando dicho camino paso a paso:

Necesitamos estudiar bien nuestra situación, fijar nuestro punto de destino y trabajar luego para definir e implementar los distintos pasos.

Vamos con la tercera pregunta: ¿Será SOA un modelo obsoleto en 4-5 años?

Responder a esta cuestión es sencilla, sacamos nuestra bola de cristal y vemos el futuro. Claro que mejor que si SOA va a ser un modelo obsoleto mejor miramos los números de la lotería, ¿no?

Siendo serios, hoy no podemos afirmar tajantemente si SOA va a ser un modelo obsoleto o no. Probablemente, no estará tan de modo como ahora, que ya nos inventaremos algo nuevo. Sin embargo, es importante darse cuenta de una cosa: las antiguas promesas quizá defraudaron algo las expectativas, que eran muy altas, sobre todo con las punto.com, pero todas las “modas” tecnológicas nos han aportado algo útil, tanto los ERPs, como los CRMs, como los mega portales de internet, así que es bastante seguro que SOA permanezca entre nosotros aportándonos valor.

Por otra parte, me parece muy importante recordar que la tecnología no es un fin en si misma, sino un medio para mejorar las empresas, es decir, para obtener un número mayor de productos, incrementar la calidad de los mismos, reducir el tiempo necesario para ofrecer un nuevo producto al mercado o simplemente reducir los costes. De modo que si efectuamos una inversión en SOA y conseguimos algunos de esos beneficios y queremos saber si ha valido la pena, lo único que debemos hacer es llevar a cabo un análisis de costes y beneficios.

Para terminar por hoy recordemos nuestro último interrogante: ¿Está todo el mercado alineado en la misma dirección (IBM, Oracle, Microsoft, etc.)?

Pues parece que sí, sin que sirva de precedente, todos los grandes proveedores (Oracle, IBM, Microsoft, etc.) están alineados en la dirección de SOA.

Y ya está bien por hoy, que al final me está quedando un post un tanto largo.

¡Hasta el próximo día!

Una vez presentados los beneficios que pueden derivarse de adoptar un enfoque SOA nos surgen enseguida unas cuantas dudas, la primera y principal es la cuestión: ¿Ha venido SOA para quedarse?

Porque los más viejos del lugar, por ejemplo Alfonso, comentarista de nuestro anterior post, se sonreirán cuando les hablemos de una nueva forma de alinear la tecnología con el negocio y nos dirán que todo eso ya lo han visto antes. Con el mundo internet y las empresas punto.com, con las soluciones de CRM, con los ERPs y antes incluso con la arquitectura cliente-servidor. Pero resulta que al final ninguna de ellas ha resultado ser la panacea, ¿por qué con SOA las cosas van a ser diferentes?

Con la intención de centrar el debate voy a concretar algunas de las posibles inquietudes:

- ¿Es SOA un modelo realmente maduro como para invertir en él?

- Si todavía no está maduro, ¿Cuándo lo estará, es decir, cuándo se podrá invertir en él minimizando los riesgos?

- ¿Será un modelo obsoleto en 4 - 5 años y, al igual que con las punto.com, habrá que volver a invertir en TI cifras desorbitadas?

- ¿Está todo el mercado alineado en la misma dirección (IBM, Oracle, Microsoft, etc.)?

Para responder a estas inquietudes necesitamos introducir algunos de los conceptos de la arquitectura SOA

Conceptos de arquitectura SOA

Evidentemente, lo primero que necesitamos es definir qué sea una arquitectura tecnológica. Una buena definición puede ser la siguiente:

Llamamos arquitectura tecnológica de un sistema de información a la visión global de los distintos componentes del sistema, incluyendo las relaciones entre ellos.

Una vez definido el concepto de arquitectura podemos enunciar en qué consiste el paradigma SOA:

Las arquitecturas SOA proponen organizar todos los recursos tecnológicos como si fueran servicios, de manera que se pueda disponer de ellos sin atender a su lógica interna y que se facilite su reutilización.

Ahora estamos en condiciones de plantearnos las cuestiones anteriores, pero eso lo dejaremos para el próximo día. Hasta entonces os propongo un pequeño ejercicio, localizar tres ejemplos de arquitectura SOA en la vida real, el más típico es la fabricación de un coche, cuyo proceso principal consiste en el ensamblado de múltiples piezas previamente construidas, casi siempre por otro fabricante al que se le ha “subcontratado el trabajo”.

Hasta pronto.

Comenzamos con este post una serie dedicada a las tecnologías de la información, en concreto, hablaremos de las arquitecturas tecnológicas orientadas a servicios, conocidas por sus siglas en inglés: Service Oriented Architecture (SOA).

¿Por qué SOA ?

En el momento actual, el paradigma SOA (arquitectura orientada a servicios) se está abriendo camino rápidamente en el mundo de las tecnologías de la información. Esto se debe a los múltiples beneficios que representa frente a otros enfoques más tradicionales. De entre estos beneficios cabe destacar los siguientes:

1. Mayor visibilidad del negocio

- Dentro de la arquitectura SOA se incluyen componentes específicos para definir, generar y presentar, en tiempo real, la información relevante de negocio.

2. Mayor flexibilidad, agilidad y escalabilidad en los sistemas IT para responder y adaptarse a los cambios del negocio.

- Lógica de procesos no embebida en las aplicaciones, lo que facilita y simplifica su modificación.

- Servicios tecnológicos altamente reutilizables.

- Reducción significativa del tiempo necesario para modificar un servicio y/o implantar uno nuevo.

3. Infraestructura tecnológica más simple y racional, con menores costes y gestión más sencilla.

- Los nuevos sistemas se integran una sóla vez, de modo que los costes de integración son lineales y no exponenciales.

- Gestión centralizada de sistemas.

- Monitorización y control central de los sistemas.

Pronto seguiremos ...