domingo, 23 de marzo de 2014

97 Cosas que un Arquitecto de Software Debe Conocer - Parte 7

Y llegamos a la última parte. Parecía que este día no iba a llegar, pero llegó. Desde mitad del año pasado vengo resumiendo y publicando el conjunto de principios y buenas prácticas de este compendio portentoso que O'Reilly Media ha decidido llamar 97 Things Every Software Architect Should Know.

El libro forma parte de una familia de libros llamados 97 Things Every XXX Should Know. Y hay de Project Manager, de Arquitecto de Software y de Programador, por lo menos hasta donde yo sé. Hace poco les conté que existe un sitio que está traduciendo al español todos estos compendios de 97 Things. Este sitio es 97cosas.com y ya tiene completamente traducido el 97 Things para Programadores.

Hoy se completa mi resumen de 97 Cosas que un Arquitecto de Software Debe Conocer. 97 principios en 7 posts.

Para consultar los posts anteriores:
Pasemos a hablar de los últimos 13 principios:
  1. Crea un Caso Fuerte de Negocio: Las personas que tienen la autoridad presupuestaria para patrocinar tus ideas son casi siempre gente orientada al negocio. Por eso, a la hora de comunicar tu arquitectura es importante: 1) Establecer la propuesta de valor: el resumen ejecutivo de por qué este negocio específico garantiza una arquitectura de software en particular, 2) Construir métricas para cuantificar: que respalden con números de negocio la arquitectura propuesta, 3) Volver a las medidas tradicionales de negocio: sería ideal poder traducir tu análisis técnico en dólares, ¿no?, 4) Saber cuándo parar: prepara una hoja de ruta (roadmap) que capture una visión en cada hito (milestone) que esté directamente relacionada con los valores del negocio y deje que los interesados (stakeholders) decidan cuándo parar; si el valor de negocio de cada hito es significativo, será más probable que consigas financiamiento continuo, 5) Encontrar el momento adecuado: puedes tener el modelo de negocio más brillante entre manos, pero de nada servirá si lo presentas en un mal momento.


  2. Patología de Patrones: Es muy tentador querer mostrar nuestra destreza arquitectónica lanzando una pila de patrones de diseño. El problema está cuando quieres encajar un patrón a la fuerza a un problema que no aplica. Como todas las herramientas, los patrones de diseño pueden ser mal utilizados. ¡Ten cuidado de no caer en la sobre-ingeniería! Es nuestro trabajo identificar los problemas que resuelven cada patrón y aplicarlos adecuadamente. ¡KISS!

  3. Aprende un Nuevo Lenguaje: Sabes hablar lenguaje de programador. ¡Muy bien! Ahora aprende lo básico de lenguaje de negocios y de testing. Aprender distintos lenguajes no solucionará todos los problemas, pero ayudará a prevenir la falta de comunicación y los malentendidos que conducen a los problemas. Difícilmente puedas ser un puente entre el negocio y el desarrollo de software si no sabes hablar ambos idiomas.

  4. No seas Astuto: La inteligencia general, la creatividad, el ingenio, la amplitud y profundidad de conocimientos, son cualidades apreciadas en los arquitectos de software. Sin embargo, la astucia implica la capacidad de concebir una solución que pueda sacarte de un apuro de forma rápida, pero que implica en última instancia un truco. El software astuto es caro, difícil de mantener y quebradizo. Sé tan tonto como te sea posible para poder crear el diseño apropiado. Si la astucia parece absolutamente necesaria, probablemente el problema esté incorrectamente definido. ¡Redefínelo! Es nuestra astucia lo que nos permite lograr que software engañoso quede funcionando. Las soluciones tontas siempre serán más fáciles de implementar. Una vez más: ¡KISS!

  5. Construye Sistemas para ser Zuhanden (manejables): Construimos herramientas, y las herramientas no son más que un medio para obtener un fin. Las herramientas se experimentan directamente, sin teorización. Cuando las usamos, desaparecen, se convierten en una extensión de nuestros cuerpos; no pensamos en ellas, pensamos en lo que estamos haciendo con ellas. Como tecnólogos, experimentamos los sistemas que construimos como un fin (no como los usuarios, que para ellos es un medio). Para nosotros, el software es un objeto de estudio. Sin embargo, es crucial que los usuarios experimenten el software que hacemos como herramientas invisibles, herramientas manejables que faciliten su trabajo (zuhanden).


  6. Encuentra y Retiene a Apasionados Solucionadores de Problemas: Armar el dream team de desarrolladores y mantenerlo unido es una de las tareas más importantes del arquitecto para asegurar el éxito de un proyecto de software. Busca desarrolladores que además de los conocimientos técnicos necesarios, tengan pasión por resolver problemas. Las herramientas cambiarán con el tiempo. Necesitarás desarrolladores que diagnostiquen problemas de rendimiento, que resuelvan problemas sin depender de las herramientas. En las entrevistas, pregúntales qué cambiarían de su proyecto anterior si tuvieran que empezar de nuevo. Los buenos desarrolladores son en general motivados por el reconocimiento. No pierdas oportunidades para levantar su moral si se lo merecen. La importancia de preservar a los buenos desarrolladores nunca debe ser infravalorada.

  7. El Software no existe Realmente: No es realista asumir que puedes implementar un diseño de la misma forma en que lo hacen las ingenierías más tradicionales. El software no es tangible como un edificio. Tanto los negocios como el software son entidades vivas en movimiento. Se suele decir que las decisiones de arquitectura de software son difíciles de cambiar, pero no tanto como mover la ubicación de un puente en medio de su construcción. Esto hace que la planificación no pueda ser tan rígida y que no haya un orden único de implementación que asegure minimizar los riesgos. Recuerda que un documento de requerimientos no es un plano y que el software es una entidad cambiante e intangible.

  8. Pague su Deuda Técnica: La ruta "rápida y sucia" para solucionar bugs o implementar nuevas funcionalidades genera deuda técnica. Pagar esa deuda mañana significa volver al problema original y solucionarlo de la forma en que se debería haber solucionado si hubieras tenido el tiempo y los recursos para hacerlo bien la primera vez. Las deudas técnicas tienen costos ocultos, intereses que se materializan en inestabilidad del sistema, aumento en el costo de mantenimiento, diseño, documentación, testing. A veces tiene sentido meter un cambio ASAP, sobre todo cuando el sistema está en producción, pero debes comprometerte a pagar tu deuda una vez que pasó la urgencia. De lo contrario, los intereses terminarán destruyendo el proyecto.


  9. No Puedes Ofrecer Soluciones a Prueba de Futuros: Las soluciones de hoy son los problemas de mañana. Nadie puede predecir el futuro. Hay arquitectos que tratan de diseñar los sistemas "a prueba de futuros"; sin embargo, todas las decisiones se volverán obsoletas eventualmente. El lenguaje de programación cool que usas eventualmente se convertirá en el COBOL de mañana. Elige las mejores soluciones que se ajusten a las necesidades de hoy. No caigas en la parálisis del análisis.

  10. El Problema de la Aceptación del Usuario: Los usuarios no siempre están contentos con los nuevos sistemas o las mejoras importantes. Como arquitecto debes estar consciente de este problema y considerar las razones, que pueden ser: miedo a perder funcionalidades que tenían en el sistema anterior, miedo a perder poder en un cambio de roles, miedo a nuevas tecnologías todavía no probadas, preocupación sobre los costos del nuevo sistema, o incluso la sencilla razón de que a las personas no le gustan los cambios. Comienza temprano a mitigar estos miedos: discute con los usuarios finales sobre las ventajas y desventajas de las nuevas funcionalidades, planifica capacitaciones y demos en etapas tempranas. Hazlos parte del proyecto compartiendo el nuevo conocimiento.

  11. La Importancia del Consomé: El consomé es un caldo que, bien hecho, debería ser muy claro. Se considera todo un desafío hacer un buen consomé, bien bien claro, porque sólo hay una manera de eliminar los sólidos y es con mucho esfuerzo y refinamiento. La arquitectura de software requiere un refinamiento continuo de pensamientos: ¿qué significan estas propiedades?, ¿y estas relaciones?, ¿cómo podemos hacer más explícito este concepto? Aclaramos nuestros conceptos para que las relaciones dentro de la arquitectura sean verificables e internamente consistentes, refinamos los requerimientos con precisión quirúrgica para eliminar la redundancia, la ambigüedad, las suposiciones injustificadas. Los conceptos son pasados una y otra vez por un tamiz para clarificarlos lo más posible.


  12. Para el Usuario Final, la Interfaz es el Sistema: Existen demasiados buenos productos escondidos detrás de malas interfaces de usuario (UI). Si la calidad de la experiencia de usuario (UX) sufre, la impresión del usuario sobre el producto también va a sufrir. Debes contratar a los mejores especialistas en UI y UX desde etapas tempranas del proyecto para que acompañen durante todo el desarrollo. La usabilidad es uno de los requerimientos no funcionales que más conciernen al arquitecto de software. La interacción del usuario con el sistema debe ser un factor fundamental para las decisiones de diseño y arquitectura. Los cambios en la UI deben ser documentados de la misma forma que los cambios en el código. Sobre este tema, recomiendo leer el siguiente artículo: La Interfaz de Usuario es la Aplicación, por Jeff Atwood.

  13. El Gran Software no se Construye, se Cultiva: Arquitecturas grandes llevan a proyectos grandes, más propensos a fallar, más difíciles de probar, más frágiles, con mayor complejidad incidental, inercia y componentes innecesarios. Resiste la tentación de querer diseñar todo el sistema al comienzo. Tener una gran visión y un diseño simple te ayudará a ser flexible. Comienza con una pequeña arquitectura ejecutable, lo más simple posible, que satisfaga los requerimientos fundamentales, y luego deja que evolucione. Hazla testeable desde el día cero. Mantén bajo el nivel de acoplamiento entre componentes cada día. Despliega continuamente en producción, desde el día en que tengas esta semilla. Aprende de los errores cuando son pequeños y su solución casi trivial. En estos principios se basan los conceptos de Arquitectura Evolutiva y Diseño Emergente.
Y con esto llegamos al final de esta serie de posts. La Arquitectura de Software es una disciplina muy joven; incluso dentro del joven mundo del software. Queda mucho por debatir, mucho para aprender. Los roles en un proyecto de desarrollo de software todavía están confusos. Hay varias escuelas de pensamiento y varias generaciones viviendo en el ecosistema de las empresas, y las descripciones de los roles pueden variar de proyecto en proyecto. El año pasado escribí un poco sobre esto en el post Sobre Arquitecturas y Arquitectos, donde hablo incluso de distintos tipos de Arquitectos dentro de la disciplina de sistemas.

Si llegaron hasta aquí y les interesó esta serie de posts, probablemente también les interese leer acerca de los principios o axiomas que no entraron en el libro 97 Cosas que un Arquitecto de Software Debe Conocer pero que sí las incluyeron en su página web: Otras Cosas que un Arquitecto de Software Debe Conocer.