SOA agenda

Existen tecnologías dentro del ambiente SOA, y BPM, que tienen mucho en común, y por lo tanto muchas veces no se logra visualizar de forma clara sus diferencias, estamos hablando de los “coordinadores de tareas”, u “orquestadores” en general , herramientas que permiten organizar actividades en un flujo. Bajo este concepto podemos tomar:

• ETL (Extract Transform and Load)
• WorkFlow tradicional
• ESB (Enterprise Service Bus)
• BPM o BPMS (Business Process Management Suite)

Estas herramientas en general permiten a través de asistentes gráficos crear un proceso a partir de la organización de tareas, o subprocesos.

Extract, Transform and Load (ETL)

Nacida para traspasar información desde un repositorio de datos origen a uno destino, esta tecnología esta orientada a los procesos de datos, procesos basados en repositorios como Base de Datos y archivos.

ETL es una de las tecnología mas antiguas de integración, integración a nivel de datos, y tal como las Bases de Datos relacionales su utilidad se ha consolidado en el tiempo. Incluso en la actualidad dentro de la “Arquitectura Orientada a Servicios” (SOA) tiene su puesto en lo que son los “Servicios de Información”, porque a pesar de que su principal uso es en procesos Batch (procesos de actualización masivos), también se puede usar para el desarrollo de funcionalidades especificas pero que involucran la integración de entidades de información dispares (distintas).

Tal como su nombre lo indica permite Extraer (Extract), Transformar (Transform), y Cargar (Load), información desde, y hacia distintas fuentes de datos.

• Extraer: permite extraer la información de distintas fuentes de datos, principalmente bases de datos, y de la mayoría de los proveedores conocidos: Oracle, Sybase, DB2, MySQL, esto lo hace directamente desde las tablas, o usando “Stored Procedures” existentes. También permite extraer datos de archivos como XML, Excel, CSV, Texto, entre otros. Y han evolucionado hasta incluso obtener información de colas de mensajes, objetos Java, y Webservices, abarcando de cierta forma el terreno de los ESB.
• Transformar: a través del manejo de Metadata (datos en un formato estándar desacoplado de la fuente) permite unir la brecha existente debido a la diferencia de los tipos de datos, por ejemplo el proceso de información “Actualizar Datos de un Cliente” que involucra actualizar en distintos lugares, puede requerir que un dato que esta en entero deba pasarse a tipo float (real), o que los apellidos que están separados en una base de datos deban guardarse juntos en un solo campo en otra base de datos, o que un código de comercio que esta en cierto estándar (como EAN) se deba traducir a otro estándar (como ISBN) porque así se maneja en el otro repositorio.
• Cargar: permite guardar la información procesada en la misma diversidad de entidades que maneja dentro de la extracción: Bases de Datos, y archivos de distinto tipo.

En la actualidad las herramientas de ETL permiten componer estos procesos mediante asistentes gráficos, ambientes de desarrollo (IDE) que realizan una introspección de las fuentes de datos, obteniendo todos los objetos y sus campos de datos, permitiendo a través de “arrastrar y soltar” construir el flujo de proceso de datos. Además pueden incorporar reglas de negocio que permiten potenciar la funcionalidad del procesos.

Ejemplo: Proceso de Información Agrega Nuevo Producto

A este proceso ejemplo se le entrega un producto, el cual lo transforma en metadata, para poder por un lado obtener la marca asociada (desde una base Sybase), y por otro lado su código EAN (usando un Stored Procedure), si el código EAN no existe se busca en un archivo XML, luego finalmente toda la información se carga en la tablas de Productos (Base DB2), y además se registra en un archivo de Log (archivo txt). Mas que nada este ejemplo sirve para mostrar la relación que se puede establecer entre los distintos objetos ETL, pero la estructura definitiva de un diseño ETL dependerá de la herramienta que se utilice.

Los principales objetos que maneja un ETL son:

• Tablas de Bases de Datos
• Procedimiento Almacenados (Stored Procedures)
• Archivos XML
• Archivos de Texto, Archivos Excel.
• Transformaciones de Datos.

Otra característica que ofrecen actualmente los ETL, y que es muy importante para la Arquitectura SOA, es que los procesos ETL se pueden ejecutar como WebServices, para lo cual el motor de ETL publica el proceso en formato SOAP, pudiendo ser ejecutado desde cualquier plataforma (Java, .Net), y ser integrado en tecnologías como ESB (Enterprise Service BUS).

Luego, en el contexto de SOA podríamos indicar que ETL es la herramienta que permite diseñar y construir procesos de información (servicios de información) basados en actividades (automatizadas) a nivel de datos.

Algunas herramientas ETL del mercado son:

• IBM WebSphere DataStage.
• Oracle WareHouse Builder (OWB)
• Business Objects Data Integrator

WorkFlow Tradicional

Decimos WorkFlow “Tradicional”, porque la forma actual y bajo SOA de implementar un workflow es BPM, pero existen aun tecnologías WorkFlow tradicionales (no BPM), pero la mayoría se esta transformando en soluciones BPM.

La verdad es que actualmente muchas herramientas WorkFlow se acercan a lo que es BPM, viéndolo solo desde el punto de vista del flujo de los procesos de negocio, por eso aquí vamos a ver el concepto de WorkFlow Tradicional que se refiere al WorkFlow como era antes de evolucionar a BPM.

WorkFlow (Tradicional) es la tecnología que permite coordinar actividades humanas (realizadas por personas, Human Task), aquí se definen roles, actividades, reglas de negocio, en buenas cuentas un flujo de trabajo (WorkFlow), pero que a diferencia de BPM no contempla en forma natural los “servicios de negocio”, es decir no contempla las actividades de sistemas (System Task) bajo el estándar SOA.

Ejemplo: WorkFlow Actualizar Stock de Productos

Este WorkFlow ejemplo define un procesos donde un ejecutivo ingresa Stock de productos, el supervisor verifica el stock ingresado, y si es un producto nuevo además verifica la ficha del producto, si por alguna razón no se valida el registro vuelve al ejecutivo, quien debe corregir el ingreso. Este es un ejemplo genérico, la estructura del diseño del proceso dependerá de la herramienta utilizada.

Luego en una solución (WorkFlow tradicional) el participante (usuario) debe indicar el cumpliendo de la tarea (cambio de estado), para de esta forma continúe el flujo de trabajo, y cuando debe interactuar con algún sistema, debe levantar dicho sistema y realizar la actividad en él, por ejemplo ejecutar el sistema de stock para agregar un nuevo producto.

Esa es otra gran diferencia con BPM, en BPM se trata de proveer una sola interfaz para un participante del proceso, ocultando la interacción con los sistemas, mientras en un WorkFlow (tradicional) la persona debe interactuar con distintos ambientes o aplicaciones, dicho de otra forma: la persona debe manejar distintas aplicaciones (sistemas), y además registrar su avance en el WorkFlow.

Con WorkFlow (al igual que BPM) se le da seguimiento y control a los procesos de negocio, es decir, podemos saber el estado actual de cada proceso, en que lugar del flujo se encuentra. Otra similitud con BPM , o dicho de otra forma; otra característica que BPM heredo de los WorkFlow, es que a través del proceso generalmente fluye información (documentos, datos), lo que se llama la metadata, u objeto de negocio (BPM).

Enterprise Service Bus (ESB)

Esta tecnología permite integrar sistemas a nivel de servicios, cuando se habla de tecnología para implementar SOA en una empresa la primera herramienta que se debe incorporar es el “Service Bus”.

Esta herramienta permite componer procesos a partir de servicios SOA, los servicios SOA son componentes funcionales encapsulados fuertemente reutilizables, haciendo el “típico” símil: son piezas de lego que permiten construir un sistema uniendo bloques, y en este caso construir un proceso uniendo servicios SOA.

Proceso ESB Actualiza Producto en Sistemas

En este proceso ejemplo se entrega el producto a actualizar se comprueba el tipo de producto (Ecommerce o SAP), usando una clase Java (conecto EJB), luego se actualiza en el sistema Ecommerce usando un WebService, o se actualiza en el sistema SAP usando un conector provisto por el ESB.

Al igual como BPM absorbió las funcionalidades de WorkFlow (a través de BPEL4People), también absorbió las funcionalidades del ESB (a través de BPEL), de hecho las BPMS (BPM Suite) suelen traer como parte de sus componentes el ESB.

La diferencia con BPM es que el ESB no maneja las actividades humanas (Human Task) solo maneja actividades automatizadas (System Task).

La diferencia con ETL (tradicional) es que ETL esta orientado a componentes de datos, y ESB esta orientado a componentes de Servicios.

Los objetos que principalmente maneja ESB son:

• WebServices
• Conectores a Colas de Mensajes, y JMS
• Conectores a Aplicaciones de clase Mundial (PeopleSoft, SAP, JDEdwards)
• Conectores a J2EE (EJB) y .Net
• Transformaciones de Datos

Los ESB también manejan Metadata para la transformación de datos, y para lograr que los sistemas se entiendan a pesar de la diferencia en los tipos de datos que manejan.

Una característica importante es que los procesos se pueden ejecutar a través de WebServices, es decir un proceso de negocio ESB se puede publicar en protocolo SOAP, permitiendo que una gran variedad de plataformas puedan acceder a estos procesos.

Algunos ESB tienen conectores para Base de Datos, permitiendo integrar consultas a tablas (SQL Query), y procedimientos almacenados (Stored Procedures), con esto el ESB comienza abarcar terreno de los ETL, pero a decir verdad esta característica pone en riesgo la orientación a servicios (SOA), ya que los servicios deben corresponder a la capa de negocio, y no a la de datos.

Algunos ESB importantes:

• IBM WebSphere ESB
• BEA AquaLogic Service Bus
• Oracle Service Bus

Resumiendo ESB desde el punto de vista SOA es la herramienta que permite desarrollar procesos basado en servicios SOA.

BPM Suite.

BPM es la solución que permite construir procesos de negocio basado en coordinar tanto actividades interactivas (human task), como servicios (system task). BPM une lo mejor del mundo del WorkFlow Tradicional con el ESB.

En un mismo flujo se integran tareas realizadas por personas, con tareas automatizadas(sistemas), entregándole al participante de un proceso de negocio una sola interfaz, ocultando la interacción con los sistemas legados.

Ejemplo Proceso de Negocio Actualizar Stock de Productos

Basado en los ejemplos anteriores, en este proceso se integran 2 servicios al WorkFlow “Actualizar Stock”: una vez ingresado el stock, si el producto existe, entonces se obtiene los datos del producto usando un “WebService” (Obtiene Ficha Producto), y si el supervisor valida el ingreso al final se actualiza el producto usando otro “WebService” (Actualiza Producto), este ultimo servicio se supone es el proceso ESB “Actualiza Producto en Sistemas” publicado como WebService. Este es un ejemplo simplificado, en la realidad puede ser necesario incluir algunos servicios más.

La otras características de valor agregado de BPM son: que ofrece un grupo de herramientas para atender todo el ciclo de visa de un proceso de negocio, dentro de las cuales se destaca, el modelador (diseño procesos), el IDE (desarrollo de servicios), y el monitor (BAM), este ultimo que permite realizar un seguimiento y control mas acabado de los procesos de negocio.

Orquestadores en la Arquitectura de Referencia SOA

Desde el punto de vista de arquitectura marco SOA, los orquestadotes se organizan de la siguiente forma:

Uno de los aspectos relevantes en SOA es definir la Arquitectura de Referencia para la Empresa, esta definición permite tener un marco de referencia en donde ubicar los nuevos desarrollos.

La Arquitectura de Referencia SOA plasma los distintos componentes de una solución SOA, principalmente Procesos de Negocio y Servicios, además muestra como interactúan estos componentes con los usuarios de negocio, y con los sistemas existentes en la Empresa (sistemas legados).

 

Esta Arquitectura debe ser complementada con los componentes específicos de cada Empresa. Además cada proveedor de soluciones (IBM, Oracle, BEA, etc.) tiene su propia Arquitectura SOA de Referencia, que incorpora sus herramientas especificas, pero toda Arquitectura de Referencia por lo menos contempla lo siguiente:

 

 

 

• Usuarios de Negocio: son lo usuarios de las aplicaciones, pero en SOA son también los participantes de los procesos de negocio, estos pueden utilizar distintas tecnologías para acceder a la aplicación (o proceso de negocio): Desktop, Notebooks, PDAs, Celulares.

• Aplicación SOA y Portal: Las aplicaciones (aplicaciones SOA, o aplicaciones compuestas), están implementadas usando componentes reutilizables (Portlets, y Servicios), para lo cual se utiliza la tecnología de Portales. Una aplicación de este tipo incorpora todas las funcionalidades de un proceso bajo un ambiente común. La ventaja principal de las soluciones Portal; es que una aplicación desarrollada para un dispositivo se puede ajustar a otro con muy poco esfuerzo, es decir, una aplicación que funciona en un Desktop se puede adaptar para que se vea en una PDA, ajustando los portlets, y su distribución para cada dispositivo. Un portal de ejemplo puede ser este sitio web: “SOAagenda.com”,

• Servicios de Presentación (Portlets): son los componentes de presentación reutilizables, que en la practica corresponden a secciones reutilizables de las paginas Web. Ejemplos: un portlet de “Calendario”, un portlet para mostrar las “Publicaciones Recientes” de un blog. En el caso de los “Procesos de Negocio” (BPMS) generalmente ellos ofrecen un portlet para ejecutar los procesos, al que llamaremos portlet “Lista de Pendientes”.

• Procesos de Negocio: son la implementación BPM de los procesos, son procesos que incorporan tareas interactivas (interacción participante), con actividades automatizadas (servicios). Ejemplo: el proceso de “publicar un comentario en un Blog”, que dentro de sus tareas interactivas esta el “ingresar el comentario”, y “aprobar el comentario para su publicación”, y una actividad automatizada es el servicio de “ingresar el comentario en el sistema de Blog”.

• Servicios de Negocio: son componentes funcionales del negocio que se pueden reutilizar en los distintos procesos, y distintas aplicaciones, generalmente son servicios compuestos (por otros servicios). Ejemplo “ingresarComentarioBlog”.

• Servicios de Información: son lo servicios atómicos que pueden ser parte de servicios de mas alto nivel. Su principal características es que acceden directamente a los recursos, o sistemas legados, encapsulan las funcionalidades especificas de los sistemas existentes, dándole así una interfaz que permita integrarlos al estándar SOA.

• Sistemas Legados: son los sistemas existentes en la Empresa, que no están integrados (sistemas silo o isla). Son que soportan actualmente la operación del negocio, y que no están bajo el nuevo esquema de “orientación a servicios”.

Parte fundamental del del “SOA Governance” es organizar la administración de proyectos informaticos, y el primer paso es definir una metodología acorde con esta nueva Arquitectura.

La dirección de proyectos informáticos es una disciplina compleja, y una forma de manejar esta complejidad es adoptar un estructura de dirección de proyectos (PMS: Project Management Structure), es decir, adoptar una metodología.

Existen varios estándares:

• PMI PMBOK: (Project Managment Body Of Knowledge) Este es la metodología propuesta por la asociación Project Managment Institute (PMI), es un estándar ampliamente difundido en EEUU. www.pmi.org
• PRINCE2: (Projects IN Controlled Enviroments)Es la metodología propuesta por el Gobierno Ingles, y ampliamente difundida en Europa. www.ogc.gov.uk/methods_prince_2.asp
• RUP: (Rational Unified Process)
• XP: (eXtreme Programing) es la metodología mas difundida de la asociación Agile, que agrupa varias metodologías de respuesta rápida y altamente flexibles.
• CMMI: (Capability Maturity Model Integration). Es un método de mejoramiento a los procesos http://www.sei.cmu.edu/cmmi/cmmi.html
• P2M: (Project & Program Management for Enterprise Innovation) es el estándar Japonés. http://www.pmaj.or.jp/ENG/P2M_Download.htm
• V-Modell: es el modelo alemán promovido por el Gobierno, y el ministerio de defensa de ese país. www.v-modell.iabg.de/
• HERMES: adaptación del modelo alemán V-Modell promovido por el Gobierno Suizo. http://www.hermes.admin.ch/

Estas metodología intentan resolver la siguientes preguntas para un Proyecto:

· Quien? (roles dentro de un proyecto)

· Que? (procesos, actividades y entregables dentro de un proyecto)

· Cuando? (plan de un proyecto, oportunidad, reglas de decisión)

· Como? (como se asignan roles, como se realizan actividades, herramientas)

Las distintas metodología resuelven en mayor o menor grado dichas preguntas, por ejemplo se indica que CMMI resuelve principalmente el “Que”, mientras que otras metodologías como V-Modell resuelven en forma mas completa todas las preguntas, por eso algunos expertos consideran CMMI como solo un estándar mas que una metodología, en otras palabras, se puede alcanzar un nivel de madurez CMMI usando metodologías como RUP o V-Modell, de hecho la metodología PMI PMBOK tiene su propio modelo de madurez OPM3 (Organizacional Project Management Maturity Model).

Al momento de seleccionar una metodología hay que tener las siguiente consideraciones:

 

no hay una única tecnología mejor que todas, ya que algunas se adaptan mejor que otras a una Empresa u organización, y esto depende de la tolerancia al riesgo de la empresa, su nivel de madurez, su tamaño, etc. Todas las metodología manejan las grandes etapas del ciclo de vida de un proyecto, lo que cambia entre ellas es el nivel de disciplina.

Otro aspecto a tomar en cuenta es que toda metodología se debe adaptar a la Organización, e incluso se pueden combinar las metodologías porque generalmente no son excluyentes, logrando una metodología mas ajustada a la realidad de la Organización.

Hay que considerar que las metodologías no lo son todo por si mismas, hay que prepara el ambiente, y preparar a los profesionales, la empresa debe promover la cultura de “Project Managment”.

Las metodologías en boga son; PRINCE2 y PMBOK, y sus principales caracteristicas son:

 

Actualmente el tema de Project Management orienta más su investigación en las PMO (Project Management Office) y en las herramientas de apoyo para la administración de proyectos (Project Management Applications). Las PMO son centros de excelencia que apoyan y supervisan a los Jefes de Proyectos, y a la actividad de Administración de Proyectos, para el caso d SOA la PMO es el centro de excelencia de Arquitectura (SOA COE).

 

Implementar una Arquitectura Orientada a Servicios (SOA) en una compañía es un proceso complejo, debido a que SOA se basa en desarrollar componentes (servicios) reutilizables, y con estos servicios componer nuevas soluciones tecnológicas para el negocio, esto implica un cambio cultural en como se construyen los sistemas, y un cambio en el ámbito de la soluciones:

• En SOA los proyectos son transversales abarcan distintas áreas, y distintas aplicaciones, siguiendo el flujo transversal de los procesos de negocio de las compañías.
• En SOA las soluciones se comparten, y se construyen para que los próximos proyectos se vean beneficiados.

Los servicios deben ser diseñados e implementados de forma tal que puedan ser reutilizados en distintas áreas, en distintos procesos de negocio, y en distintas aplicaciones

Esto determina que en la Empresa comienzan a proliferar partes móviles e independientes de los sistemas (los servicios), que deben ser organizadas, y deben ser informados para asegurar su reutilización.

Además otro objetivo fundamental de SOA, es que los componentes sean flexibles, que se adapten fácilmente a los cambios. Los servicios deben ser flexibles, y los procesos de negocio implementados sobre SOA también, luego los cambios tecnológicos, o de negocio afectarán en menor medida a una Empresa, y específicamente afectarán en menor medida a los sistemas que utilizan dichos componentes. Esta flexibilidad permite salir en forma oportuna con nuevos productos, o soluciones (Time2Market).

La reutilización, y flexibilidad son los fundamentos de SOA, solo con ellos se logra bajar los costos de mantención, se logra aprovechar de mejor forma los recursos implementados, mejorar la productividad, y el time2market., es decir obtener el retorno de la inversión (ROI).

Lograr este tipo de componentes reutilizables, y flexibles, e implementar soluciones basadas en ellos, no es una tarea fácil, porque no basta solo con utilizar ciertas herramientas, si no además se apoya fuertemente en el cumplimiento de estándares, y buenas practicas, y es por eso que se denomina “Arquitectura” (Orientada a Servicios). Se pueden desarrollar componentes sobre tecnología SOA, pero aun así no asegurar su reutilización, o flexibilidad (ver articulo al respecto).

Este cambio cultural, la administración de partes y piezas, la disciplina para seguir estándares, y el lograr desarrollar soluciones efectivamente reutilizables y flexibles, necesitan de un esquema de administración especial: SOA Governance.

Algunas definiciones respecto de SOA Governance:

“Estructura de toma de decisiones, y responsabilidades, cuyo objetivo es promover determinado comportamiento en el área de Tecnologías de la Información” .

“SOA Governance define cambios en la administración del área tecnológica (TI) para asegurar que los conceptos y principios de SOA, y su arquitectura distribuida sean manejados apropiadamente, y que sea capaz de lograr los objetivos de negocio de los servicios” 

“SOA Governance ya no es una opción, es un imperativo, sin esta administración (governance) el retorno de la inversión es mucho menor, y todo proyecto SOA estará en riesgo” .

“En el 2006, la carencia de mecanismos de Governance en los proyectos medianos de SOA (proyectos de menos de 50 Servicios) han sido la razón mas común de falla de los proyectos”.

“Lograr crecer en SOA con la disciplina necesaria para asegurar la reutilización de los servicios, y que se evite la duplicación de servicios, esto solo se puede lograr a través de procesos de Governance cuidadosamente diseñados, y fuertemente impuestos”.

Bajo el enfoque SOA, los costos de implementación comienzan a bajar a medida que se van reutilizando los servicios. Por eso es la importancia de asegurar la reutilización y flexibilidad de los servicios, porque es lo que finalmente justifica la inversión en SOA.

SOA Governance debe definir:

• Que Hacer: El plan global de proyecto SOA de la Empresa, define el “SOA Roadmap” (Plan de Ruta SOA).
• Quien lo Hace: La estructura organizacional (los grupos de trabajo), define la “SOA Office”.
• Como Hacerlo: Los procesos (procedimientos) de administración, las normas.
• Como Medirlo: Las métricas para medir el éxito