Arquitectura y Aplicación: el Huevo y la Gallina

 Éste,  podría entenderse a priori como un artículo de arquitectura de software, pero en realidad está más ligado a la administración de proyectos que a aspectos técnicos de arquitectura como tal

Semanas atrás, almorzando con dos viejos compañeros de un trabajo anterior, me comentaban de la implementación de un proyecto en el que ambos participaban. El proyecto consistía en un ambicioso cambio de arquitectura de una aplicación central (y de misión crítica, esto es: sin ella la organización ve seriamente afectada su capacidad de ejecución)

En lo que me comentaban, el desarrollo se había organizado en dos grandes grupos paralelos. Uno para implementar la arquitectura de la solución y el otro para implementar los servicios de nivel de aplicación. Entendamos, en este contexto, "arquitectura" como "infraestructura lógica", servicios de bajo nivel o "de granularidad fina", de los que se iban a nutrir los servicios de alto nivel del otro equipo
Para no darle demasiada vuelta, la arquitectura le iba a brindar servicios a la capa de aplicación
Pero según me comentaban, mientras los equipos trabajaron en forma aislada la cosa anduvo aceptablemente bien. Pero al llegar el gran momento de juntar las piezas, quedaron en relieve gruesas inconsistencias que obligaron a revisar todos los puntos de contacto entre la arquitectura base y la capa de aplicación. Cada redefinición de interacción obligó a hacer cambios en varias partes del código (parámetros de interacción no contemplados, etc)
En balance, sienten que están demasiado lejos de implementar dado que aún no logran cerrar todo el esquema de interacción entre capas, y cada modificación obliga a revisar extensas porciones de código. Según uno de ellos, lo que falló fue haber trabajado en paralelo, en arquitectura y en servicios de alto nivel. A su juicio había que haber cerrado toda la arquitectura primero antes de comenzar con los servicios. Discrepo con su argumento y por eso me sentí motivado a escribir mis razones

 

Por qué Arquitectura primero no
En otros proyectos en los que trabajé, se había dedicado un tiempo sustancial a construir arquitectura unicamente (código, no diseño). Lógicamente esto ocasionaba permanente malestar tanto en las áreas usuarias (especialmente las gerencias usuarias) como en la misma gerencia de Sistemas. El origen del malestar es el hecho de que la arquitectura por sí misma no aporta valor al negocio sino en la medida en que abarata la construcción de los servicios de alto nivel (encapsulando la lógica compleja en componentes reusables, ayudando consecuentemente a disminuir el expertise necesario para hacer lógica de negocio)
Soy el primero en reconocer esta virtud de las arquitecturas, de hecho no habría dedicado tantos años de mi vida a estudiar arquitecturas de referencia, patrones, buenas prácticas, etc. Pero también voy a ser el primero en asumir que es muy difícil explicar tanto las arquitecturas como sus ventajas a usuarios no técnicos. Y especialmente convencerlos y dejarlos tranquilos de que todo marcha como se planeó
Otro riesgo al que nos exponemos en la modalidad "arquitectura primero" es que al no tener una aplicación cliente que nos sirva como mecanismo de validación y homologación estamos exponiéndonos a posponer demasiado la verificación de asumpciones: exactamente lo que pasó en este caso anecdótico que refería al comienzo. En otras palabras, haber dedicado mucho tiempo a una tarea exclusiva y que aún así haya sido en vano

 

Aplicación primero?
Metodologías ágiles como eXtreme Programming (XP) trabajan en gran medida construyendo servicios de aplicación exclusivamente (en realidad, construyendo user stories según la nomenclatura de esta metodología -no son servicios en sentido estricto sino características funcionales de la aplicación-). En una segunda etapa estas metodologías, por refactorización (refactoring), van convergiendo en una arquitectura que reduzca el código a mantener
XP tiene a favor que parte por satisfacer la necesidad del usuario. Al menos yo le veo como contra que descreo que las necesidades del negocio den tiempo luego para refactorizar el código (me suena conocida esa historia de "primero hagámoslo que funcione y después lo emprolijamos"). Aún si luego de implementar el primer release se dieron las condiciones para la refactorización, el costo de desarrollar el software en versión final puede ser realmente muy caro

 

Arquitectura y Aplicación en Simultáneo
En mi opinión esta es la alternativa menos mala, siempre que se practiquen las siguientes actividades (algunas de ellas tomadas del mismísimo XP que acabo de criticar):
  • Definir contratos primero (contract-first)
  • Integrar código frecuentemente
  • Implementar tempranamente uno o dos "cortes verticales" (vertical slices)
Contratos primero (contract-first)
Esta es una práctica frecuente y recomendada de las arquitecturas orientadas a servicios (service-oriented architectures o SOA). En la práctica, para aquellos que se vienen moviendo en orientación a objetos (OO), es algo más que definir las interfaces principales de interacción (atención: interfaces a nivel de objetos, no hablamos de interfaces de usuario). Es también, definir ciertas políticas respecto de estas interfaces (rango posible de valores de los datos de entrada, de los de salida) y quizás también definir algunas políticas de seguridad y/o encuadre transaccional

Que esta práctica sea insistentemente recomendada por quienes abogan por montar SOA no es casual: en SOA hablamos de servicios autónomos, desacoplados de sus consumidores, que evolucionan en forma separada, que encapsulan sus propios datos, que definen fronteras explícitas (dentro de las cuales tanto proveedor como consumidor pueden optar por la implementación que deséen). Y especialmente, donde lo único que comparten es el contrato de interacción: no los objetos ni sus atributos (lo que acoplaría improductivamente ambos estratos)
 
Integración frecuente
Esta es una práctica de eXtreme Programming y de otras metodologías ágiles (menciono a XP para no dejar la sensación de que voy en contra de esa metodología). Tiene por propósito anticipar errores de integración de componentes, derivados de interpretaciones conceptuales divergentes. En definitiva, intenta evitar que llegue "el gran momento de juntar las distintas componentes" haciendo que en todo momento sea ese gran momento
Intentar poner en práctica esta recomendación en forma manual es costoso. No obstante hay una oferta muy grande de herramientas para llevar todo el código a un repositorio compartido, hacer construcciones diarias, ejecutar en forma automática pruebas tanto unitarias como de aceptación (end-to-end), comunicar a los interesados de los fallos de integración de manera que lo sepan antes que nadie (dicho en otras palabras, que lo sepan antes de que los demás se enteren)

Sin hacer propaganda barata, Visual Studio 2005 Team System es un excelente acelerador para el montado de este esquema (aunque está restringido a la plataforma .NET: al menos out-of-box no contempla plataformas como J2EE aunque existen piezas de terceros en estos casos)

Esta práctica es requisito indispensable para poder ejecutar la práctica que sigue (fundamental)

 
Cortes verticales (vertical slices)
A modo de PoC (Prueba de Concepto o Proof of Concept) es que deberíamos tomar -en una forma sencilla- uno o dos casos testigo de aplicación, teniendo un esquema automatizado para poder probarlos rápidamente ante cualquier cambio en la lógica de las capas. Estas PoCs tienen que servirnos para revalidar nuestra arquitectura pero especialmente los contratos definidos entre las capas. Acá no me refiero solamente a los contratos entre la capa de aplicación y la arquitectura base: contratos entre el canal de interfaz de usuario y la capa de negocios, contratos entre la capa de negocios y las capas de acceso a datos y/o integración, etc

 

Conclusión
No digo que sea lo mejor. Digo que es lo menos malo. Gratis no sale (sobre todo montar inicialmente la infraestructura), pero el esquema de trabajo que planteo es tal que asume el paralelismo en los desarrollos como algo inevitable (deseable?). Intenta, entonces tomar salvaguardas por medio de estas prácticas, para mitigar efectos como el que motivaron la escritura de este artículo
Esta entrada fue publicada en Software Management. Guarda el enlace permanente.

Responder

Introduce tus datos o haz clic en un icono para iniciar sesión:

Logo de WordPress.com

Estás comentando usando tu cuenta de WordPress.com. Cerrar sesión / Cambiar )

Imagen de Twitter

Estás comentando usando tu cuenta de Twitter. Cerrar sesión / Cambiar )

Foto de Facebook

Estás comentando usando tu cuenta de Facebook. Cerrar sesión / Cambiar )

Google+ photo

Estás comentando usando tu cuenta de Google+. Cerrar sesión / Cambiar )

Conectando a %s