Cuando uno está diseñando una arquitectura software hay una parte siempre difícil: la de la toma de decisiones, el valorar los trade-offs y decidir qué dejas a un lado y por qué apuestas. Todos sabemos que por buena que sea la idea siempre tendrá algún aspecto negativo a considerar: quizás un mayor coste, una mayor complejidad de implementación, o un riesgo alto al apostar por una tecnología no tan probada.
Problemas siempre habrá y alguien se encargará de recordártelos cuando empiecen a dejarse notar. Todos se acordarán de ti cuando se le empiecen a ver las orejas al lobo.
Pero el problema de verdad no está en los diagramas, en los planos y diseños, está justo después de eso. Cuando hay que llevarlo a la práctica, cuando alguien tiene que abrir el Visual Studio y convertir en líneas de código contantes y sonantes eso que para ti eran solo un par de flechitas en un Powerpoint. Ahí hay un verdadero riesgo de fracasar: nadie mantiene las decisiones arquitectónicas, nadie tiene en la cabeza todo el diagrama, y los apaños, o el «yo pensé que podíamos resolverlo de esta otra forma», van tomando cuerpo y reemplazando tu bonito blueprint.
Vas a tener que registrar las decisiones más importantes en los ADR, y revisarlos con frecuencia. Adaptarlos para lograr que sobrevivan al contraste con la realidad, y vigilar el coste de cambiar de rumbo. Ten siempre presente qué decisiones son reversibles y cuáles no.
Pero ante todo, comunica siempre los pros y los contras. Necesitarás que se suban a tu barco, y entiendan por qué se tomaron esas decisiones, para que no empiecen a remolonear cuando la mar pinte fea.
