Arquitectura del software

97 Cosas que Todo Arquitecto de Software Debe Conocer
Hay un libro llamado así: 97 Cosas que Todo Arquitecto de Software Debe Conocer. No lo he leído, pero su Wiki me parece más que interesante.



En este primer post dedicado al tema, comparto los primeros 15 principios expuestos en la Wiki:
1. Nunca pongas tu CV antes que las Necesidades del Sistema: El mejor activo de tu carrera es unalarga lista de clientes satisfechos dispuestos a recomendarte porque hiciste lo correcto para ellos y para el proyecto. Este "fondo de comercio" te servirá muchísimo más que el último chiche brillante en el último lenguaje brillante o el último paradigma brillante.

2. Simplifica la Complejidad Esencial y disminuye la Complejidad Accidental: La Complejidad Esencial representa la dificultadinherente a cualquier problema (ejemplo: la complejidad de un dominio). La Complejidad Accidental surge de las piezas tecnológicas que construimos para mitigar la Complejidad Esencial (ejemplo: la complejidad de un framework).

3. Es probable que tu mayor Problema no sea Técnico: La mayoría de los proyectos son construidos por personas; y esas personas son la base del éxito y el fracaso.

4. LaComunicación es la Reina; la Claridad y el Liderazgo, sus humildes servidores: Olvida los documentos Word de 100 páginas; nadie va a leerlos. Usa herramientas de modelado, diagramas simples que puedan cambiar frecuentemente, reúne al equipo en una pieza y comunica tus ideas en pizarrones, sácales fotos a los pizarrones y compártelas. El arquitecto debe ser también un líder. Ten a los desarrolladoresde tu lado, trabaja con ellos, déjalos expresar sus ideas, genera un ambiente cómodo de trabajo. Haz lo mismo con los demás miembros del equipo: testers, analistas de negocio, líderes de proyectos, etc.

5. Arquitecturar es Balancear: La Arquitectura de Software abarca mucho más que las clásicas actividades técnicas que hacen a la profesión; también involucra los requerimientos de negocio  detodos los stakeholders del proyecto. Es trabajo del Arquitecto poder balancear los aspectos más técnicos con las prioridades de otras áreas orientadas al negocio y a la rentabilidad del software a construir y mantener.

6. Busca el Valor en las Capacidades Requeridas: A menudo, los clientes y los usuarios finales señalan lo que piensan que es una solución viable a un requerimiento, mezclando loque es el dominio del problema con el dominio de la solución. Para evitar esto, es aconsejable organizar una serie de workshops y reuniones donde los arquitectos se enfoquen en las necesidades del cliente, ayudándolos a descubrir el "por qué" del requerimiento. Estas discusiones deberían evitar los aspectos técnicos, para que los clientes y usuarios puedan enfocarse en el dominio del negocio queconocen y no en el dominio del desarrollo de software.


Administrando Requerimientos de Software

7. ¡Ponte de Pie!: Si estás comunicando tu visión hacia otras personas, ¡ponte de pie! Así sea una revisión formal o una discusión informal, ¡ponte de pie! Sobre todo si los demás están sentados. Ponerse de pie automáticamente transmite autoridad y confianza en uno mismo. El contacto visual y ellenguaje corporal son elementos muy importantes de la comunicación. Cuando uno se pone de pie, tiende a controlar mejor la voz, hablando claro y fuerte, y reduciendo la velocidad a la hora de remarcar conceptos importantes.

8. Los Rascacielos no son Escalables: A menudo comparamos a la Ingeniería de Software con la  Ingeniería Civil. Sin embargo, nadie en su sano juicio empieza a construir unaobra de Ingeniería Civil sin saber cómo será cuando esté terminado. Agregar pisos adicionales a un edificio existente es costoso y de un riesgo incalculable, por lo que nos esforzamos por evitarlo. Una vez diseñado, no se supone que un rascacielos pueda cambiar de ubicación. Por eso es que, en contraposición con el proceso de cascada, hoy en día contamos con procesos ágiles de desarrollo, en los...