Tal vez me presenten como «arquitecto de software» a los clientes porque todos los demás prefieren no ser objeto de la ira que el cliente está dispuesto a desatar. (Los clientes no suelen visitarme cuando las cosas van bien.)
De todos modos, para algunas partes del software que desarrolla mi grupo, soy probablemente lo más parecido a un «arquitecto de software». Es una descripción de trabajo un poco nebulosa o posiblemente falsa como se menciona en algunas otras respuestas. Mi verdadero título es Ingeniero Principal. Posiblemente también falso.
Creo que convertirse en un «arquitecto de software» requiere mucha experiencia con su propio software, así como la comprensión de cómo funcionan otras piezas similares de software. Esa experiencia y comprensión no se da por sí sola, incluso si trabajas en la misma área durante más de 20 años. Creo que hay una actitud que debes tener hacia tu carrera que incluye:
- Deberías querer entender todas las pequeñas piezas del producto-no sólo saber que existen, sino entender su implementación, limitaciones, la deuda técnica, etc. asociada con cada parte del sistema.
- Deberías aprender sobre cómo interactúa con otro software-el software que escribes y el software complementario, y el software de la competencia.
- Deberías entender cómo tus clientes utilizan el software, y también lo que necesitan.
Puedes trabajar en la misma empresa durante 20 años y no conseguir nada de lo anterior, así que necesitas algo más que tiempo.
La mejor manera de hacer el número 1 es conseguir algo de experiencia haciendo desarrollo en tantas piezas del software como puedas. Corregir errores, ayudar con las características, hablar con los desarrolladores que poseen cada una de las piezas. Comprender la «deuda técnica» asociada a todas las piezas te ayudará a entender cuánto tiempo llevará cambiar algo, cuántos errores tendrá y cuándo es el momento de reescribirlo. Si hay varias soluciones, la que implique grandes cambios en el código con mucha deuda técnica es probablemente más arriesgada y una de la que hay que alejarse.
Una buena manera de aprender sobre el #2 anterior es usar el software usted mismo.
La mejor manera de lograr el #3 anterior es hablar con los clientes, visitarlos y verlos usar la herramienta. Hay una tendencia, creo, a que los desarrolladores de software se aíslen de los clientes, viviendo en su propio mundo en el que creen entender lo que el cliente quiere, por qué lo quiere y cómo dárselo. Cada vez que interactúo con alguien que realmente utiliza el software, es una experiencia reveladora y a menudo me hace replantear las características existentes o me da ideas sobre otras nuevas.