Pregunta clásica. Ante la avalancha de acrónimos, no siempre es fácil comprender todo lo que está en juego, sobre todo cuando la confusión es posible, especialmente, en lo relacionado a su interdependencia. En el dominio que nos interesa, las dos siglas que aparecen más a menudo son BPM (del inglés, Business Process Management, gestión de procesos de negocio) y SOA (del inglés, Service Oriented Architecture, arquitectura orientada a servicios). ¿Cuál es la relación entre ambas?

Sin entrar en detalles, diremos que el BPM consiste en formalizar y automatizar los procesos de negocio de la empresa, incluyendo a los usuarios y a las aplicaciones en los mismos procesos. Para ello, es necesario implementar una solución de software que proporcione, por una parte, las herramientas de parametrización que permitan modelizar y describir cómo se encadenan las etapas de los procesos, y, por otra parte, un motor de ejecución que se encargará del tratamiento de cada uno de los expedientes iniciados por usuarios (agente del front office, comprador…), eventos (nuevo correo electrónico, nuevo archivo XML…) o aplicaciones (llamada a la API, mensaje de aplicación, servicio Web…) La suite de aplicaciones de BPM proporciona de forma predeterminada las técnicas necesarias para tratar estas tres «poblaciones», ya sea para el inicio de un nuevo expediente, el tratamiento de una etapa, en los que cada «participante» aportará su valor añadido al expediente que se está tratando o el acceso a un recurso del sistema de información.

La SOA es una forma de diseñar, implementar y administrar la infraestructura lógica en la que se exponen los recursos bajo la forma de servicios independientes accesibles en un formato estandarizado para las personas y los sistemas.

Un servicio es una tarea de negocios o una función correctamente definida y repetible que pueden ser llamadas de una forma estándar. La naturaleza de dicha función puede ser más o menos amplia. Puede ser una simple tarea unitaria, como actualizar la dirección de un empleado, o una tarea mucho más compleja que ponga en marcha varias acciones y genere un cierto número de resultados posibles.

La convergencia entre SOA y BPM parece relativamente evidente, un proceso se convierte en un servicio compuesto de servicios elementales que son las etapas del proceso; de la misma forma, el proceso puede ser un consumidor de servicios estándar del sistema de información.

El enfoque conjunto de la BPM y la SOA responde a una problemática distinta y que es probablemente la más compleja: ¿cómo definir la granularidad de los servicios, cómo organizar la reforma? En efecto, poner en marcha la SOA es un trabajo de reforma del sistema de información, con los riesgos que ello implica de efecto túnel si no se fija un cierto número de objetivos operativos o funcionales. La experiencia BPM demuestra que la implantación de procesos marca, a favor de la corriente de su formalización, el camino a seguir para el progresivo paso de las aplicaciones que requieren una interfaz hacia una arquitectura SOA, ya que la BPM está, por definición, centrada en las necesidades de negocio.

En fin, esta convergencia sólo será beneficiosa si no olvidamos que la BPM no es una herramienta de orquestación de servicio, sino más bien un trámite centrado en la formalización de los procesos de negocio y, por lo tanto, centrado en las necesidades de los usuarios.