Mucho se ha escrito e insistido en que SOA no es algo referente a la tecnología, ni es un Middleware, ni una herramienta que se pueda comprar en una caja (en este mismo blog se puede ver varias entradas que tratan sobre esto, como ésta y ésta). Lejos de esto, SOA es una forma de pensar, una nueva forma de diseñar software. Dicho si se quiere con más parafernalia, SOA es un nuevo paradigma de diseño de aplicaciones software, a la altura (o incluso más) de lo que significó en su día el paso a la programación estructurada o la orientación a objetos.

Por otra parte, SOA debe venir impulsado, en primer lugar, por el área de Negocio. Deben ser ellos los primeros interesados en disponer de servicios software que tengan sentido desde su punto de vista. Que aporten funcionalidad de negocio que puedan incorporar a sus procesos, y que de una manera sencilla, puedan ofrecer a sus clientes nuevos servicios (de más valor añadido) a partir de otros de más bajo nivel existentes en la empresa (composición de servicios).

Sin embargo, todos sabemos que en la práctica, SOA viene impulsado por el departamento de IT de la organización. Desde IT se confía en SOA para que haga realidad el viejo sueño de la reutilización del software, de la flexibilidad en la construcción de nuevas soluciones y el acortamiento de los ciclos de desarrollo.

Creo que en la actualidad, en la gran mayoría de los casos, las IT han dejado atrás el cliché histórico de vivir de espaldas al negocio, en su propio “frikismo” tecnológico y ya esta orientada claramente al negocio y al cliente. Aunque pueda parecer un slogan artificioso tenemos asumido desde las áreas técnológicas aquello de “somos esclavos del negocio” o “damos servicios al negocio”. A fin de cuentas, el área de negocio es el que paga el sueldo al área de T.I..

Por supuesto, todavía está instalada en muchas cabezas la correspondencia entre IT y máquinas, discos duros, consolas, etc. etc. Por supuesto, todos estos elementos son imprescindibles para que funcione el software, pero también es cierto que al área de negocio no les interesa los problemas con la falta de memoria en los servidores o si las CPU están al 100%. Simplemente quieren que los servicios de negocio que reciben estén siempre disponibles (que cumplan el acuerdo de nivel de servicio) para que ellos puedan atender a sus clientes de la mejor manera posible.

Debemos entonces, quitarnos el halo de tecnológico o de infraestructura. En T.I. a fin de cuentas se trabaja con información y no con tecnología. De ahí que hay quien propone incluso cambiar el término TI (Tecnologías de la información) por servicios de información.

Y la reflexión que me hago entonces,es: ¿por que se llama SOA a SOA?. Si lo tiene que impulsar el negocio y verlo como algo propio, ¿que sentido tienen las palabras “arquitectura orientada a servicios”?. “Arquitectura” tiene un tufillo demasiado técnico y no es fácilmente entendible para personas que no están en el mundillo. ¿como se explica a alguien que no es informático que es la Arquitectura de Software?.

Después está aquello, poco afortunado a mi entender, de “orientado“. ¿orientado a qué? parece un quiero y no puedo. Quiero ser esto y no llego, entonces en lugar de “ser” algo, como sólo soy un poquito entonces digamos que esto “orientado”.

Luego está lo de “servicios“. Normalmente en las presentaciones esto nos lleva a explicar lo que es un servicio. Que si los principios de Gartner, que si debe ser reutilizable, puede ser compuesto, distribuible, etc. etc. más y más términos técnicos díficil de entender para los no iniciados.

Modestamente propondría el cambio de nombre de este paradigma que está llamado a revolucionar la situación de las IT y de las aplicaciones software (y espero que así sea). ¿que tal algo como?

Diseño dirigido por negocio.

En inglés quedaría muy “efectista:”

Business Driven Design BDD

¿alguna propuesta?

Actualización: parece que el término ya estaba “inventado”, juro que no había mirado antes 😉

Comparte esta entrada

Share

Anuncios