¿Cómo tomar decisiones de arquitectura? Definiendo y ordenando objetivos

En cualquier proyecto de software que vaya más allá de una prueba de concepto o demostración, necesitaremos una organización racional del trabajo. Tendremos que esforzarnos en buscar patrones repetibles para agilizar futuros procesos y debemos armarnos con criterios duraderos para tomar decisiones coherentes a lo largo del ciclo de vida del proyecto. Esto es, lo que en el mundo de la arquitectura del software, llamamos una metodología. Pero, ¿cómo optar por una u otra? ¿Cómo decidir si adherirnos o no a un determinado estándar? ¿Cómo determinar el nivel adecuado para formalizar más o menos el andamiaje de la solución? ¿Está la metodología contraviniendo la agilidad en el desarrollo? En definitiva, ¿qué criterios seguir para tomar decisiones?.

Las respuestas a estas preguntas estarán condicionadas por las prioridades que otorguemos a los objetivos que nos marquemos al definir nuestra arquitectura del software. En mi credo aparecen objetivos que a todos os resultarán familiares y difícilmente podemos prescindir de alguno de ellos. Pero la cuestión es que, ante una situación de escasez de recursos para hacer frente a todos ellos como se merecen, ¿cuál es la prioridad? ¿se pueden ordenar estos sagrados objetivos?. Para el caso de pequeñas consultoras, o startups creando su primer producto propongo esta lista ordenada

Agilidad en el desarrollo, para fomentar la productividad y aceptar cambios en la funcionalidad sin traumas.
Funcionalidad Básica, para poder ser evaluada cuanto antes, y que además sirva de revulsivo o pequeño quick-win.
Fiabilidad en la ejecución. Es mejor que haga poco, pero bien, pues la desconfianza una vez instaurada es muy difícil de erradicar.
Mantenimiento operativo y correctivo: programar con el usuario, pero también con el operador y futuros programadores en mente.
Extensibilidad de la funcionalidad, ya que la hemos reducido inicialmente debemos ser muy precavidos para dejar puntos de extensibilidad suficientes.
Adaptabilidad sin compilación. Ficheros de configuración, parametrizaciones, técnicas de inyección de código, cualquier posibilidad de mejora? sin recompilar y redistribuir el proyecto principal.
Funcionalidad completa. La competencia y las demandas de los clientes no tienen límite, debemos completar la aplicación agregando módulos a buen ritmo.
Seguridad de la información. Según el sector de destino, este puede ser un punto crucial que avance posiciones.
Velocidad en la ejecución. Optimizar los tiempos totales y sobre todo los percibidos por el usuario.
Coste total. Resumen y colofón de todo lo anterior. ¿Cuánto me cuesta producir el programa de esta forma? ¿Me saldría más barata otra tecnología?

A lo largo de mi experiencia profesional me he encontrado con proyectos de mayor o menor calado, pero todos se han visto afectados por los anteriores factores. Esta suerte de mandamientos en mi experiencia constituyen la clave del éxito de los desarrollos de multitud de proyectos.

Creo que cualquier metodología ante todo debe ser ágil para no entorpecer la productividad de la empresa, y permitirle alcanzar una funcionalidad básica que pueda ser apreciada y validada por el destinatario del software, el cliente. Si esto no se produce, el proyecto en sí puede desaparecer. Un equipo de desarrollo lento o una metodología engorrosa son un factor decisivo hacia el fracaso.

Para continuar debemos pensar en corregir, completar y adaptar el software hasta satisfacer las necesidades del usuario. Si los primeros objetivos se han cumplido deberíamos suplir las carencias del piloto con facilidad, y haciendo entregas continuas ganarnos la confianza del usuario que verá como día a día evoluciona el producto. La seguridad debe implantarse de forma gradual y supeditada a los criterios principales de agilidad y mantenimiento. Esto lo digo ahora que ningún administrador de sistemas nos oye…

No priorizo la velocidad, pues no soy amigo de optimizaciones tempranas que puedan retrasar el nacimiento del proyecto. Prefiero métricas reales y atacar los cuellos de botella que se detecten con el uso, favoreciendo siempre la sensación de velocidad del usuario.

Por último el coste del proyecto, entendido este como la suma de los factores productivos clásicos (maquinaria y mano de obra), el mantenimiento futuro, y la imagen final (plataforma de despliegue…). Realmente la consideración del coste está implícita en cada decisión tomada, si no eres tú el que te juegas tu dinero, alguien habrá que lo haga, y te recordará vía presupuesto cuál es tu cajón de arena para jugar.

Como reflexión diré que cualquier metodología debe ser tomada como una guía y no como una ley estricta, máxime cuando todos los objetivos reseñados son vitales. Estar abiertos a cambios, ser permeables al conocimiento y abusar del sentido común, os permitirá ordenar vuestros objetivos en cada proyecto, y con ello tomar decisiones adecuada y coherentemente.