Las falsas promesas de SOA y las TIC

He leído este artículo sobre el impacto de SOA (Service Oriented Arquitecture) en la cuenta de resultados de una empresa. La verdad es que dudo si hablamos de una arquitectura o de comprar pulseras power balance para toda la organización, porque los milagrosos efectos sobre la cuenta de resultados podrían ser similares. Habría dejado un comentario pero no se puede comentar en esta web de tecnología. Veamos que nos prometen que nos puede dar SOA:

  1. Una respuesta más rápida ante crecimientos del negocio.
  2. Un mejor posicionamiento para realizar externalizaciones – SaaS de módulos informáticos.
  3. Una reducción en el plazo de integración entre aplicaciones existentes y futuras.
  4. Un aumento de las posibilidades de acceso, cruce y explotación de la información proveniente de diferentes módulos.
  5. Una menor dependencia de proveedores de software debido al aumento de la capacidad de negociación.
  6. Se posibilita la tan necesaria, en estos tiempos, reducción de costes gracias al acceso a mercados de componentes-módulos tecnológicos en modo SaaS para las operaciones informáticas menos nucleares o que sean más estándares.
  7. El acceso a una mayor base de proveedores de servicios tecnológicos con “cajas negras” similares. SOA, además, permite ser reaprovechada a partir de sinergias existentes con la orientación por procesos (BPM), lo que se traduce en un aumento de productividad.

SOA tiene muchos beneficios, pero decir que por si sola genera beneficios en la cuenta de resultados me parece una exageración y esto es malo para los clientes y para los consultores que recomendamos SOA a nuestros clientes porque hace que todos perdamos credibilidad y seriedad. Aplicar SOA es desarrollar los proyectos TI de un modo concreto, esto puede ser beneficioso o una pérdida de tiempo en función del tipo de proyectos y del tipo de empresa donde se aplican los mismos. Si ya es difícil decir cuando es beneficioso aplicar SOA afirmar que los beneficios se ven en la cuenta de resultados es una excentricidad de un modo genérico, suena bonito pero es poco preciso.

Comparto los puntos (1) y (3), SOA puede proporcionar una reducción del tiempo de puesta en marcha de aplicaciones o de adaptar servicios a nuevos requisitos, pero no un aspecto tecnológico, se basa en los cambios de organización y procedimientos en el desarrollo de aplicaciones, no es “comprar” SOA y ser más rápido. Ahora, convertir la velocidad de implantación de TI en beneficios en la cuenta de resultados no es algo al alcance de cualquier empresa, solo organizaciones muy maduras en el uso de la tecnología llegan a convertir velocidad en beneficios empresariales de un modo constante. Y los que lo hacen es porque aplican muchas más ideas que SOA. La velocidad de reacción es una ventaja competitiva que nos puede ayudar pero por si sola no incrementa los beneficios.

No comprendo la mezcla con el tema de la externalización que comentan los puntos (2), (6) y (7), externalizar es beneficioso (no siempre) pero no tiene que ver con SOA, de hecho no creo que haya casos prácticos que demuestren que SOA y la externalización han tenido hasta hoy relación o que haya soluciones SaaS que necesiten específicamente que el cliente utilice una arquitectura SOA para utilizarlas. Es una mezcla de ideas inconexas que confunde a las organizaciones de TI.

El punto (5) sobre la menor dependencia de proveedores, no es comprensible, ¿hay más proveedores que te proporcionen servicios compatibles con SOA que los que lo hacen de un modo más tradicional? ¿De verdad? Nombren diez proveedores de soluciones que necesiten una arquitectura SOA en las instalaciones del cliente para poder contratar sus servicios.

El punto (4) es para mi el peor, ¿SOA aumenta las opciones de cruzar información? Yo tengo mis dudas, de hecho para mi SOA al distribuir más la información y las funciones entre múltiples sistemas diferentes con modelos de datos distintos complica el análisis de la información, no lo facilita, desde luego ese perjuicio puntual puede solucionarse y los beneficios de SOA pueden compensarlo sobradamente, pero decir que SOA se compone de “cajas negras” como afirma y al mismo tiempo afirmar que facilita explotar la información interna (lo que es una “caja blanca”) es incoherente.

¿Qué es un BPM?

Los clientes sufren un problema común con las soluciones BPM (o BPMS), y es que hay muchos proveedores afirmando que sus productos son BPM, y muchos BPM que al analizarlos son muy diferentes funcionalmente. En realidad, el debate en si no me parece demasiado interesante, creo más en un análisis de las necesidades y construir una solución para ellas con las tecnologías disponibles, sean BPM o no. Pero es cierto que muchos clientes consideran que implantar un BPM les ayudará a cambiar su forma de trabajar y facilita la gestión por procesos, de modo que puede ser interesante definir que es un BPM exactamente.

Como ejemplo, creo que como lo define Gartner es una definición útil:

  • Un BPM es una solución software que aplicada a los procesos permite obtener los objetivos de mejorar la eficiencia y el coste de ejecución de los procesos (Gartner dice “best performance”)
  • Además un BPM debe incluir las siguientes diez áreas de funcionalidades:
    • Un motor de ejecución de procesos y gestión de estados.
    • Un entorno de modelado de procesos.
    • Integración con documentos y contenidos.
    • Gestión de usuarios y grupos (yo añadiría roles y gestión de la estructura organizativa a esta pareja, pero Gartner no lo menciona).
    • Herramientas de conectividad con otros sistemas (abreviando mucho, capacidades SOA, integración por correo electrónico, API de conexión).
    • Soporte de gestión de eventos de negocio y monitorización de actividad de negocio (BAM), aunque yo creo que es un añadido al BPM y no necesariamente parte de él.
    • Herramientas de simulación y optimización.
    • Gestión de reglas de negocio.
    • Herramientas de administración del sistema. (Me parece un poco obvio como funcionalidad)
    • Repositorio de componentes y registro.

Me sorprende no ver la exigencia de disponer de bandejas de tareas, supongo que está implícito en la gestión de estados pero para mi son dos cosas diferentes, también creo que se debe exigir que un BPM disponga de herramientas de diseño de formularios o pantallas de usuario (aunque casi todo el mundo desarrolle las suyas en sus entornos de programación) porque en caso contrario el BPM por si mismo no permitiría ejecutar procesos. Otro tema importante es disponer de un sistema de auditoria y ejecución de informes, puede que lo integren en el punto de BAM, pero de nuevo para mi son cosas diferentes.

Funciones de valor añadido

Aunque pocas soluciones lo tienen yo creo que aportaría mucho exigir que existieran librerías de elementos, procesos y subprocesos genéricos que poder usar para el modelado (correos de aprobación, notificaciones) que facilitarían la implantación y la orientación a procesos. Otro tema a considerar muy importante es tener capacidad de integración con los ERP más comunes y disponer de un repositorio de documentos de negocio porque simplificaría los proyectos de implantación.