A medida que avanza la implantación de SOA en una compañía, tarde o temprano, nos tendremos que enfrentar a varias situaciones bastante comunes en todos las organizaciones.
Una de estas situaciones comunes es sin duda la siguiente:
- Tenemos dos aplicaciones: por ejemplo la aplicación que gestiona los clientes y la que gestiona las cuentas corrientes.
- Cada una de estas aplicaciones pertenece a un departamento o área concreto del banco.
- Siguiendo una filosofía SOA ambos han construido servicios de negocio reutilizables por el resto de la organización.
- Tarde o temprano, más bien temprano, aparece la necesidad de un servicio de más alto nivel que combine la funcionalidad de cada uno. Por ejemplo: consultar las cuentas de un cliente.
Estrictamente hablando, esta funcionalidad no pertenece a ninguna de la apliciones ya que queremos que a partir de un nombre y apellidos se recupere del servicio de Clientes el DNI o código interno de cliente y con éste invocar al servicio de cuentas para que consulte todas las cuentas relacionadas con este identificador de cliente.
Ahí va la pregunta del millón:
¿quién tiene que hacer este servicio compuesto que combina ambas funcionalidades?
Obviamente este servicio es útil para la organización y con toda probabilidad será reutilizado por otras aplicaciones. ¿Debe hacerlo la aplicación de Clientes o la de Cuentas? Creo que la respuesta más razonable sería: ni uno ni otro.
Tiene que haber un rol diferente, que tenga una visión más general de las necesidades de la empresa. Un rol que podríamos llamar arquitecto de aplicaciones.
La persona o personas que desarrollen este rol en la empresa deben de tener en cuenta esta situación concreta pero también tener en consideración las necesidades presentes y adelantar las necesidades futuras generales para la empresa.
No hay que olvidar que los servicios SOA deben ser reutilizables. No sirve de nada construir un servicio que sólo valga para una situación concreta. Evidentemente esta generalización (lograr que los servicios valgan para el resto de la organización) no es trivial. Por eso se necesita este rol de Arquitecto de Aplicaciones (el nombre puede ser otro), alguien que no pertenezca a un área en concreto y que sea capaz de saltarse los límites de un área o departamento concreto.
Si SOA ha terminado con las aplicaciones departamentales, las aplicaciones «silos», logrando que todos ofrezcan y consuman servicios de los demás: ¿podemos seguir con un modelo organizativo en el que sólo aplica el límite departamental? Por supuesto que no.
Comparte esta entrada:
Blog de Andrés Hevia 
22/11/2011 at 13:29
BAjo mi punto de vista, el servicio pertenece a clientes, ya que lo que se ofrece es información asociada un cliente en partcular. En toda relación 1 a N
(un cliente tiene n cuentas) siempre manda la entidad que tenga la cardinalidad menor. Por tanto, en este caso el servicio claramente es de clientes. Ahora bien, si tenemos el caso de una relación de entidades de negocio n a n, ahí ya puede haber un problema.
Normalmete también hay una entidad que manda sobre la otra en el contexto de la funcionalidad común que se pretende ofrecer. Por ejemplo, si necesitamos obtener la relación de clientes que han optado por una serie de productos hipotecarios. Esta relación es N:N, pero se ve claro que la relación tiene sentido desde el punto de vista del negocio de los productos, ya que esta información puede servir para decidir qué tipos de productos son más rentables.
Si lo que se quiere son los productos de un determinado cliente. Es la misma relación n:n, pero esta funcionalidad tiene más sentido desde el punto de vista de clientes. Por ello, creo que siempre se puede decidir a quien pertenece una determinada funcionalidad o servicio funcional.
Creo que la labor del Arquitecto va más allá de hacer los servicios que no son de nadie. La labor del Arquitecto es la de diseñar el sistema, elegiendo los componentes arquitectónicos mas adecuados y mantener la idea conceptual a lo largo del proyecto en el que participe. Así como realizar prototipos tempranos que avalen la concepción del sistema que quiere construir.
Estoy de acuerdo plenamente contigo en que el paradigma SOA rompe con la organización departamental de la compañía.
Saludos!!
23/11/2011 at 19:16
Lo de la carnalidad puede ser un criterio a tener en cuenta. Sin embargo, puede ser un poco subjetivo. Si hablamos de clientes e hipotecas o clientes y productos, podemos decir que el que «manda» es el producto. Sin embargo, podemos hacer un enfoque hacia al cliente y decir que el cliente es el que manda, que toda la empresa debe enfocarse al cliente. ¿cual sería entonces la parte que predomine?
23/11/2011 at 08:41
Yo creo que la mejor solución es crear un departamento o área que aglutine todos los servicios de uso común o general. En uno de los clientes para los que he trabajado la solución que se ha aportado es esa, de tal forma que en el momento que un servició pasa a ser utilizado por varios departamentos, o por un mismo dpto. en varios países por ejemplo (por ejemplo un banco internacional) dicho servicio pasa a ser responsabilidad de dicha Area o dpto(denominada servicios estructurales). Por supuesto si el desarrollo es nuevo, y se sabe de antemano que será utilizado por varios dptos. lo gestionarán ellos desde el principio.
Esto da la ventaja de que los evolutivos sobre esos servicios están centralizados, y por tanto mas controlados. El inconveniente es que el conocimiento de la aplicación lo tienen principalmente las áreas que lo usan, lo cual supone un coste adicional en cuanto a gestión y traspaso de ese conocimiento al Area o dpto. que se encarga de los servicios estructurales. No obstante creo que los beneficios son mayores.
19/06/2013 at 03:53
Hola estoy buscando un Arquitecto SOA y un consultor en Gobierno SOA,Analista soporte Tic y Gobernanza, Consultor en Automatizaciòn de Procesos, Consultor en Reingenierìa de Procesos, Director de Proyectos y Consultor en Arquitectura de Datos, agradecere a los interesados enviarme sus CV actualizados a oencinas@indracompany.com, el trabajao es para laborar en perú en un proyecto emblematico que transformara una intitucion estatal. agradecere reenvien esto a sus referidos y conocidos que clacen con el titulo de cada busqueda. es importante que puedan evidenciar su experiencia con documentos de formacion y de experiencias laborales por ser requisito indispensable para el gobierno peruano. El horizonte de tiempo del proyecto es de 3 años. buscamos disponibilidad inmediata y los apoyamos con sus tramites migratorios.
19/06/2013 at 08:23
Un proyecto interesante 🙂