A raíz de esta entrada me hago la siguiente reflexión: quizás hemos estado mucho tiempo poniendo de relieve los beneficios, creo que innegables que tiene SOA desde el punto de vista de la arquitectura técnica. Sin embargo, quizás hemos dejado un poco de lado lo que de verdad tiene que significar SOA, los beneficios que tiene para el negocio.

En el post al que me refiero se citan los siguientes:

1. Bajo acoplamiento
2. Transparencia en la localización de los servicios
3. Reutilización
4. Mejor “testeo” de los servicios
5. Desarrollo paralelo al poder independizar el desarrollo de las “pantalla” del de los servicios

Beneficios que creo que son innegables. Pero como tenemos un gran trabajo por hacer, y me refiero a convencer a la gente de negocio y a los que toman las decisiones del “gasto” en la T.I., creo que nunca se es bastante pesado en ponerlo de manifiesto.

Imperativos de negocio

El negocio nos pide lo siguiente:

1. Conectar los activos que ya tenemos
2. Extraer más valor de lo que ya tenemos
3. Extender y evolucionar lo que ya tenemos

Como vemos aquí, algunos de los principales requerimientos que se hacen a T.I. no es una tecnología revolucionaria. Simplemente y siendo prácticos, nos hacemos la siguiente reflexión:

hemos estado años pagando millones por unos sistemas informáticos y tenemos que rentabilizarlos. Tenemos que aprovechar lo que ya tenemos y sacarle más jugo si es posible. Además si tenemos en cuenta que hoy en día no tenemos mucho dinero que gastar  hay que extraer más valor de los activos que tenemos actualmente en la empresa.

¿Y como se consigue esto?

Pues en muchas ocasiones de una manera que obviamente es más fácil de decir que de hacer: conectando esos activos con otros.

Ya han pasado los tiempos de aplicaciones verticales, aplicaciones silo, diseñadas para no conectarse con nada y tener un fin meramente departamental o de nicho dentro de la empresa. Es necesario conectar las cosas para sacar más valor a lo que ya tenemos.

¿Y bien? ¿cual es la solución a estos requerimientos de negocio? La respuesta es fácil: SOA.

En conclusión

Así pues, no debemos tener reparos ni cortapisas en hablar a negocio (desde el área de T.I.) sobre SOA y los beneficios que conlleva (también por supuesto de sus riesgos).

Según la muy exigente normativa DSI PSS (Estándar de Seguridad de Datos para la Industria de Tarjeta de Pago), para que una empresa pueda almacenar o incluso únicamente procesar tarjetas de crédito, incluso sin guardarla en ningún momento, tiene que cumplir una serie de requisitos bastante difíciles de implementar.

Una de las más importantes, y la que más consecuencias tiene es que todos los sistemas que estén en la misma red que el que procesa la petición de la tarjeta tienen que cumplir con la misma normativa. Es decir, si en la misma red que la aplicación de pago con tarjeta, tenemos otras 100 aplicaciones (con sus correspondientes middleware y base datos).

Es fácil de imaginar que es lo que pasaría en la informática de una empresa si una aplicación de negocio, digamos que tradicional, tiene que integrar los pagos con tarjeta. Como esta aplicación seguramente estaría muy acoplada con el resto de aplicaciones de la empresa, no encontraríamos con la clásica bola de espagueti con decenas o cientos de llamadas entre ellas que nos daría como resultado que toda las aplicaciones de la empresa deben cumplir con la normativa que comentan al principio. Fácilmente, esto podría representar un proyecto de muchos meses, años siendo realistas, con un coste difícil de justificar (si no imposible) ante negocio.

¿Donde nos puede ayudar SOA con esto?. La respuesta es bastante inmediata: siguiendo los principios de desacoplamiento e independencia de la localización física del servicio podemos reducir la complejidad y coste de forma muy, pero que muy, significativa.

Desacoplamiento:

Mediante este principio, como ya sabemos, las aplicaciones o más bien los servicios están muy débilmente acoplados con los otros servicios que forman la solución de negocio. El único acoplamiento que existe es el contrato entre los mismos.

Independencia de la localización física del servicio:

Un servicio debe ser independiente de la localización física donde se ejecute. Por eso, el consumidor de ese servicio no debe saber dónde está el servicio a la hora de invocarlo. Es por eso que existe la figura del registro de servicios, un índice al que el consumidor acude para localizar el endpoint (dirección física del servicio) donde tiene que invocar.

Sumando estas dos cosas, podemos integrar fácilmente la funcionalidad de pago con tarjeta, con arreglo a esta exigente normativa con el mínimo esfuerzo y coste posible.

Por un lado, si es necesario, el servicio de pago con tarjet, se puede desplegar (él sólo incluso) en una red diferente a el resto de servicios de la empresa.

Por otro lado, los clientes sólo tienen que invocar al servicio de pago (y ni siquiera sabrán donde está)

Conclusión

Como vemos, si tenemos en cuenta mínimamente los principios sobre los que se asienta SOA, la solución aquí expuesta es poco más que una obviedad. Sin embargo, como he dicho en post anteriores, en la mayoría de las veces, para el éxito de SOA, debemos tener en cuenta dos puntos relativamente sencillos:

1. Con los principios más sencillos, aplicándolos con criterio, tenemos la solución a muchos de los problemas que se nos pueden plantear (ver la regla del 20%).
2. La mayor dificultad que tiene SOA es la de convencer a la gente. Me temo que indicar esta solución por parte del arquitecto SOA es bastante más sencillo que lograr que esto se implemente en la realidad (y no me estoy refiriendo a problemas técnicos).