sábado, 10 de agosto de 2013

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

Sigamos con la serie de posts inspirados en el libro 97 Cosas que un Arquitecto de Software Debe Conocer. El que quiera refrescar la memoria sobre los primeros 15 principios puede visitar el primer post de la serie.
  1. No Puede haber más de Uno: Este principio ataca directamente a las raíces de DDD y a la utopía de SOA de concebir un único Modelo Canónico para toda la organización. ¿Por qué no enfrentar la realidad de un mundo desordenado y permitir múltiples, inconsistentes, superpuestas representaciones, servicios, soluciones? Tomemos como ejemplo el mundo de los data warehousing. El esquema de datos habitualmente está desnormalizado, los valores importados y calculados se mezclan arbitrariamente, y presentan una visión de los datos muy diferente de las bases de datos subyacentes. Distintos modelos de dominio pueden servir para representar el mismo negocio en distintos contextos, y siempre podremos contar con Traductores o Transformadores que nos sirvan para mapear las propiedades con la metadata apropiada.

  2. Unidades de Negocio: Los Arquitectos deben actuar como un puente entre el negocio y las comunidades tecnológicas de una organización. El ROI debe servir como guía importante a la hora de poner en una balanza el valor de una funcionalidad versus el costo de entrega de esa funcionalidad. La transparencia es crucial. El Arquitecto, junto con los Líderes de Proyecto, deben hacer visible el proceso de construcción del software. Para esto, técnicas como las de LeanKanban y/o Entrega Continua pueden ser muy útiles. El negocio debe guiar el desarrollo de software.

  3. Kanban Board

  4. Simplicidad antes que Generalización; Usar antes que Reutilizar: Cuando haya dos soluciones posibles, favorece siempre la más simple y la que resuelve de forma más concreta el problema. Aunque bien intencionados, a menudo los componentes que fueron diseñados para uso general terminan no satisfaciendo necesidades concretas. Los componentes de software deben ser diseñados principalmente para su uso y que cumplan bien ese uso. La generalización efectiva proviene de la comprensión, y la comprensión conduce a la simplicidad. Podemos encontrarnos con la generalidad y la flexibilidad tratando de ofrecer soluciones específicas.

  5. Los Arquitectos deben Poner Manos a la Obra: Sin una buena comprensión de la gama completa de tecnologías, un Arquitecto es poco más que un Project Manager. Es difícil imaginar cómo los integrantes del equipo pueden tener confianza en su Arquitecto si el Arquitecto no entiende la tecnología. Esto no quiere decir que un Arquitecto no pueda pedir ayuda al equipo. El equipo debe sentirse parte de la solución, pero el Arquitecto debe escuchar el debate e identificar la mejor solución. Los Arquitectos no están sentados en una Torre de Marfil dando órdenes al equipo, sino que trabajan a la par del equipo buscando soluciones a los problemas más complejos.

  6. Integra Continuamente: Como Arquitecto, debes promover y fomentar el uso de Integración Continua en cada proyecto, y de las herramientas necesarias para su implementación. Automatiza los builds, la ejecución de las pruebas unitarias, de análisis estático de código, automatiza los despliegues en los distintos ambientes, integra el producto en un servidor de Integración Continua y allana el camino para la Entrega Continua, a través de un Deployment Pipeline (Tubería de Despliegue). La era de la construcción del software como un evento Big Bang ha terminado.

  7. Evita Errores de Planificación: Jugar con el Triangulo de Hierro para abaratar Costos o reducir Tiempos puede herir gravemente la Calidad del producto y conducir al fracaso del proyecto. Una entrega apresurada de cualquier eslabón de la cadena de montaje (diseño, desarrollo, testing) conduce directamente a atrasos y/o un mayor número de problemas en Producción. La experiencia nos demuestra que ciertas reducciones provocan un encarecimiento muy superior al ahorro buscado originalmente. Como Arquitecto es tu responsabilidad no negociar la Calidad. Recuerda que "ágil es rápido, no apurado".

  8. El Triángulo de Hierro

  9. Ventajas y Desventajas Arquitectónicas: ¡No puedes tenerlo todo! Tratar de cumplir todos y cada uno de los requerimientos conduce a una arquitectura inestable que no podrá cumplir nada bien (y sino pregúntale a los tripulantes del Vasa). Hay varias herramientas disponibles para determinar las ventajas y desventajas en el diseño de una arquitectura. Entre ellas se destacan las populares Architecture Tradeoff Analysis Method (ATAM)Cost Benefit Analysis Method (CBAM) del Software Engineering Institute (SEI).

  10. La Base de Datos como una Fortaleza: La nueva escuela dice: "despliega temprano y seguido; una línea de código en producción es mejor que diez en tu cabeza". Pero mientras que las reglas de negocio y las UI evolucionan rápido, las estructuras y las relaciones entre los datos por lo general no. Las bases de datos son el custodio final de los datos. La capa de aplicación que, por diseño, es efímera, no puede ser su perro guardián. El modelo de datos debe ser lo suficientemente robusto para rechazar datos que no le pertenecen y evitar relaciones que no tienen sentido. Las claves (primarias y foráneas), los índices y las restricciones de dominio que se declaran en un esquema son breves, fáciles de entender y verificar, y sirven como documentación. Las reglas de dominio codificadas en el modelo de datos son persistentes, y un cambio en la lógica de la aplicación no tira estas reglas a la basura.

  11. Usa la Incertidumbre como un Conductor: Una arquitectura eficaz es aquella que reduce la importancia de las decisiones de diseño. Esto significa que, como Arquitectos, al enfrentarnos a dos opciones, nuestro trabajo no es elegir A o B, sino preguntarnos cómo podemos diseñar para que la decisión entre A y B sea menos significativa. Donde hay incertidumbre sobre diferentes caminos a tomar, toma la decisión de no tomar la decisión. Retrasa la decisión real hasta que ésta pueda ser tomada de forma más responsable, basada en conocimientos más profundos, pero no tan tarde que no sea posible aprovechar ese conocimiento.

  12. El Alcance es el Enemigo del Éxito: Los Arquitectos de Software amamos los proyectos complicados. Por eso tendemos a expandir el alcance de los proyectos. Pero cuanto más grande el alcance, más probable es el fracaso. Como Arquitectos debemos reducir el alcance, no expandirlo. ¿Cómo? Entendiendo las necesidades reales (cuestiona cada requerimiento no explicado en términos de valor medible para el cliente), dividiendo y conquistando (es más fácil manejar muchos proyectos pequeños que uno muy grande), priorizando (la priorización nos permite entregar los requerimientos más importantes primero) y entregando resultados lo antes posible (ya que pocas personas saben lo que quieren antes de tenerlo). Las arquitecturas complejas fallan mucho más seguido que las simples. Reduciendo el alcance del proyecto, obtendremos arquitecturas más simples.

  13. Los proyectos grandes son más propensos a caer en la hamaca de Slabbovia

  14. La Reutilización involucra a Personas y Educación, no sólo Arquitectura: Incluso la más hermosa, elegante y reutilizable arquitectura (framework, librería o API) sólo será utilizada por la gente que sabe que existe, sabe cómo usarla y está convencida de que usarla es mejor que hacerla de nuevo. Si tus equipos no saben dónde encontrar los artefactos reutilizables o cómo reutilizarlos, optarán por el camino más natural: los construirán ellos mismos. ¡Y pagarás por ello!

  15. No hay un Yo en Arquitectura: Los Arquitectos de Software solemos volvernos arrogantes y a menudo nuestro ego termina comiendo al proyecto y a nosotros mismos. ¿Cuántas veces pensamos que nosotros entendemos mejor los requerimientos que el cliente? ¿Cuántas veces vemos a los desarrolladores como recursos contratados para implementar nuestras ideas? ¿Cuántas veces estamos a la defensiva e ignoramos ideas valiosas? ¿Y por qué sucede esto? Porque los Arquitectos somos personas con auto-confianza, con la carga de varios éxitos a cuestas, la gente nos respeta y no somos más que humanos. ¿Qué podemos hacer entonces para evitar caer en la trampa del ego? 1) Trabaja con el cliente para entender los requerimientos: ten en cuenta que tú no manejas la arquitectura, son los requerimientos lo que lo hacen. 2) Enfócate en el equipo: no son recursos, son tus colegas. 3) Chequea tu trabajo: el modelo no es la arquitectura. 4) Evalúate a ti mismo: piensa en tus interacciones humanas un rato cada día: ¿fuiste egoísta?, ¿reaccionaste negativamente?

  16. Obten la Vista de Mil Pies: En un diagrama de Arquitectura pequeñas cajas representan sistemas enteros y líneas pueden significar dependencias, flujos de datos, recursos compartidos, etc. Estos diagramas son una vista del software a 30 mil pies de altura, y el código fuente se encuentra al nivel de la tierra. Claramente necesitamos vistas intermedias, vistas a mil pies. Estas vistas pueden estar compuestas por múltiples métricas como cantidad de métodos, diagramas locales de clases, complejidad ciclomática, grafos de dependencias, vistas polimétricas de los módulos y paquetes. Sonar, por ejemplo, es una excelente herramienta que nos brinda este tipo de información.

  17. Prueba Antes de Elegir: Como Arquitecto debes identificar constantemente las decisiones inminentes. Siguiendo el principio de Lean de postergarlas lo más posible, cuando se aproxime el momento, elige a varios desarrolladores del equipo y aíslate un tiempo con ellos en una sesión de descubrir-probar-evaluar distintas soluciones, analizando las ventajas y desventajas de todas las que surjan. Por lo general, luego de un análisis de estas características, la mejor solución al problema suele ser evidente para todos. El Arquitecto no tiene que tomar la decisión, simplemente orquestar el proceso de toma de decisiones. La duración de estos "Hackatones de Arquitectura" dependerá de la complejidad de la decisión a tomar.

  18. Comprende el Dominio del Negocio: Es el rol del Arquitecto de Software entender el problema, los objetivos y los requerimientos del negocio, y traducir esas necesidades en una solución de arquitectura técnica. Conocer el Dominio del Negocio ayuda a un Arquitecto a decidir qué patrones aplicar, cómo diseñar para soportar la extensibilidad, y cómo prepararse para las tendencias de la industria.