Aca escribo un poco de lo que estuve viendo.
- La metodologia de IBM SOMA
- La de Thomas Erl (la mejorcita) MSOAM y otro link de lo mismo
- Las de ciclo de vida de los servicios de BEA (que no me dejo mucho) y
- Las recomendadas por las SOA practitioners guide
En fin, parece que para el analisis y la entrega de servicios en una metodologia SOA existen dos caminos posibles. TOP-DOWN y BOTTOM-UP. Pueden verlos aqui
Cuando lo lei, asocie la forma de delivery BOTTOM-UP a la forma de analisis orientada a la necesidad actual cuando los requerimientos provienen de sistemas legacy y los procesos de negocio no estan definidos; y la TOP-DOWN, cuando se parte del analisis basado en entidades de negocio, procesos de negocio y demas descomposiciones, que se pueden ver aqui
Igual, se debe tener en claro que todo el proceso tendera tarde o temprano a ser un TOP-DOWN, de lo contrario no se llegara a una Arquitectura SOA ideal, donde IT este alineado al negocio.
Otra cosa que dice MSOAM es que el analista funcional debe trabajar en conjunto con el tecnico (aqui).
Con los analistas tecnicos deben trabajar si o si, ya que estos son los que conocen las restricciones tecnologicas, los patrones de diseño y podran modelar los servicios de manera acorde a los estandares empresariales. Un analista funcional no podra modelar las entradas, salidas y capacidades de un servicio por si mismo; especialmente hoy en dia, que la vision orientada a servicios es escaza.
Cuando se habla de analistas funcionales son analistas cross al negocio. Eso quiere decir que el analista no debe conocer UNA aplicacion o UN proceso de negocio, sino meterse en todos los procesos y conocer un poco de tooooodo IT en la empresa.
Es por eso que el analista SOA debe trabajar (o consultar antes de definir, al menos) con la gente que modela y documenta los procesos de negocio.
El ciclo de vida de servicios debe estar bien definido y se deben formalizar los pasos para la creacion, eliminacion o modificacion de un servicio, como tambien los pedidos para su consumicion. Sin esto, no se podran generar politicas adecuadas para el repositorio...
Para un correcto analisis, se debe poseer un repositorio de entidades de negocio y de servicios Y con un proceso de GOVERNANCE bien definido es fundamental.
La existencia del repositorio y la definicion de la metadata de cada servicio sera lo que permita modelarlos y centralizar la informacion de servicios en toda la empresa.
No se habla unicamente de UDDI, ya que este estandar es limitado. Se habla de un repositorio a nivel de analisis y diseño, que permita automatizar el proceso de modelado y descubrimiento de servicios, como tambien asi su aprobacion por parte de la SOA BOARD (que sera el sector/comision/grupo de sectore que tendran el governance de los servicios en la empresa y definiran los estandares).
El proceso de Governance debe estar bien definido, y los estandares y modelado de negocio tambien. Aqui hay un articulo sobre la importancia del governance
La metodologia de analisis debe ser iterativa!!!! no se debe querer relevar tooooooda la informacion de tooooooodos los procesos para comenzar a definir servicios que sean reutilizables.
Los servicios son altamente modificables y apuntan a la reutilizacion, por lo que se debe analizar por partes a los procesos de negocio/procesos de la empresa para poder entregar los primeros servicios. Luego, estos se iran modificando con la aparicion de nuevos requerimientos, para eso se definio un repositorio y un ciclo de vida de servicios.
Con los links y la metodologia en si, hay bastante para profundizar. SOA Es una metodologia que sigue cambiando y que cada consultor hace, hoy en dia, como mas le parece.
Es importante tener una metodologia de analisis que se ajuste a las necesidades de la empresa, dependiendo su grado de madurez (me gusta la piramide de ese link, es muy clara). El grado 3 de madurez, es el mas dificil de lograr, el resto sale con fritas.
Saludos.
