businessmen-530331_640

Cuando queremos iniciar un proyecto de SOA, una de las preguntas más recurrentes es “¿Por donde empiezo?“.

El enfoque clásico para empezar es seguir una estrategia de descomposición top-down o al revés, bottom-up. Sin embargo, en un proyecto grande, no siempre está esto tan claro. Aquí puedes ver una entrada en el que hablo de esto.

Pero en esta ocasión quiero hablar de un problema que aparece en los grandes proyectos y, por verlo gráficamente, no me estoy refiriendo ahora a ver el proyecto “a lo alto” (de arriba a abajo o viceversa). Me estoy refiriendo a verlo a lo ancho. A lo que pinto en el siguiente diagrama como “área”.

Captura de pantalla 2015-02-15 a las 14.40.40

Si pensamos en un proyecto muy grande, con varias decenas de personas implicadas y en el que es necesario avanzar por fases. Los más habitual es partirlo en varios bloques funcionales.

En el gráfico he pintado lo que podría ser una descomposición de un proyecto SOA en un banco, con varios módulos funcionales como son Clientes, Préstamos, Tarjetas y Cuentas.

Y es que cuando tenemos varios módulos funcionales, esto se complica. ¿Debemos empezar por uno de estos módulos y luego continuar con los otros? o empezamos por abajo de una manera  cross por todos los módulos.

A lo Ancho

El primer enfoque consistiría en coger todo “lo ancho” del proyecto, es decir, todos los bloques funcionales y empezar en una dirección, desde arriba o desde abajo. En este caso, por ejemplo en el enfoque bottom-up iremos descubriendo todos los servicios básicos, de negocio, necesarios para ir implementando la funcionalidad.

Sin embargo, esto tiene el problema de que al tener tanta “superficie” que tratar, con seguridad empezaremos a tener decenas o cientos de servicios básicos que todavía no se pueden usar realmente, es decir, no podemos tener nada útil en producción. Digo esto, porque para hacer disponible una funcionalidad al usuario necesitemos los servicios de alto nivel, los de arriba y no tendremos ninguno porque estaremos inmersos en la base.

A lo Alto

El otro enfoque, consistiría en coger un sólo módulo, es decir, limitar el “ancho” de nuestro enfoque y empezar a crear servicios en esta área más reducida. Al tener menos superficie que trabajar tendremos servicios que el usuario pueda utilizar en una fase más temprana.

Sin embargo, el inconveniente de esto es que no hay un módulo 100% aislado del resto. Con toda seguridad, para ir complementando los servicios de nuestro módulo necesitaremos servicios del resto. Servicios que no tendremos porque nadie se está ocupando del resto de los módulos… ¿qué hacer en esta situación?

Esta es la gran pregunta. Y aquí algunas de las respuestas que se pueden ver. Por desgracia, no necesariamente son buenas:

  1. A medida que vamos descubriendo servicios de otro bloque funcional que necesitamos, que haga el servicio el primero que lo necesita, aunque no sea suyo.
    Esto implica obviamente que un equipo de “Cuentas” haría, por ejemplo, servicios de “Clientes”… es fácil de imaginar el problema de gestión y de falta de conocimientos funcionales que esto puede provocar.
  2. Yo lo hago y luego el propietario de verdad lo hará de nuevo y yo tiraré el mío.
    Es decir, yo hago un servicio “provisional” para sacarme las castañas del fuego y luego ya vendrá su “legítimo propietario” a hacer el de verdad, el definitivo.
    Más gasto y por supuesto, un problema cuando haya que reemplazar el servicio provisional por el definitivo. Casi seguro que el contrato tiene que cambiar porque se habrá hecho un servicio que cubra las necesidades del que lo necesitaba pero no el “interés general” de la empresa.
  3. Vamos a definir los contratos de los servicios pero hacemos servicios dummy.
    Esto quedaría a medio camino, es decir, no se implementan realmente los servicios pero si se define su contrato (el que sería definitivo) e incluso se hacen unos servicios dummies para que se puedan hacer pruebas de integración.
    Esto implica más tiempo y dinero porque no sólo estamos abordando un bloque funcional sino que realmente estamos “analizando” todos ellos (todos los que se vayan necesitando).

Podemos pensar que la opción más cabal sería la tercera. Pero como siempre, no siempre se puede hacer en un proyecto lo que se quiera, hay que ajustarse a lo que se puede hacer. Un problema difícil sin duda.