Tag: SOA

En algunos sectores, como por ejemplo en los productos de consumo, alta tecnología y los proveedores de la industria farmacéutica, se conceden rebajas para ciertos clientes directamente. En la distribución al por mayor a veces los mayoristas reciben acuerdos de precios de sus proveedores para su aplicación directa en determinados clientes o grupos de clientes, muy a menudo con limitaciones en valor o en cantidad.

SAP ha liberado nuevos servicios para acuerdos de precios, que están ya disponibles en el ERP y permiten definir las condiciones entre los proveedores y los clientes que se consideran en el pedido de ventas.

Estos servicios B2B permiten un fácil mapeo de información de los precios de entrada de los proveedores. Este servicio B2B permite la asignación de cualquier formato de datos de cualquier estándar de la industria, y facilita el intercambio de datos con sus proveedores de manera significativa.

Beneficios de los servicios B2B para el emisor:

Los servicios web existentes proporcionan la tecnología para el mapeo. No se requiere software adicional para asignar los campos requeridos en los documentos XML. Por tanto, los costes de los proyectos de implementación disminuyen de manera significativa.

Beneficios generales de los servicios B2B desde el punto de vista del receptor:

Con los servicios B2B la asignación de datos durante el “intercambio electrónico de datos” se reubica en SAP. El mapeo de la información externa se incluye en la información interna. Gracias a ello se evita a realización de costosos proyectos de implementación de EDI, que ya no son necesarios.

Resumen:

Los servicios B2B para los acuerdos de precios deben bajar costes y esfuerzos y, en consecuencia, deben bajar las barreras de entrada para que los pequeños proveedores puedan participar en el intercambio electrónico de datos.

No hay muchas historias de éxito o de fracaso de SOA a compartir ya que pocos realmente han logrado completar la adopción de SOA, pero hay muchas empresas que han comenzado su viaje en ese campo. Como parte de mi trabajo tengo la oportunidad de formar parte de varios viajes de SOA y aunque están en las primeras etapas ya hay varias lecciones que hemos aprendido. 

En todos los contratos SOA en los que yo estaba involucrado, nos dimos cuenta (tarde o temprano, y cuanto antes mejor) que sin tres pilares principales del edificio que estamos tratando de construir se derrumbaría. Estos principios son: el apoyo e implicación CxO, la semántica y un modelo de propiedad de la información clara. 

Apoyo e implicación CxO:

SOA no es sólo una tecnología o la arquitectura de IT, SOA es un cambio que afecta a toda la empresa. La adopción de SOA afecta el dominio del negocio de la empresa, así como los dominios de la información, aplicaciones y tecnología. Refleja las necesidades del negocio. Por lo tanto, si la empresa no adopta los servicios como un concepto para dirigir la empresa, la implantación de SOA será un fracaso. Los cambios en el negocio demandan no sólo apoyo sino también la participación de CxO en este proceso. Sin el apoyo y la participación directa del nivel de CxO no conviene ni siquiera tratar de iniciar al viaje SOA. 

Semántica:

La semántica es esencial para SOA. Sin semántica de negocio e información, será imposible crear una implementación de SOA. Si su empresa no tiene ningún modelo semántico de negocio ni de información usted no tiene los fundamentos para crear servicios que proporcionan las funciones de negocio mediante el uso de la información como las entradas y salidas. Usted sólo tendrá las bases para construir otra torre de Babel. La creación de modelos semánticos puede parecer obvia y sencilla, pero la mayoría de las empresas no tienen un modelo semántico para los negocios y la información de que (al menos) la mayoría de las unidades de negocio de la empresa aceptan. Además, es un proceso complejo y tedioso para construir modelos semánticos y el apoyo a su alrededor. Creo que sin un marco o metodología probada esta tarea se hace aún más difícil de lograr. Sin un modelo semántico claro se encontrará en un callejón sin salida de una forma u otra. 

Modelo de propiedad de la información clara:

La información es el componente central de SOA. Al final del día los servicios de negocio reflejan las capacidades de manipulación de datos. La mayoría de los problemas de IT en la empresa, por lo general, provienen de situaciones donde la información es manejada por dos o más unidades de negocio o es sólo un activo de una unidad de negocio. Si queremos construir una verdadera implementación de SOA, la propiedad de la información debe ser explícita y aprobada por todas las partes en la empresa. Los servicios se refieren a la manipulación de datos y la transferencia de los resultados para evitar silos de datos y la duplicación de datos. Sin acuerdos sobre la propiedad de la información no seremos capaces de solucionar los problemas. Por lo tanto, los problemas van a aflorar a la superficie en el transcurso de nuestro trabajo.

Es habitual que por parte del departamento de Sistemas de una compañía se generen muchas discusiones sobre la manera “correcta” de implementar una arquitectura orientada a servicios (Service Oriented Architecture ó SOA), pero la realidad nos muestra que la mejor manera de adoptar SOA es convencer a “la parte empresarial” de nuestra compañía de las ventajas de esta arquitectura para el negocio. Debemos ser realistas y aceptar que las Tecnologías de la información son sólo una herramienta o un facilitador para que el negocio alcance sus objetivos.

Service Oriented Architecture
De hecho, ya que las TI son la herramienta para gestionar la información de la empresa, siempre acaban reflejando la situación de la misma. Es decir, la información de la empresa estará mejor ó peor en función de la forma de gestionar el negocio, por tanto, hay una influencia directa del negocio en las TI.

Y esto significa que desde el lado del departamento de Sistemas de Información es posible encontrar una buena arquitectura y lanzarse a utilizarla, sin embargo, si nos ponemos a resolver los problemas de TI sin resolver primero los problemas del negocio, es probable
que fracasemos.

Todos estamos familiarizados con los típicos “problemas imposibles de TI” que todo el mundo se esfuerza en resolver desde el lado de sistemas: el propio departamento, los proveedores de soluciones, los proveedores de servicios de implantación… Pero ¿Alguna vez nos paramos a pensar porque nos encontramos con estos problemas? Si alguna vez lo hacemos tal vez nos demos cuenta de que el problema “irresoluble” que tenemos en TI, es en realidad un reflejo de un problema del negocio. Si este es el caso, no importa que arquitectura de TI acabemos eligiendo. La solución al problema está en rediseñar primero los procesos de negocio.

Esto es fácilmente entendible si acudimos al recurso que utilizan algunos autores de comparar la arquitectura de sistemas de una empresa con la planificación urbana de una ciudad. Por ejemplo, si en una ciudad se ha decidido construir el aeropuerto en una ubicación errónea, cuando se realice la planificación del tráfico de mercancías y personas, la ubicación de los edificios y complejos de oficinas, y el trazado de vías férreas y autopistas, no importa las vueltas que le demos al diseño, la solución nunca será optima, porque la ubicación del aeropuerto no lo es. Si, utilizando esta analogía, comparamos el tráfico de personas y edificios con el tráfico de información del sistema, los edificios con las aplicaciones, y las carreteras y vías férreas con la infraestructura, entenderemos porqué solo cambiando la ubicación del aeropuerto (los procesos de negocio) se puede optimizar los sistemas.

El problema al que se enfrentan hoy las empresas respecto a SOA, es que SOA es una arquitectura “técnica” impulsada por el departamento de sistemas, pero a menudo sin consultar al lado del negocio de la empresa. Lo irónico del asunto es que realmente la arquitectura SOA puede ayudar a las empresas a rediseñar los procesos de negocios evitando los “problemas irresolubles” de sistemas, que son los que a su vez impiden tener éxito al implantar una arquitectura SOA.

Esta paradoja nos indica que los proyectos de implantación de SOA deben estar íntimamente ligados a las necesidades del negocio y que junto al equipo de sistemas, debe contarse con un equipo de la parte de negocio que apoye el cambio y que aproveche la implantación de la nueva arquitectura para rediseñar procesos allí donde fuera necesario. Solo así se garantiza el éxito de un proyecto SOA.