Para ejemplificar esto, supóngase que se tiene la version 1.0 de un servicio (getTotalAmount) replicado en 3 ambientes diferentes, y uno de ellos cambia a version 2.0 (se le quita un parametro) , debido a que se ha añadido un nuevo consumidor (application composite), generando caídas en los sistemas “afectados”.

Otra situación más sutil, es que el servicio no cambie el contrato, pero que envíe, usando el ejemplo anterior, menos puntos decimales, haciendo que un sistema financiero consumidor quede “descuadrado”, siendo este “error” extremadamente dificil de detectar.

Victor Toledo

La definición generalmente aceptada de SOA es una arquitectura desacoplada de componentes de software que proveen funciones específicas (proveedor) y que pueden ser invocadas por otros componentes (consumidor) independientemente de la plataforma en que se encuentren ambos.

La ventaja inherente a una arquitectura de este tipo es lograr una mayor flexibilidad al construir nuevas aplicaciones o modificar aplicaciones ya existentes, con lo cual el negocio se ve beneficiado en términos de tiempo y costo, así como lograr una mayor eficiencia y plataforma para habilitar el cambio y la innovación dentro de la empresa.

También existen ventajas en términos de ahorro en TCO (Total Cost of Ownership) de los componentes de software y de las aplicaciones construidas utilizando estos componentes. El ahorro viene en cuanto a la independencia de plataforma, reuso de aplicaciones ya instaladas (legacy applications), utilización de protocolos asi como metodologías estándares para especificar y diseñar aplicaciones.

El ideal de la arquitectura orientada a servicios es poder construir aplicaciones compuestas (Composite Applications) que reutilicen funcionalidades comunes expuestas como servicios; permitiendo de esta forma encapsular procesos de negocios que usualmente involucran utilizar varias herramientas de software sin una interfaz común. Asimismo, se busca flexibilidad al momento de modificar las reglas de negocio, en el sentido de solamente cambiar la aplicación compuesta para adaptarla al nuevo proceso de negocio, sin tener que modificar las funciones básicas expuestas como Servicios.

Una analogía de este idea es la forma en que los fabricantes de autos reutilizan partes de los autos como chasis, puertas, asientos para crear diferentes diseños y modelos de autos; en este caso el valor principal del negocio existe en crear estos nuevos diseños y modelos reutilizando los mismos componentes en lugar de volver a crear todas las piezas con cada modelo nuevo.

La mayoría de los grandes proveedores de software como IBM, Microsoft, SAP, etc han iniciado su ola de producción de herramientas alrededor de esta arquitectura, y en los siguientes años veremos un crecimiento en el uso de la terminología de SOA para una gran cantidad de productos de software, que se modificarán para ser de cierta forma “SOA compliant”. En los siguientes párrafos resumiré la propuesta de IBM y SAP, y concluiré con algunas recomendaciones.
La propuesta de IBM está centrada en el uso de su bus de servicios o ESB (Enterprise Service Bus) y el uso de herramientas específicas como Websphere Business Modeler, Integration Developer, Process Server y Business Monitor durante el ciclo de vida de las soluciones. El siguiente diagrama muestra el ciclo de vida propuesto por IBM:

[photopress:ibmSOA.jpg,full,centered]

La propuesta de SAP está basada en el framework o suite llamada SAP Netweaver que he descrito en otro artículo; las piezas claves de SAP son el Application Server, su herramienta de integración (XI o Exchange Infrastructure ahora renombrada a PI o Process Integration), el portal y MDM (Master Data Management). La propuesta de SAP es ESA (Enterprise Service Architecture también referida como Enterprise Service-Oriented Architecture), y la propuesta realmente es modificar los Web Services para reflejar funciones completas de negocios que serían las piezas de las soluciones compuestas.

En la propuesta de SAP un Web Service debe exponer una función de negocio, por ejemplo “Cancelar Orden” en lugar de “Borrar Orden”. La diferencia es que “Cancelar Orden” contiene semántica del negocio, en el sentido que esta funcionalidad implica modificar el nivel de inventario, cancelar los envíos programados, etc. a diferencia de “Borrar Orden” per se que significar el borrado de un registro en la base de datos de órdenes.
Mi propuesta para atacar el tema de arquitectura orientada a servicios (SOA) se basa en un enfoque del más alto al bajo nivel, en parte soportada por ideas de Thomas Mattern y Dan Woods en su libro “Enterprise SOA: Designing IT for Business Innovation”
Mattern and Woods comentan un enfoque de 5 C: Conceive, Consume, Compose, Create, and Control. Una vista más gráfica se muestra en el siguiente diagrama:

[photopress:ESAmap.JPG,full,centered]

Mi recomendación para iniciar la transición hacia una arquitectura basada en servicios se describe en el siguiente plan de alto nivel:

1. Definir un Roadmap que contemple los aspectos de negocio y de tecnología.
2. Identificar los componentes de negocio reutilizables
3. Modelar y diseñar un piloto o prueba de concepto de una aplicación compuesta que abarque de preferencia al menos dos áreas de negocio.
4. Seleccionar una plataforma, herramientas de desarrollo, tratando de ser lo más independiente de un solo proveedor.
   Desarrollar los building blocks o Web Services que complementan la aplicación compuesta.
5. Controlar o administrar la aplicación o Web Services definiendo un modelo de Governance y mantenimiento de los mismos.

Existen varios puntos de coincidencia que personalmente veo entre el modelado de las aplicaciones compuestas y las herramientas actuales y desarrollos de BPM (Business Process Management) asi como del modelo de Governance y control que existen actualmente en una implementación de IT Service Management como ITIL sobretodo para la parte de monitoreo, estadísticas, help desk, esto último porque con esta información es posible implementar y cerrar el ciclo de mejora continua de las aplicaciones construidas sobre un arquitectura de SOA.

La complejidad de la infraestructura de Tecnología de Información (TI) hoy día ha impuesto un enorme reto en cuanto a la administración y soporte necesario para mantener toda esta maquinaria andando a la par del negocio. Hoy día muchas aplicaciones empresariales que anteriormente eran solo accesibles para las grandes empresas, tales como Customer Relationship Management (CRM), Enterprise Resource Planning (ERP) están accesibles para cualquier empresa mediana o pequeña.

Sin embargo, el reto de administrar toda el área de IT sigue vigente sin importar el tamaño de la empresa. De esta manera muchas empresas han volteado a las prácticas antes vistas solamente en grandes empresas: IT Service Management (ITSM); ITSM impone una estructura formal de IT la cual permite manejar ésta área de forma cohesiva. Esto es muy similar a la forma en que se organiza un grupo de personas o una estructura de procesos en una fábrica.

ITIL en el sentido más fundamental es un conjunto de mejores prácticas que ayuda a las empresas a proveer un servicio consistente y confiable de TI al usuario final a un precio costeable.

Muchas empresas no manejan el área de IT de una manera cohesiva, sino más bien distribuida, lo cual deriva en islas de hardware, software, servicios de telecomunicaciones, cada quién respondiendo por sus respectivos departamentos, sin ver el servicio completo al usuario final.

Bajo la perspectiva de Service Management, cada persona y servicio que afecta la experiencia del usuario final pertenece al mismo equipo. De hecho, los principios de ITIL y otros frameworks están derivados de los mismos métodos de calidad que transformaron la industria en el siglo 20.

ITIL fue desarrollado en UK en 1980 en un esfuerzo del gobierno británico por mejorar su administración de IT. ITIL se ha convertido en casi un estándar global de administración de IT; empresas como HP, IBM, EDS an estandarizado sus operaciones de servicios de acuerdo a ITIL.

El IT Service Management Forum (itSMF) es el encargado de regular y administrar ITIL mundialmente, incluyendo materiales, publicaciones, certificaciones, etc. En conjunto con ISO y BSI han desarrollado estándares como ISO20000 y BS15000 que son estándares de ITSM basados en prácticas de ITIL.

Estructura básica de ITIL

Los procesos básicos de ITIL se muestran en la siguiente figura.

[photopress:itil2.JPG,full,centered]

De esta figura resaltan dos puntos importantes, el primero es que el Service Desk juega un rol central recolectando toda la retroalimentación del usuario final. El segundo punto, es que hay una división de dos tipos de servicios uno dedicado a mejorar la calidad del servicio para el usuario final y el otro orientado a medir y controlar el costo y calidad desde una perspectiva de negocios.

Mitos, lo que ITIL NO es

ITIL no es algo que se pueda implementar “out of the book”. Todo lo contrario, no existe una realación directa entre las mejores prácticas de ITIL y la implementación específica de una empresa. Lo que resulta es una definición de procesos adaptados a la empresa que gobiernan los IT Services y que están a su vez basados en los principios y definiciones de ITIL.

ITIL no es un Standard. Aunque los proveedores utilizan el término ITIL-compliant, no existe tal cosa pues ITIL solamente define las mejores prácticas; sin embargo existen los nuevos estándares BS15000 e ISO20000 que si son estándares de ITSM basados en ITIL.

ITIL no es un Governance Framework. ITIL no puede ser usado por sí solo para asegurar el cumplimiento de Sarbanes-Oxley; sin embargo, ITIL mapea a l framework de COBIT que es el framework de governance de facto para Norteamérica.

ITIL no cubre todos los aspectos de los ambientes de IT. Los ambientes actuales de computación distribuida, Internet, etc pueden no estar cubiertos por ITIL, ya que está pensado para una organización centralizada, propia de los años 80s.

ITIL no es una propuesta “Todo o Nada”. La naturaleza interactiva entre los procesos de ITIL hacen patente la ventaja de contar con una implementación completa; sin embargo, muchas empresas se benefician de implementar solo uno o dos de los procesos de ITIL. Esto es particularmente útil para empresa pequeñas y medianas (PYMES).

ITIL no es una religión. Muchos CIOs puede que búsquen un remedio mágico para resolver los problemas de IT, sin embargo ITIL solamente pone orden en los procesos y ayuda a mejorar la calidad de los servicios.

Más alla de ITIL

Dada la evolución en el área de IT, ha sido necesario abarcar nuevos dominios de IT. Existen un buen número de estándares que soportan el rol extendido de ITSM, los cuales complementan a ITIL. Los tres más importantes son COBIT (Controlled Objectives for Information and Related Technology), SIX SIGMA y MOF (Microsoft Operations Framework).

COBIT pone mayor énfasis en los factores de manejo de riesgo, seguridad, consistencia de los datos, control de costos. Muchos de los objetivos de control en COBIT existen en ITIL. COBIT ha publicado el COBIT QUickStart que está enfocado a las PYMES que no cuentan con requerimientos tan complejos como las grandes empresas.

SIX SIGMA tiene raices comunes con ITIL, es más o menos de las mismas fechas de origen. En la definición más simple, Six Sigma es la herramienta que mide con precisión la calidad, mientras que ITIL monitoreao y regula los procesos de IT.

MOF es el framework de Microsoft enfocado a administrar ambientes basados en herramientas y plataforma de Microsoft; cuenta con procesos mapeados específicamente a productos de Microsoft, un modelo de ciclo de vida que permite crear, evolucionar y monitorear servicios a través del tiempo. Cuenta con una correspondencia con MSF (Microsoft Solutions Framework) la cual provee una metodología para la planeación y rollout de aplicaciones empresariales en un ambiente de Microsoft.

Una guía de implementación

Implementar una estructura basada en servicios puede tomar un largo período de tiempo. Como todo proyecto debería ser abordado con un enfoque incremental, provando y revisando lo implementado a medida que se avanza en el proyecto macro. La secuencia de pasos es muy específica a cada empresa, sin embargo un ejemplo de pasos de implementación se da a continuación:

Evaluar necesidad de la empresa.

Entrenar al personal clave en el nivel de ITIL Foundation.

Crear un plan táctico (Alinear a proveedores forma parte de esta etapa) El plan tambien debe determinar el rol de un framework complementario como COBIT o MOF.

Crear una base de datos de Configuration Management.

Poner Incident Management bajo control. Esto permitira recolectar los datos de los procesos que permitirán la mejora continua.

Implementar Problem and Change Management.

Implementar procesos para atacar requerimientos específicos de negocio. Implementar Service Delivery processes basado en prioridades del negocio.

Espero que esto de una idea a los managers y gente de sistemas de PYMES para poder abordar el tema de ITIL de una manera apropiada para sus empresa.

Netweaver es en parte la evolución de mySAP portal; y digo en parte porque la filosofía de SAP Netweaver va más allá de solamente ser un portal. La idea de SAP Netweaver es ser un foundation o una plataforma sobre la cual alojar todas las aplicaciones de la empresa.

[photopress:sapevol.gif,full,centered]

El stack o capas lógicas de SAP Netweaver son:

1. Personas
2. Información
3. Procesos
4. Plataforma

[photopress:NetWeaverStack.jpg,full,centered]
En la capa de Personas (Integración de personas) se encuentra el portal de SAP (Enterprise Portal) que está orientado a ser una interfaz amigable al usuario accesado a través de un navegador típico. El portal puede ser extendido con las herramientas de colaboración tanto online como offline. Por otra parte, en esta capa de Personas se encuentra un componente de Multichannel Access que la función que cumple es permitir accesar las aplicaciones de SAP desde cualquier dispositivo móvil más alla de un navegador tradicional.

En la capa de Información (Information Integration) se encuentra el componente de Knowledge Management, que realmente es parte del producto de Portal , compuesto principalmente por Document Management y el buscador TREX. Otro componente clave es Business Intelligence (BW) que sirve para explotar información de las aplicaciones transaccionales y generar reportes, los reportes de BW pueden ser expuestos e integrados a través del Portal de SAP. Un tercer componente importante es el Master Data Management (MDM) que sirve para consolidar información y para proveer un repositorio centralizado de datos maestros como materiales, productos, clientes, etc. MDM es un producto fuera de SAP R/3 pero que puede ser integrado.

La capa de Procesos (Process Integration) tiene dos bloques lógicos principalmente, uno es el Integration Broker y el otro es Business Process Management (BPM). La herramienta clave aquí es XI o eXchange Infrastructure (en nuevas versiones se ha cambiado el nombre a PI como la misma capa); con esta herramienta es posible realizar interfaces entre el mundo SAP y el mundo exterior, léase bases de datos, aplicaciones legacy u otros ERP como Oracle, Peoplesoft, etc. El componente de BPM no es un producto, realmente SAP propone el uso de ARIS for Netweaver para el modelado de procesos y utilzar XI para la implementación de los procesos.
Finalmente la capa de Plataforma abarca los componentes que habilitan a todas las aplicaciones para ejecutarse sobre el hardware y el sistema operativo. Los componentes en esta capa son la Base de datos, y los servidores de aplicación (Application Server) que puede ser de Java (J2EE compliant) o de ABAP. Cabe mencionar que el application server J2EE es propio de SAP y es de acuerdo a la especificación del estándar J2EE.

Existen dos componentes lógicos alrededor de estas capas lógicas, que trataremos en posteriores artículos: Composite Application Framework (CAF) y Solution Lifecycle Management; asimismo cubriremos los links que hacen referencia al mundo exterior (Java, Websphere, .net)

Nota. El autor es consultor especializado en temas de SAP Netweaver, cuenta con la certificación “SAP Enterprise Portal, KM and Collaboration”, actualmente labora en una importante empresa de consultoría en México.
[photopress:sapnetweaver.gif,full,alignleft]