Eso depende del arquitecto y del contexto, porque la definición de la arquitectura de software en sí misma es resbaladiza y cambia según a quién le pregunte y cuándo.
Un descriptor con el que la mayoría de la gente estaría de acuerdo es “los arquitectos miran el panorama general”. 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 más útil”. forma 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.
- ¿Cuántos años puede sobrevivir un ingeniero de software de rendimiento promedio en la industria de TI? ¿Qué hacen muchas personas después de ese período?
- ¿Debo cambiar al desarrollo basado en pruebas y, en caso afirmativo, cómo?
- ¿Hay algún libro que discuta cómo escribir software altamente compatible?
- ¿En qué casos son útiles las permutaciones / combinaciones en la programación? ¿Cuáles son algunos problemas que ocurren cuando estas ecuaciones serían útiles para resolverlas?
- ¿Por qué AM Padma Reddy escribe libros CS?
(Tenga en cuenta que cuando escribo “programador”, inserte su título favorito: desarrollador, ingeniero, etc. Personalmente no compro en la jerarquía que las personas intentan inventar alrededor del programador frente al desarrollador frente al ingeniero de software).
En un extremo del espectro hay un CTO o CIO para quien la arquitectura trata sobre en qué tecnologías y plataformas debe invertir la empresa.
En el otro extremo, incluso un programador habitual de Joe piensa en cómo las piezas del sistema en las que están trabajando van juntas.
En el medio, el equipo de ese programador podría tener un arquitecto que pase el día asegurándose de:
que el equipo está tomando el enfoque general correcto para resolver el problema;
que los diferentes subsistemas en los que están trabajando los programadores encajarán bien juntos;
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 rol diferente).
Esto podría implicar una gran cantidad de diagramas UML, o podría ser más práctico e involucrar más discusiones * y pizarra, dependiendo nuevamente de la cultura y el tamaño de la organización.
Puede haber un arquitecto en el siguiente nivel que piense en cómo funcionan juntos los diferentes sistemas empresariales.
[* Nota, si es un buen grupo de desarrollo de software, esperaría que esas discusiones involucren a 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 del tiempo. su tiempo con gerentes de proyecto, planificadores de proyecto, líderes de equipo, etc.
En contextos organizacionales más grandes, con frecuencia se hace mucho hincapié en los formalismos para proteger a los trabajadores de rango y archivo de las distracciones. En organizaciones más pequeñas, o grupos de desarrollo más precisos en organizaciones más grandes, es más fácil evitar que la colaboración de trabajo en equipo se distraiga (y a veces es más fácil convencer a la gerencia de que sabes cuál es cuál).]
Hay un término que a veces aparece en las discusiones de software, pero sorprendentemente no creo haberlo visto nunca en una discusión de arquitectura: preocupaciones transversales.
Las preocupaciones transversales son problemas que abarcan toda la aplicación, como el registro, la seguridad, cómo se mueven los datos (colas de mensajes vs oyentes de eventos vs, etc.). Los programadores ciertamente piensan en estas cosas y 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 (una buena parte de) la carne y la bebida del arquitecto.
Además, como dice un dicho militar un poco más oscuro, “los privados estudian tácticas, los generales estudian logística”:
La naturaleza del rol del arquitecto es tal que él o ella pasa mucho tiempo tratando con todos los miembros y niveles del equipo, incluido el planificador del proyecto y el gerente del proyecto (si no son la misma persona). Como mencioné anteriormente, aunque no me sorprendería en absoluto si una organización determinada es muy formal sobre las líneas entre áreas de responsabilidad, tampoco me sorprendería en absoluto si es lo contrario, si el gerente de proyecto y el gerente de proyecto y el arquitecto del proyecto y quien sea que haya pasado mucho tiempo no solo mintiendo, sino colaborando y haciendo kibbitzing. Por lo tanto, el arquitecto también podría terminar haciendo muchas cosas prácticas con la planificación de proyectos y la metodología de desarrollo de software.