software - architecture traduccion

¿Cómo convertirse en un arquitecto técnico? (4)

Actualización: los dos enlaces están rotos, intentaré encontrar algún contenido de reemplazo pero, mientras tanto, esta página tiene una lista de diferentes tipos de arquitectos, FWIW: http://en.wikipedia.org/wiki/Systems_architect

~~~~~~~~~~~~~~~~~~~~~~~~~~~

Depende de lo que llames " Arquitecto Técnico ", así como a dónde quieres ir. Además, su experiencia (en la medida en que lo describió) está relacionada con la programación / software, por lo que el término "Arquitectura técnica" podría no ser exactamente lo que está buscando.

Como lo entiendo, un Arquitecto Técnico se preocupa más por los estándares, así como por un Arquitecto de Software que trataría más con los códigos y los patrones de diseño.

Mi consejo general para usted es este:

Investigación: leer libros, artículos, blogs y (lo más importante) ...
Interacción: hable con arquitectos reales sobre qué es lo que hacen y cómo llegaron allí. Seguro que puedes hacer preguntas en foros como este, pero lo que estás buscando es una discusión profunda y no solo una o dos. Una forma de hacer esto es ...
Únase a un foro local de arquitectos o grupo comunitario en su área, o asista a las charlas extrañas. Las grandes conferencias como Tech Ed tendrán una pista arquitectónica, así que esté atento a los temas interesantes.
Bide you Time: obtuve el título formal de "Arquitecto de soluciones" después de 8 años en el desarrollo de software, que probablemente esté en el lado rápido; así que prepárate para un largo pero "profundo" viaje.
En términos de dominio, ¿desea permanecer en el software o pasar a la infraestructura? ¿Especialista en seguridad quizás? La única forma de saberlo es ensuciarse las manos con algunas de ellas; y tener muchos pequeños bits de amplia experiencia (como en infraestructura, seguridad, datos) aumenta muy bien un "centro de gravedad" profundo en algo como la arquitectura de software.

Cosas a considerar en el camino:

Ser un arquitecto no se trata solo de encontrar soluciones técnicas para problemas técnicos, también (al menos la mitad) se trata de "habilidades blandas" ...
Liderar equipos de desarrollo / equipos de proyectos, asesorar a los gerentes de proyectos; Te buscarán una guía.
Resolviendo la ambigüedad, lidiando con necesidades conflictivas. Análisis de problemas empresariales, etc.
Pensando fuera de la plaza y haciendo (volviendo a hacer) las preguntas básicas, por ejemplo: Pregunta: "¿Cuál es la mejor manera de hacer X?", Su respuesta: "¿Por qué X en primer lugar?"

Para su información, " Aspiring Architects " es uno de mis temas favoritos.
Actualización de enero de 2017 : finalmente se actualizó el enlace roto (¡contenido escrito en 2010!), Y además se agregó uno nuevo sobre cómo definir architecture-roles .

He pasado más de 3 años en la programación de dotnet (C #) y ahora quiero ver el marco / diseño.

He decidido convertirme en un buen arquitecto en el futuro. Sé que para esto necesito trabajar duro. Estoy listo para hacerlo.

Lo que no sé es cómo empezar?

¿Podrían ustedes ser lo suficientemente amables para ayudarme a conseguir el paso correcto?

Gracias

Creo que para ser un buen arquitecto técnico, debe ser un buen comando en los patrones de diseño, WCF, WPF, herramientas de informes, C #, SQL Server, etc.

Personalmente aprendí más cuando refactoricé un gran sistema heredado hacia una arquitectura modular en la que se corta el código antiguo en capas y se pega con una inyección de dependencia u otras abstracciones basadas en patrones de arquitectura comunes. De este modo, puede ver cuáles son los errores comunes y por qué tiene sentido poner esfuerzo en modularizar un sistema desde el principio.

Se trata de construir un sistema que pueda mantenerse en el tiempo. ¡La testabilidad y los módulos son clave!
Debe conocer los patrones y ver cuándo pueden ayudar y por qué.
"Sobre las diferentes tecnologías que usaste en el archivo que trabajas y cómo pegarlas
"sobre la configuración de un sistema grande que se puede utilizar en diferentes contextos con un mínimo esfuerzo
"sobre herramientas que pueden medir una buena arquitectura como pmd, findbugs en el mundo java
"sobre la configuración de un código, prueba, entorno de construcción que permita un desarrollo ágil ...
y muchos muchos mas...
Arquitectura de un sistema es una gran responsabilidad y si se hace mal, puede arruinar todo.

Personalmente, no permitiría que alguien tome decisiones arquitectónicas importantes sin menos de 10 años de experiencia.

Un verdadero arquitecto que construye edificios reales pasará la mayor parte de su tiempo investigando el código de construcción, estableciendo vínculos con autoridades de planificación y discutiendo los costos con los inversores.

Por lo tanto, un arquitecto de soluciones pasará la mayor parte de su tiempo asegurándose de que la solución cumpla con los diversos estándares de seguridad y desarrollo en el sitio, que cumpla con los planes de trabajo de la empresa, etc., y que discuta presupuestos, etc. .

Un arquitecto real rara vez tiene la oportunidad de ser Richard Rodgers y construir un edificio sustancial en un sitio nuevo para un cliente con bolsillos profundos, en lugar de eso, diseñan casas de "cortadores de galletas" para desarrolladores especulativos, agregan extensiones a edificios existentes o remodelan edificios antiguos para obtener nuevos usos.

De la misma manera, el arquitecto de TI pasará la mayor parte de su vida profesional mejorando o reemplazando partes de un sistema existente dentro de un presupuesto limitado, un período de tiempo limitado y estará severamente limitado por la tecnología existente.

Por lo tanto, mi consejo es controlar los distintos estándares y procedimientos en los que trabaja e intentar controlar el proceso arquitectónico en la medida en que funciona y la jerga que se utiliza en su organización. Si eras muy bueno como programador, ya sabes todas las cosas técnicas que necesitas.