¿Qué hace a un buen arquitecto de software? ¿Cuáles son las características definitorias de un arquitecto y las diferencias entre un arquitecto y un gerente de ingeniería?

Primero, es importante diferenciar la arquitectura de software de las mejores prácticas. Un buen ingeniero de software puede ser excelente en la codificación, excelente y detallado en su enfoque, y tener una gran comprensión del problema, pero aún así puede no ser un buen arquitecto.

Como mínimo, un buen arquitecto debe tener las siguientes habilidades:

Un arquitecto es excelente en la descomposición del problema . La descomposición del problema es la habilidad necesaria para ver un problema en prácticamente cualquier nivel y dividirlo en los pasos y piezas necesarios para implementarlo. Un buen arquitecto de software puede tomar una declaración como “Nuestros sistemas de control de tráfico aéreo son inadecuados y necesitamos un mejor diseño” y conoce las preguntas que debe hacer para comenzar a descomponer el problema en componentes alcanzables, descomponer esos objetivos de componentes en subproyectos alcanzables y descomponga esos subproyectos en tareas de programación realizables. Un buen arquitecto puede hacer estas cosas a cualquier nivel o escala, desde imaginar un proyecto de software de mil millones de líneas hasta comprender la mejor manera de implementar un algoritmo para hacer frente a enlaces poco confiables. La escala es irrelevante porque el proceso es siempre el mismo.

Un arquitecto entiende las interfaces . Las interfaces, ya sea en forma de protocolos, bibliotecas de funciones, interfaces de clase o esquemas, son la herramienta principal necesaria para administrar la complejidad de los proyectos cuando hay contratistas e implementadores independientes. Al conocer el proceso de definición de interfaces nítidas e inequívocas que están lógicamente completas, un arquitecto puede capacitar a muchas personas para construir piezas de sistemas que se conectan fácilmente para lograr un objetivo más amplio.

Un arquitecto comprende que la complejidad es el enemigo y tiene un dominio de las herramientas de programación y los paradigmas necesarios para reducir la complejidad en todos los componentes, reducir la complejidad de las interfaces y asegurar una redundancia mínima o nula de la implementación de la función. Pueden reconocer rápidamente algoritmos e implementaciones que son demasiado específicos o demasiado genéricos, y guiar a los que se desarrollan para crear componentes que realicen la función correcta. A menudo, las herramientas de gestión de la complejidad son cosas como la ocultación de datos, la programación orientada a objetos, los sistemas de autovalidación y los planes integrales de prueba para interfaces estándar. Pero, un buen arquitecto no es dogmático acerca de las herramientas y las tecnologías porque tiene una comprensión académica integral de los fundamentos y las razones por las que funciona la ocultación de datos, y por qué ciertos lenguajes admiten buenos principios de diseño y otros no.

Un arquitecto es un buen comunicador, un buen y prolífico escritor y documentador , y es bueno para hablar el lenguaje de programación, así como el lenguaje común de aquellos que son partes interesadas en el diseño del sistema. Junto con una buena comunicación, un buen arquitecto puede dar razones concretas para las prácticas de programación en lugar de opiniones, y ofrece información a su equipo en lugar de argumentos. Favorecen y buscan la opinión del usuario sobre la idoneidad de los propios o de los programadores involucrados en el proyecto.

Un buen arquitecto es un buen líder y es excelente para ganarse el respeto de todas las personas técnicas con las que trabaja . Por lo general, esto significa que tienen un alto nivel de habilidad, han trabajado en varios idiomas y han sido arquitectos antes, o han demostrado su capacidad para crear diseños de sistemas que se han mantenido flexibles ante el cambio.

Muchas definiciones incluyen una variedad de palabras de moda, enfatizando metodologías como diseño basado en datos, programación ágil, lenguajes específicos, plataformas y juegos de herramientas. Estas son etiquetas actuales para varias técnicas cuya base necesita ser bien entendida, no aceptada porque actualmente en boga. Por lo tanto, en muchos sentidos, las principales habilidades de un arquitecto son la experiencia, la inteligencia, la voluntad de trabajar duro y asumir un papel práctico, una buena intuición y la capacidad de resolver problemas usando la lógica para que las palabras de moda de la industria vayan y vengan, Sus diseños siguen siendo útiles y relevantes.

Mi definición anterior intencionalmente no incluye gestión de proyectos, programación y habilidades de gestión. El rol del arquitecto es crear buenos sistemas, no resolver problemas de equipo o presupuestos. De hecho, es mejor si aquellos con presupuestos y problemas de equipo son simplemente partes interesadas que ayudan a definir una de las limitaciones que el arquitecto debe enfrentar, como si fuera parte de su problema de diseño.

Creo que la respuesta de Gary lo logró casi por completo, e incluso lo voté. Lo único que agregaría a su definición es que un buen arquitecto también es una persona pragmática.

Después de hacer todo el extenso y excelente trabajo que Gary describió tan bien, un buen arquitecto comprenderá las restricciones y limitaciones del entorno en el que se encuentra (política, plazos, presupuesto, etc.) y adaptará su solución para ajustarse de manera realista a esas restricciones. Esto no significa necesariamente destruir, pero a veces hay que tomar decisiones muy difíciles, y un buen arquitecto tiene que ser capaz de lidiar con ellas y aún así encontrar una solución viable.

Algunas buenas respuestas arriba. Yo agregaría: “Construcción de relaciones” a la lista de habilidades mencionadas.

Un arquitecto debe poder obtener la cooperación de personas de todo tipo de disciplinas diferentes en una empresa. (por ejemplo: infraestructura de TI, soporte, control de calidad, pymes comerciales, etc.) para cumplir los objetivos de los arquitectos. La capacidad de construir relaciones hace posible esa cooperación.

Diría que esos roles no están estrictamente definidos y no creo que quiera verlos bien definidos.

Para mí, un arquitecto es alguien que ha trabajado mucho como desarrollador de software, idealmente en muchas plataformas, idiomas y herramientas. Alguien que no solo entregó un buen software sino que también falló muchas veces.

Habiendo hecho todo eso, puede estar lo suficientemente educado como para tomar decisiones. Es decir, qué plataforma usar, cómo integrar, cómo evolucionar, etc.

Por lo tanto, un arquitecto no es alguien con muchos conocimientos teóricos que piensa que puede diseñar un sistema completo simplemente usando abstracciones “estándar de la industria”. Para mí, esta es la definición de un pasivo, y no me gustan los pasivos en mis proyectos.

Realmente excelentes respuestas sobre lo que es un buen arquitecto de software.

Agregaría a la lista un gran sentido del estado comercial actual en términos de mercado y escala requerida. Esto para saber qué solución elegir y qué compromisos se pueden hacer en el diseño para evitar la arquitectura innecesaria.

Respecto a la diferencia entre arquitecto de software y gerente de ingeniería.

El trabajo del arquitecto de software es asegurarse de que el software escala bien a medida que la empresa crece. El trabajo del gerente de ingeniería es asegurarse de que la organización de ingeniería se adapte bien a la empresa a medida que crece.

Todas las respuestas son muy relevantes. Gary tiene def. clavó la respuesta al punto y con gran detalle. Las dos cosas que quiero agregar a su respuesta son:

1. La contribución del arquitecto al presupuesto es muy valiosa, ya sean recursos técnicos o humanos.
2. La arquitecta de software necesita leer, aprender y evolucionar constantemente para aprender y dominar la última y mejor tecnología (en perspectiva).

Un breve resumen sería alguien que tenga habilidades técnicas muy amplias y muy profundas al mismo tiempo. La amplitud es necesaria para poder visualizar un sistema en todo su alcance. La profundidad es imprescindible ya que a veces los pequeños detalles pueden tener consecuencias muy amplias en sistemas grandes.

Otra cualidad útil es la capacidad de ponerse en el lugar del cliente. Eso incluye partes interesadas no tan obvias, como los propios desarrolladores o diseñadores gráficos. El arquitecto está allí para asegurarse de que el sistema se pueda construir de manera fácil y económica, no solo de que cumpla con algunos requisitos de tiempo de ejecución.

Un arquitecto es un ingeniero talentoso que también sabe cómo llevar un proyecto de principio a fin y cómo ese proceso afecta el diseño. No es suficiente poder formular y comunicar diseños bien pensados. Es igualmente importante saber cómo pasar de los sistemas actuales a esos diseños, de forma incremental, en tiempo real y con limitaciones reales.

La capacidad de escuchar realmente a sus partes interesadas y comprender las necesidades que podrían no estar expresando, teniendo en cuenta el panorama general y prestando atención a los detalles. Integridad, congruencia y pasión por la simplicidad y la elegancia.

Capacidad en una línea para mirar la solución completa.

Entrega principal de – modelos arquitectónicos, principios de arquitectura, diseño, selección de paquetes, requisitos funcionales mon.