Creo que la mejor definición (más práctica y más precisa) de «arquitectura» es «lo que piensas cuando piensas en tu problema actual de una manera útil más abstracta». O para decirlo de otra manera, puede ser un análogo al viejo dicho sobre ganar la batalla pero perder la guerra. Los programadores ganan las batallas, los arquitectos ganan la guerra.
Hablar de arquitectura de software es resbaladizo, porque la propia definición de arquitectura de software es resbaladiza y cambia dependiendo de a quién se le pregunte y cuándo. Una descripción con la que la mayoría de la gente estaría de acuerdo es «los arquitectos miran el panorama general»
En un extremo del espectro se encuentra un CTO o CIO para el que la arquitectura se trata de las tecnologías y plataformas en las que la empresa debe invertir.
En el otro extremo, incluso un programador normal y corriente piensa en cómo las piezas del sistema en el que están trabajando van juntas.
En el medio, el equipo de ese programador podría tener un arquitecto que pasa su día asegurándose:
- de que el equipo está adoptando el enfoque general correcto para resolver el problema;
- de que los diferentes subsistemas en los que están trabajando los programadores encajarán bien cuando los junten;
- de que el equipo está resolviendo el problema correcto (dependiendo de la cultura y el tamaño de la organización, esto podría dividirse en un papel diferente).
Esto podría implicar un montón de diagramas UML, o podría ser más práctico e implicar más discusiones y pizarras, dependiendo de nuevo de la cultura y el tamaño de la organización.
Si se trata de un buen grupo de desarrollo de software, yo esperaría que esas discusiones involucraran a los miembros del equipo del proyecto en todos los niveles, pero en grupos más promedio podría haber más formalidad y líneas de división más estrictas, y el arquitecto podría pasar la mayor parte de su tiempo con los gerentes de proyecto, planificadores de proyectos, líderes de equipo, etc.
En contextos organizacionales más grandes, a menudo hay mucho énfasis en los formalismos para proteger a los trabajadores de base de las distracciones. En las organizaciones más pequeñas, o en los grupos de desarrollo más afilados de las organizaciones más grandes, es más fácil evitar que la colaboración en el trabajo en equipo se convierta en una distracción (y, a veces, es más fácil convencer a la dirección de que se sabe cuál es cuál).
Puede haber un arquitecto en el siguiente nivel que piense en cómo los diferentes sistemas de la empresa funcionan juntos.
Hay un término que a veces aparece en las discusiones de software, pero sorprendentemente creo que nunca lo he visto en una discusión de arquitectura: preocupaciones transversales.
Las preocupaciones transversales son cuestiones que atraviesan toda la aplicación, como el registro, la seguridad, cómo se mueven los datos (colas de mensajes vs. escuchadores de eventos vs, etc), y así sucesivamente. Los programadores ciertamente piensan en estas cosas y en cómo se relacionan con las partes del proyecto en las que están trabajando. Pero también sería razonable decir que las preocupaciones transversales son (o son una buena parte de) la carne y la bebida del arquitecto.
También, como dice un dicho militar un poco más oscuro, «los soldados rasos estudian la táctica, los generales la logística»:
La naturaleza del papel del arquitecto es tal que él o ella pasa mucho tiempo tratando con todos los miembros y niveles del equipo, incluyendo el planificador del proyecto, y el director del proyecto (si no son la misma persona). Como he mencionado anteriormente, aunque no me sorprendería en absoluto que una organización determinada fuera muy formal en cuanto a las líneas entre las áreas de responsabilidad, tampoco me sorprendería en absoluto que fuera lo contrario, es decir, que el director del proyecto y el arquitecto del proyecto y cualquier otra persona pasaran mucho tiempo no sólo dialogando, sino colaborando y charlando. Por lo tanto, el arquitecto también podría terminar haciendo un montón de cosas prácticas con la planificación del proyecto y la metodología de desarrollo de software.
(Nota, donde escribo «programador», inserte su título favorito: desarrollador, ingeniero, etc. Algunas personas (y algunas organizaciones) tratan de inventar una jerarquía en torno a estos títulos, pero nadie parece tener las mismas definiciones, por lo que la distinción no tiene sentido.)