¿La solución para plazos delicados? Arquitectura sencilla.

El Coding The Architecture London User Group ha publicado su primer podcast (slides)., que con un poco de suerte será el primero de una larga lista.

Es un podcast bastante interesante, ya que se trataba de exponer un caso práctico de un proyecto y como escogieron su arquitectura, aunque la calidad del audio no es demasiado buena. En ella hablan de un proyecto para desarrollar un sistema de análisis de riesgos que tuvieron hace unos meses para un banco de inversiones en Londres y que estaba programado para realizarse en 4 semanas. Sin embargo, tanto los requisitos no funcionales, no ya en cuanto a carga, si no más bien en cuanto a seguridad, como los funcionales ya que la lógica de el análisis de riesgos era bastante compleja, hacían que el proyecto fuese totalmente inabordable.

Después de duras discusiones, la solución fue adaptar la solución al márgen de tiempo disponible. Se encontró que para lo que realmente quería el banco era más que suficiente con prescindir del 90% de la lógica de análisis de riesgos y tener un sistema que más bien diese pistas sobre anómalias en lugar de algo 100% fiable; que no era necesario utilizar un potente servidor de aplicaciones sino que con un stack basado en Tomcat y Spring era más que suficiente; que a veces hay que dejar también tecnologías que en un principio son buena idea, como Hibernate o Maven, ya que el proyecto es lo suficientemente pequeño, y los plazos suficientemente ajustados, para que no tengan tanto sentido; o que muchas veces el cliente dispone ya de las herramientas para cubrir requisitos no funcionales, como en este caso el Veritas Cluster Server, y se pueden aprovechar también en lugar de ponernos nosotros a reimplementarlas.

La aproximación que siguieron para solucionar el problema es también bastante interesante. En lugar de rendirse al cliente y aceptar sus exigencias, apostando por la venta fácil y la entrega con retrasos, lo que se hizo fue la opción honesta que es ofrecer una solución adecuada pero con los plazos que se consideraban indispensables: en este caso seis meses. El cliente se da cuenta de la magnitud del proyecto y aceptan reducir funcionalidad. El proveedor de servicios se da cuenta de las necesidades inmediatas del cliente y aceptan prescindir de ciertas soluciones innecesarias.

En resumen un acuerdo entre ambas partes para reducir el espectro del proyecto que resulta en un final feliz. ¿Tenéis alguna historia similar?