Consultoría SOA y BPM
El aumento de la eficiencia y la agilidad de los negocios frente a la presión de la competencia, la reducción de costos operacionales y aumento de la productividad y los márgenes de ganancia, y las condiciones cambiantes del mercado tales como el cumplimiento de nuevas regulaciones legales, son retos y prioridades para la alta gerencia de las organizaciones. Esto a su vez se traduce en desafíos para la TI de las empresas que deben reducir la complejidad y ser más sensible a las necesidades del negocio.
Históricamente las empresas han intentado conjugar dos visiones para realizar su negocio:
- Visión de Negocio: Especificar y mejorar sus procesos empresariales (modelado y análisis de procesos de negocio mediante workflows, certificaciones ISO)
- Visión de Tecnología (TI): Informatizar el negocio a través de la tecnología (frameworks, desarrollo e integración de software, metodologías CMMi e ITIL)
Para abordar estos retos, hay dos tecnologías afines: BPM (acrónimo en inglés de Business Process Management) y SOA (acrónimo en inglés de Service Oriented Architecture).
SOA/BPM unifica estas dos perspectivas en una visión común permitiendo que las organizaciones combinen fluidamente sus activos de IT existentes para desarrollar nuevas aplicaciones, procesos y modelos de negocios internos o externos a la empresa.
Tecnológicamente, las Arquitecturas Orientadas a Servicios representan el máximo exponente de la evolución de la informática en los últimos cuarenta años: desde los sistemas Mainframe en los 70, pasando por Cliente-Servidor de los 80 hasta llegar a las Arquitecturas Distribuidas (Corba, RMI, DCOM) en los años 90 para culminar en SOA como la arquitectura del siglo XXI.
BPM es la disciplina clave y la tecnología para automatizar, gestionar y mejorar los procesos de negocio. SOA está relacionado con la producción y gestión de los servicios de negocio reutilizables a partir de los sistemas de TI o de nuevos servicios, y luego para usarlos para construir (componer) aplicaciones de negocio ágiles, en forma más rápida.
BPM y SOA también tienen características diferentes. A nivel general, SOA es algo inferior, centrada en el desarrollo, y técnicas, mientras que el BPM es de nivel superior y orientado a los negocios. Sin embargo, BPM y SOA tienen similitudes (por ejemplo, tratan sobre los procesos de negocio), y más importante, son complementarios. Los procesos de negocio gestionado por BPM pueden utilizar (consumir) los servicios de negocio que se definen y administran mediante SOA. Esto ayuda a que los procesos de negocio sean más flexible y ágiles. Al mismo tiempo, permite la creación de servicios empresariales de alto nivel. Las aplicaciones en SOA a menudo requiere la orquestación de procesos que se encuentra en el ámbito de BPM. BPM y SOA en combinación pueden ayudar a reducir la complejidad, dar cuenta de desarrollos más rápido de aplicaciones RAD (acrónimo en inglés de Rapid Application Development), y acelerar la automatización de procesos en la empresa.
Si nos fijamos en los retos que enfrentan las empresas para alcanzar sus metas y objetivos de negocio, el negocio debe ejecutar de manera eficiente sus procesos, tener acceso a la información en forma correcta y oportuna, y responder a las cambiantes condiciones del negocio. Para ello, TI debe proporcionar a su negocio de la infraestructura, herramientas y aplicaciones necesarias para lograrlo.
Retos para los Negocios y TI de las Empresas
Un entorno de TI se compone de varias aplicaciones comerciales y aplicaciones propietarias (por ejemplo, ERP, CRM y SCM). Estas aplicaciones tienden a utilizar diversas tecnologías y arquitecturas. Algunas pueden estar basadas en host construido en COBOL, sin una separación entre la interfaz de usuario y la lógica y sin ningún tipo de API. Algunos otras pueden ser cliente-servidor escrita en C / C + +, mientras que otras pueden ser más moderno de n capas basadas en Web construidas en J2EE o. NET. Cada aplicación tiene potencialmente su propia base de datos. Algunos pueden utilizar un middleware, mientras que otros no. La figura 1 muestra la heterogeneidad y la complejidad asociadas a TI de una empresa típica.
Cada aplicación de ese tipo normalmente automatiza los procesos de negocio, o más frecuente un segmento de un proceso de negocio más amplio que si se realiza de extremo a extremo, se extiende por varias aplicaciones. En el caso de aplicaciones comerciales estos procesos son genericos y comúnes. Se deben configuran y personalizar para ajustarlos a las necesidades de la empresa por lo general por un equipo de consultoría durante un largo, costoso y laborioso proceso de desarrollo antes de ir a la producción.
Los encargados del negocio, que son dueños de estos procesos, tienen poco control sobre la gestión de sus procesos en estos sistemas. Estas aplicaciones tienden a ser rígidas e inflexible. Es difícil integrar con estos sistemas de manera sistemática y escalable. Además, cuando hay una necesidad de un nuevo servicio o aplicación, es difícil reutilizar la funcionalidad de estas aplicaciones. Cualquier cambio debe pasar por complejas actividades de TI y consumen mucho tiempo y recursos.
Las cosas empeoran con los sistemas legados, como son las aplicaciones de mainframe. Estos sistemas contienen una cantidad significativa de los datos de misión crítica y de la lógica que en muchas de las grandes empresas, tales como bancos, aún estan ejecutando. Esta información es de muy difícil acceso y reutilización, ya que son sistemas fueron desarrollan en tecnologías más antiguas. No es práctico ni posible acabar con ellos. Tiene que haber una forma fácil de reutilizar los datos y la lógica de negocio.
En esencia, los procesos automatizados están encerrados dentro de estas aplicaciones . Cada suite de aplicaciones forma un silo de automatización con su propia base de datos, lógica de negocio, y la interfaz de usuario. También hay redundancia en los datos y lógica a través de estos silos. Por ejemplo, la información acerca de un cliente, una orden, o una parte de un producto, puede residir en múltiples sistemas. También hay asociaciones cruzadas entre silos. Por ejemplo, una orden en un silo está asociado con un cliente que reside en otro. Actualizar o cambiar a una entidad en un silo puede requerir cambios en múltiples aplicaciones y bases de datos de los otros silos. La figura 2 proporciona una visión simplificada de los silos de aplicación típicas.
De ahí la necesidad imperiosa de la integración a través de estos silos. La funcionalidad de estos silos deben ser expuestos de manera que puedan ser reutilizados en la construcción fácil y rápida de nuevas aplicaciones de negocio y servicios. TI deben proporcionar la infraestructura y herramientas para la automatización y la gestión de los procesos empresariales de extremo a extremo, mientras que aprovechar la información y la lógica de las aplicaciones existentes. El sistema resultante debe ser accesible y utilizable por los usuarios de negocios. También debe proporcionar los medios para medir el rendimiento del negocio con el objetivo de que los ejecutivos puede supervisar el cómo se está ejecutando los procesos vesus las estrategias de negocio y los objetivos corporativos.
Desafíos para SOA/BPM
BPM y SOA responden a las necesidades de las empresas y, a su vez a los requisitos de TI. Cada uno responde a ciertas necesidades, pero utilizando los dos juntos, podemos darnos cuenta de beneficios mucho más profundo.
BPM permite a las empresas simplificar y automatizar sus procesos de negocio a través de la organización, aumentando así la productividad y reduciendo los costos de funcionamiento de esos procesos. Mediante la gestión de cara al cliente y procesos de negocio utilizando BPM, las empresas también pueden aumentar la satisfacción del cliente y su retención.
BPM permite a las empresas modelar, automatizar y optimizar los procesos de negocio que impliquen a personas (es decir, empleados, clientes y socios) y los de sistemas. Un proceso de negocio es una actividad con múltiples paso que generalmente implica a varias personas y sistemas, de manera que cada actividad es realizada por una persona o una pieza de software (por ejemplo, un servicio Web). En algunos casos un proceso de negocio puede estar muy centrado en los sistemas y tienen pocas o ninguna intervención humana, o puede ser de gran colaboración humana y con pocas o ninguna actividad del sistema. Para cada actividad humana, debe definirse una interfaz de usuario que puede ser Web, correo electrónico o basado en tecnología móvil. Las actividades en un proceso de negocio suelen vincular y coordinar y estar sujetas a un conjunto de reglas de negocio y políticas.
El artefacto producido por un BPMS es una aplicación de procesos de negocio. Dado que los procesos de negocio son modelados y diseñados en un entorno visual en un BPMS, el costo de desarrollo se reduce significativamente en comparación con la escritura de código. BPM también permite a los ejecutivos tener visibilidad y control sobre sus procesos permitiendoles observar y medir la ejecución de los procesos y tener una influencia en la mejora de sus procesos. Así, BPM puede ayudar a cerrar la brecha entre el negocio y TI. Esto permite un mejor seguimiento, monitoreo y medición de las actividades de los procesos de negocio. Debido a que los procesos de negocio y las normas en una representación visual en el BPM, es más fácil para controlar y medir sus actividades empresariales y rendimiento. Y cuando hay una necesidad de cambio, es más fácil de modificar, mejorar los procesos de negocio y las normas desde BPM. Esto hace que una empresa sea más ágil y sensible a los cambios de negocios, planeado o no.
La forma en que una empresa efectúa sus operaciones y lleva a cabo su actividad empresarial es esencialmente capturada a través de sus procesos de negocio modelados y automatizados. Las organizaciones se diferencian y crear ventajas competitivas a través de la singularidad de sus procesos de negocio. BPM permite a las organizaciones construir esa singularidad en sus procesos de negocio. A diferencia de las aplicaciones comerciales que suelen empaquetar los procesos de negocio dentro de sí, BPM pone en los analistas de negocios y ejecutivos de empresas (las verdaderas partes interesados en los procesos de negocio) en el control y responsabilidad de sus procesos de negocio. Si bien se permitirá su participación en la aplicación de BPM, la gente de negocios se acerca a la comprensión, la definición y la gestión de sus propios procesos. BPM también proporciona una manera eficaz para hacer la transferencia de conocimientos a través de la documentación de los procesos de negocios que los usuarios puedan recibir como parte de su formación.
Servicios Web y SOA para reutilización y agilidad
Los procesos de negocio al ser administrado por BPM deben integrarse con las aplicaciones y sistemas existentes. Para ellos necesitan tener acceso a las funciones que están empaquetadas dentro de las aplicaciones. Código duro de punto a punto para la integración con las aplicaciones no es una buena solución, ya que crea un ajuste rígido con la aplicación y hace que el proceso sea frágil y poco flexible. Cada vez que hay cambios en la aplicación, el punto de integración puede cambiar también. Un cambio en el proceso también puede romper el punto de integración.
SOA y los servicios web proporcionan la clave para abrir los silos aplicaciones y exponer su funcionalidad fuera de ellos. Usando tecnologías SOA, las funciones dentro de las aplicaciones de negocio puede ser capturadas y empaquetadas con bajo acoplamiento, autonomía y reutilización en forma de servicios Web, por lo general. Los servicio Web son una interfaz pública (contrato) que especifica cómo debe ser usado. Un consumidor de servicios simplemente obtiene toda la información que necesita a través la interfaz que se publica en un formato estándar.
Estos servicios son almacenados y registrados en un directorio de servicio para que todos los interesados y autorizados los pueden utilizar. La figura 3 muestra que los servicios de las aplicaciones antes monolíticas de la automatización se generan y se expone. Comúnmente utilizados actividades, operaciones, segmentos de proceso, y la funcionalidad de los sistemas back-end son capturadas como componentes reutilizables como son componentes J2EE y NET, o preferentemente servicios Web. Estos servicios son registrados y almacenados en un registro de servicio para su reutilización. Estos servicios pueden ser reutilizados en la definición de nuevos procesos de negocio, junto con nuevos servicios.
El mapeo de todas las llamadas a la API de varias aplicaciones empresariales y a los servicios Web puede ser sólo el primer paso en la transición a SOA. Estos servicios suelen ser de muy bajo nivel y no ofrecen mucho valor para el negocio. Para proporcionar más útilidad y orientación a servicios de negocio, los servicios de bajo nivel puede ser orquestados e integrado en un servicio de alto nivel o de servicios compuestos. Por ejemplo, un servicio al cliente de cambio de dirección puede ser un servicio integrado que se compone de cuatro servicios de bajo nivel para el cambio de la calle, ciudad, estado y código postal. Debe haber un componente de orquestación en SOA para este propósito.
Algunos servicios compuestos puede ser en realidad y con pleno derecho llamados aplicaciones compuestas. Una aplicación compuesta es un conjunto de software que implementa una (posiblemente única) función de negocios (potencialmente, un segmento de un proceso más amplio de negocios). Sus componentes accesan datos y lógica de negocio de varios sistemas back-end. Las aplicaciones compuestas pueden ayudar a transformar aplicaciones viejas y legadas de negocio a tecnologías más modernas. Por ejemplo, multiples aplicaciones legadas usadas para un proceso de negocio en particular puede convertirse en una única y uniforme aplicación web.
BPM y SOA, junto
Los servicios de la empresa no son muy útil por sí mismos. Su valor se realiza a traves de la reutilización de diversos procesos y aplicaciones compuestas. A menudo se componen, ensamblan o orquestan medienate el uso de BPM para crear servicios de negocios de alto nivel o aplicaciones compuestas.
A su vez los servicios de negocio que se generan en la orquestación de servicios web pueden ser utilizadas en los procesos de negocios que típicamente incluyen las actividades humanas. Estos procesos se pueden modelar y automatizar usando BPM.
La Figura 4 muestra servicios de bajo nivel que se componen para formar los servicios compuestos que tienen más de un contexto de negocios. Un motor de orquestación basada en BPEL puede ser utilizado para la composición de tales servicios. BPEL en su forma pura no se ocupa de las actividades humanas. Es estrictamente para la orquestación de servicios Web. Sin embargo, la mayoría de los BMP de fines generales también puede manejar la orquestación de un servicio igual de bien. Los servicios compuestos a su vez pueden ser consumidos por los procesos de negocio que implican la participación humana. El lenguaje de proceso de BPM suelen tener explícita la construcción para el manejo de las actividades humanas.
Tener un lenguaje común para definir los procesos de negocio es importante porque ayudará a que los procesos de negocio sean portables a través de diferentes sistemas de BPM. También podría haber una necesidad de integración y la interoperabilidad entre diferentes sistemas de BPM. Dicha norma también contribuirá al desarrollo basado en estándares con herramientas de diseño de proceso.
Un aspecto importante de BPM y SOA es la relación que normalmente tienen los procesos (o un punto de entrada a los mismos) que se definen en BPM puede ser publicado como un servicio Web. Dicho servicio puede ser consumido por otros servicios en las composiciones y orquestaciones o por otros procesos de negocio en BPM. Por lo tanto, BPM y SOA de forma bi-direccional y de vinculación recursiva en términos de publicar y consumir servicios Web: Servicios Web (en SOA) pueden ser consumidos por los procesos de negocio (en BPM). En cambio, los procesos de negocio en BPM pueden ser publicados como servicios Web y consumidos por otros servicios o procesos.
Diseño de Servicios y Procesos
¿Cómo diseñar e implementar SOA y BPM? ,¿Los servicios son lo primero, o los procesos? Podemos comenzar con la construcción de servicios. Tomamos todas las aplicaciones hacemos un mapeo de las API de los servicios. También podemos definir nuevos servicios que pensamos pueden ser útiles. Se trata de un enfoque de abajo hacia arriba. Podemos componer algunos de estos servicios para crear servicios de alto nivel. Todos estos servicios son almacenados en un registro para ser utilizado por los usuarios autorizados. Entonces, cuando el modelo y el diseño de nuestros procesos, esperamos poder encontrar los servicios que serán necesarios en el Registro. El problema con el diseño de abajo hacia arriba es que si un servicio no puede hacer exactamente lo que necesita un proceso o no puede proporcionar la interfaz correcta, tendrá que cambiar el servicio o definir una nueva mutación del mismo.
Otra posibilidad de empezar con el modelado de procesos de negocio en BPM de alto nivel. A medida que trabajamos en los detalles se identifican los requerimientos de integración con otros sistemas o recursos informáticos nuevos que pueden ser los servicios. Asumimos que las interfaces de servicio requerido existen y proceder con el modelado y diseño de procesos . Así que el proceso empresarial dicta los servicios que necesitan para completar los procesos. Cuando llegamos al diseño de un servicio necesario, podemos dividirla en servicios de nivel inferior. Este enfoque es de arriba hacia abajo. Es impulsado por el negocio y los resultados en la creación de servicios que son importantes y necesarios con las interfaces adecuadas.
Figura 5 muestra los conceptos de top-down y bottom-up de diseño en el contexto de los servicios y procesos.
En realidad, a menudo se usa una combinación de ambos top-down y bottom-up en el diseño de manera iterativa. Es posible que algunos servicios de diseño que sabemos que será útil, genérica y reutilizable. Al mismo tiempo, proceso de alto nivel de las actividades de modelado se apuntan a la necesidad de servicios específicos de otros. Diversos grupos pueden colaborar y iterar sobre este proceso hasta que llegar a una definición del proceso óptimo y los servicios que consume como proceso. Tras el despliegue inicial, mediante el monitoreo de la performance de los procesos, las áreas de mejora pueden ser identificadas que pueden resultar en el perfeccionamiento de estos procesos y servicios para lograr tanto el servicio y la optimización de procesos.
Una empresa moderna con SOA y BPM
El principal en construir en SOA y BPM son los servicios y procesos, respectivamente, aunque esta distinción se hace menos relevante en los procesos de negocio en sí mismos pueden ser publicados como los servicios. Desde una perspectiva de alto nivel, SOA gestiona los servicios empresariales y BPM gestiona los procesos de negocio. Los procesos de negocio se componen de los servicios empresariales, que pueden incluir las actividades humanas, así como otros procesos de negocio.
Los servicios de empresas a su vez se componen de servicios de menor nivel que pueden estar vinculados a la informática y aprovechar la infraestructura existente EIS (sistemas de información de la empresa).
Figura 6 muestra una vista de alto nivel de una empresa moderna, donde hay una capa de servicios empresariales en la parte superior de la infraestructura de TI. Estos servicios de negocio puede estar compuesto por servicios de menor nivel que el multiplicar los recursos en la infraestructura. Esta capa de servicios está definido y gestionado por SOA. También hay una capa de procesos sobre la capa de servicio que aprovecha los servicios de negocio a continuación para crear procesos de negocio altamente flexible y ágil. Esta capa está definido y gestionado por BPM.
Servicios Web
El elemento más central en SOA y que es también pertinente en BMP son los componentes de software reutilizables que son llamados servicio que implementan una función útil. Una característica clave de un servicio es que proporciona una interfaz de publicación que se especifica cómo se puede utilizar. La interfaz o contrato especifica qué información se pasa y lo que devuelve (si aplica). Uso de la encapsulación de los detalles de la aplicación y el lenguaje utilizados son ocultadas para el usuario potencial. La puesta en práctica, de hecho, puede cambiar en algún momento, pero mientras la interfaz sigue siendo la misma, utilizando cualquier cliente que no tiene que cambiar. Así, un consumo de un cliente de servicios Web, sólo tiene que preocuparse de que hace servicio (interfaz), y no de cómo lo hace.
Existen diferentes tecnologías que proporcionan componentes reutilizables o servicios. Dicho servicio puede manifestarse como una assembly de . NET, un objeto CORBA, un componente de Java J2EE, o como un servicio Web. Cada uno de estos provee de su propio lenguaje de definición de la interfaz y los protocolos que soporta. Sin embargo, los servicios Web son la tecnología que se utiliza en SOA. Los servicios Web tienen características importantes que hacen el bloque de construcción ideal para SOA. Los servicios Web están débilmente acoplados en el sentido de que no hay relación estrecha entre el cliente y el servicio Web que llama. Los servicios Web también disfrutar de la transparencia de localización. No es importante donde se encuentra un servicio. De hecho, la ubicación de un servicio que está en uso pueden cambiar sin romper nada.
Las principales normas y elementos de trabajo con un servicio web son:
• WSDL (Web Language Services Definition) define la interfaz de un servicio Web
• SOAP (Simple Object Access Protocol) define la codificación de los mensajes que se envían y reciben desde un servicio Web
• UDDI (Universal Description, Discovery and Integration) es un registro y servicios de directorio para almacenar y recuperar los servicios Web, sino que es esencialmente un blanco / páginas amarillas para los servicios Web
• HTTP / HTTPS: HTTP y HTTP seguro son los transportes de primaria (protocolos de transferencia), apoyado por SOAP, SOAP también admite los protocolos SMTP (protocolo de correo electrónico).
La figura 7 muestra cómo se utiliza un servicio Web básico. Un cliente busca un servicio Web en el registro UDDI y obtiene su WSDL. A continuación, invoca el servicio Web.
El servicio Web puede ser síncronico, en cuyo caso el cliente espera (bloques) hasta que se recibe un mensaje de respuesta del servicio Web. El servicio Web puede ser asincrónico en cuyo caso el producto de cliente después de la invocación y el servicio Web responde en un momento posterior, si la respuesta se define para ello.
La comunicación síncrona vs asíncrona es uno de los conceptos fundamentales de SOA. La comunicación síncrona de mapea de cerca a la composición, mientras que los vínculos de comunicación asíncrona a la integración. La siguiente figura expresa este concepto. Figura 8 (a) muestra una aplicación básica de la comunicación asincrónica y contrasta con una aplicación de comunicación sincrónica en la figura 8 (b).
Ambos modelos de comunicación sincrónica y asincrónica son esenciales y deben ser apoyados. La comunicación asíncrona es el fundamento de la arquitectura manejada por eventos (EDA), un pariente cercano de SOA a través de un tema mucho menos popular.
Hay muchas normas importantes para los servicios Web que deben aplicarse y respetarse. Por ejemplo, los servicios Web Reliable Messaging (OASIS WS-ReliableMessaging) estándar que como se desprende de la denominación se refiere a la mensajería confiable entre los servicios Web. Proporciona garantía de la entrega de mensajes entre servicios web para un criterio dado. Por ejemplo, un mensaje debe ser entregado por lo menos una vez, en más de una vez, exactamente una vez, o en orden.
Otro estándar importante de servicios web es el de seguridad de Servicios Web (OASIS WS-Security), que define las funciones de seguridad para servicios Web, tales como la autenticación y la asociación de tokens de seguridad con mensajes.