Como es sabido, a la hora de hacer un análisis SOA, podemos hacer un enfoque top-down (en el que se identifican los servicios a partir de los requisitos de negocio), o el enfoque contrario, partir de los servicios ya existentes e intentar cubrir los requisitos de negocio con lo que se tiene (podéis ver esta entrada del blog donde hablo de esto).
Teniendo esto claro, lo siguiente sería pensar en ¿quien tiene que hacer este análisis? o mejor dicho ¿qué perfil debe tener la persona que hace esto?. En un principio podemos pensar en el analista SOA, aunque hay un matiz importante, si el proyecto es suficientemente complejo, con varios departamentos de la empresa implicados, además del rol de analista necesitamos un rol que tenga una visión global de toda la empresa: el arquitecto de aplicaciones.
Perfil mixto
El nombre concreto no es muy importante, ya que en cada empresa lo pueden llamar de varias maneras. La clave de la cuestión es que esta persona tiene que tener un perfil mixto que quizás sea más difícil de encontrar.
Por una lado debe de tener los conocimientos de orientación a servicios necesarios, tener claro los conceptos clave como los principios de SOA, los patrones de diseño a utilizar, etc. etc. pero también, por supuesto debe tener conocimiento de los requisitos de negocio.
Tiene que dar respuesta a las preguntas recurrentes en un proyecto SOA
Esta persona es la que tiene que responder a preguntas en principio sencillas, como ¿cuántos servicios hay que hacer? ¿este servicio ya existe? ¿como descompongo un requisito de negocio de alto nivel en varios servicios sencillos y un servicio compuesto que los orqueste?.
Si estamos en un proyecto grande, con varios departamentos implicados, esta persona tendrá que hilar muy fino para poner de acuerdo a todas las personas de cada departamento, donde cada uno puede tener sus propios intereses, prioridades, tiempo y presupuestos para hacer las cosas.
En un proyecto SOA, la suma total no es la suma de las partes. Quiero decir con esto que no podemos tomar cada departamento o grupo específico de una parte de la solución total, ya sea a nivel de negocio (el grupo de Clientes, de Recibos, de Préstamos, etc. etc.) o a nivel técnico (el equipo de servidores de aplicaciones, de bases de datos, de gestión documental, etc.) como si fueran conjuntos disjuntos, en el que el límite del fin del ámbito de un grupo marca el inicio del ámbito de otro grupo.
Precisamente, el arquitecto de aplicaciones tiene que extender su ámbito, no a un grupo concreto, si no a todo el proyecto. Es él el que tiene que estar por “encima” de estos grupos, coordinándolos, dirigiéndoles al objetivo de dar solución a un requerimiento de negocio mediante un arquitectura orientada a servicios, el que tiene que velar por la cooperación de todas las partes:
Proyecto total = Suma de las partes + arquitecto de aplicaciones
Ya pero… ¿quién hace este servicio?
Así podremos dar respuesta prontamente a la pregunta más temida en un proyecto ¿quién hace este servicio compuesto? ¿quién tiene que emplear su tiempo y su dinero en crear un proyecto que no es de ningún departamento en particular sino que tiene un poco de cada uno?
Parece una pregunta trivial, pero su respuesta puede llevar fácilmente días o incluso semanas… la única solución como digo, es tener un arquitecto de aplicaciones en el proyecto, con un perfil mixto, y por supuesto, con la suficiente autoridad para dar sus directrices al resto de participantes del proyecto.
Me gusta esto:
Me gusta Cargando...
Blog de Andrés Hevia 
08/12/2015 at 15:11
Entiendo entonces que el Arquitecto de aplicaciones es como una leyenda urbana 😉 pero a la vez muy util…