equipo de desarrollo

Si hay algo que se ve claramente a medida que participamos en el desarrollo de aplicaciones orientadas a servicios es que muchos de los típicos clichés que veníamos manejando hasta ahora, ya no valen.

Y uno de ellos es el modo de desarrollo de una aplicación, que típicamente consiste en:

  1. un frontend (o interfaz de usuario)
  2. un backend donde se ejecuta la lógica de negocio
  3. el acceso al repositorio de datos (normalmente una base de datos)

En un aplicación silo, va todo unido. La aplicación se diseña como si fuera la única que hay en el mundo (no es así del todo realmente pero casi) y por lo tanto lo que le interesa al programador de las pantallas es como llamar a la lógica de negocio y viceversa, al programador de la lógica de negocio le interesa que lo que devuelva le sirva al compañero para pintar la pantalla.

Por muy grande que sea el equipo de desarrollo este esquema se repite… todos los implicados pertenecen al mismo grupo, o al mismo proyecto, dentro de una planificación común y con los mismos intereses por acabar en las fechas previstas.

Pero ¿qué pasa con SOA?… pues que lo que podríamos ver como un esquema tradicional ya no sirve.

El frontal debe consumir servicios de negocio, estén donde estén y hayan sido hechos por quien haya sido hechos, tanto dentro como fuera de la empresa. Es cierto que si es un proyecto grande, en el mismo se implementarán pantallas y servicios pero, con toda seguridad, también necesitará servicios que ya estén hechos o se vayan a hacer por otros equipos y que no entran en su alcance.

Por otra parte, si hacemos servicios en el backend, como servicios reutilizables que son pasarán a formar parte del inventario de la empresa y otros frontales de otros proyectos los consumirán.

Así pues, si levantamos un poco la cabeza de nuestro propio proyecto, nos salimos de lo que es una aplicación silo y nos orientamos a servicios, tendremos lo siguiente:

  • “Nuestras” pantallas consumirán servicios “nuestros” y servicios de los demás
  • “Nuestros” servicios serán accedidos desde “nuestras” pantallas pero también por pantallas de “otros”

A la vista de esto, ¿Qué sentido tiene que un mismo equipo de desarrollo haga las pantallas y los servicios? ¿no sería mejor que a todos los efectos fueran dos equipos distintos? ¿Por qué van a tener más en común los desarrolladores del frontal con los desarroladores del backend que con cualquier otros desarrolladores del resto de la empresa?.

Por otra parte, y no es cosa de poca importancia, la separación total de ambos equipos nos servirá para evitar “vicios” y fomentar las buenas prácticas de respeto a los principios de SOA. ¿O es que alguien cree que si las pantallas y los servicios se hacen en el mismo equipo no se van a caer en “apaños” para atajar y ahorrarse tiempo y esfuerzo aún a costa de que los servicios no sean reutilizables?

En mi opinión, el frontend y el backend de una aplicación deberían considerarse proyectos independientes, relacionados por supuesto, pero independientes a todos los efectos, en la construcción y también en el análisis.