tutor-407361_640

En la teoría de Thomas Erl y compañía, acerca de SOA, se menciona lo que podrían ser las fases por las que tendría que pasar un proyecto orientado a servicios. Son estas, y son (creo) autoexplicativas….

  1. Análisis de inventario de servicios
  2. Análisis orientado a servicios (Service Modeling)
  3. Diseño orientado a servicios (Service Contract)
  4. Diseño de la lógica de servicios
  5. Desarrollo del servicio
  6. Test del servicio
  7. Despliegue y mantenimiento del servicio
  8. Descubrimiento del servicio

Una vez definidas las fases, creo que lo importante (por la novedad en SOA respecto a otros paradigmas), son los roles. Obviamente en cada una de estas fases tienen que intervenir uno o varios de estos roles o perfiles de profesionales para completarla. Es importante recordar que los roles no son personas, es decir, que una misma persona puede desempeñar varios de estos.

La definición de cada rol, a veces, puede no estar muy clara. De todas maneras es cada empresa la que tiene que establecer una definición clara de cada uno, y sobre todo, de qué es responsable cada rol y qué tiene que hacer. No hay nada peor en una empresa que no esté muy claro quien tiene que hacer qué, y quizás peor, cuando las responsabilidades de varios roles están solapadas. Aquí corremos el riesgo de una “lucha” continua de ámbito de  competencias o que nadie haga una tarea al ser de “todos” y no ser de nadie.
Así pues, y según el gurú de SOA Thomas Erl, los roles presentes en SOA, por supuesto con mis comentarios, son los siguientes:

Roles:

Analista de servicios

Es el perfil más orientado a servicios. Digamos que este rol debe saber más de negocio que de SOA, y casi nada de tecnología. Por supuesto, debería conocer los ocho principios de SOA y no estaría de más que entienda los fundamentos de la implementación de servicios que se tiene en la empresa (como servicios web o REST).En esto ayudaría por ejemplo, establecer una comparativa clara y sencilla entre la implementación de SOA y cualquier otra implementación que ya conozca previamente. Por ejemplo, la diferencia entre SOA y una implementación procedural u orientada a componentes.

Arquitecto de servicios

En los últimos tiempos se está usando la palabra “arquitecto” para denominar todo tipo de perfiles y cometidos y esto ha dado lugar a un poco de confusión. Teniendo esto en cuenta, os comentaré mi particular definición sobre esto. Según mi criterio, un arquitecto de servicios debe ser una persona que no trabaja para ningún proyecto en concreto. Es decir, tiene que estar por encima de los proyectos y trabajar en el ámbito de toda la empresa. Debería velar por ejemplo, por que los servicios sean realmente reutilizables, que no se hagan dos veces (o más) un mismo servicio, etc, etc…

Custodio de los estándares de diseño de la empresa

Si lo traducimos, quiere decir a la persona que tiene que garantizar la aplicación de las directrices de diseño de la empresa.

Especialista en seguridad

En algunas empresas, el acceso por servicios web o REST, es un nuevo frente de posibles ataques al que no estaban habituados. Hasta ahora se tenía mayormente aplicaciones web con pantallas. Los servicios web, sin embargo, pueden ser una puerta de entrada al exponer, por ejemplo, servicios de Core a otras empresas vía internet. Es importante tener esto en cuenta por lo tanto… Aunque claro que como todo tiene que haber un término medio entre la seguridad (la seguridad total no existe) y el coste de implementar esta seguridad para no caer en lo que podemos definir como “la parálisis por la seguridad”.

Custodio del schema

Es el perfil análogo al de modelo de datos de las bases de datos. Es decir, tiene que gestionar el modelo de datos que usan los servicios, intentando establecer un dominio de lenguaje común en el dominio o empresa…

Custodio de las políticas

Es el rol encargado de mantener las políticas de manera accesible por el resto de la empresa. Es una cuestión obvia, pero se necesita una herramienta que permita estas consultas.

Especialista técnico en comunicaciones

Yo lo ampliaría quizás al especialista en escalabilidad y rendimiento. Únicamente como experto en las comunicaciones me parece un poco corto.Si tenemos éxito con SOA y disponemos de un conjunto mínimo de servicios agnósticos y muy reutilizables, tendremos algunos problemas con el rendimiento y dimensionamiento de la plataforma.Además, hay que tener en cuenta que cada “flecha” o “salto” que vemos en un diagrama de llamadas en SOA, significa (seguramente) que vamos a hacer una llamada por HTTP con lo que eso conlleva para el rendimiento del sistema

Especialista en QA

Además de lo que podemos entender como un especialista en pruebas y calidad, hay que tener en cuenta que en SOA tenemos un escenario que no tememos en las aplicaciones silo: me refiero a la interdependencia entre servicios.Es necesario, imprescindible, tener una política de creación de servicios dummies o mejor aún, una virtualización de servicios que permitan a los equipos de desarrollo probar sus aplicaciones sin depender del resto de servicios de otros equipos. Ver esta entrada sobre virtualización de servicios para que veáis lo que quiero decir.

Especialista en gobernanza

Efectivamente, es necesario tener un rol específico que se encargue de la gobernanza de los servicios. Quizás este rol lo pueda desempeñar la misma persona que el arquitecto de servicios.

En definitiva, y al margen de los roles que tengamos en SOA, creo que lo importante es ver que hay muchas tareas nuevas que nos trae la implantación de la orientación a servicios y debemos tenerlas en cuenta.

Anuncios