La mejor respuesta
No existen definiciones formales de estos roles que sean ampliamente adoptadas como estándar por organizaciones, por lo que habrá mucha variación y contexto localizado.
Como guía general, utilizo las siguientes definiciones:
- Arquitecto técnico: especialista en áreas alineadas a la infraestructura, las redes y la seguridad.
- Arquitecto de soluciones: un generalista responsable de las soluciones basadas en proyectos que tienen en cuenta todos los aspectos de una solución (por ejemplo, impacto comercial, cambios de aplicaciones, consideraciones de datos e información y la tecnología que sustenta todo esto) y, con suerte, también las consideraciones del cliente.
- Arquitecto principal: alguien con un conjunto de responsabilidades más amplio que los roles anteriores. Esto podría centrarse en un dominio empresarial, un programa de trabajo más amplio o en toda una empresa. También lo utilizan a menudo las consultoras para sugerir un nivel de superioridad (experiencia) sobre otros arquitectos del equipo. Normalmente tendrán preocupaciones generalistas en lugar de centrarse en un solo dominio de arquitectura como la infraestructura, pero ese no es siempre el caso.
Espero que eso ayude. Es importante recordar que hay no hay estándares aceptados, por lo que los términos en sí son específicos del entorno en el que se utilizan.
Respuesta
Primero, es importante diferenciar la arquitectura del 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 cantidad de información sobre el problema, pero aún así puede no ser un buen arquitecto.
Como mínimo, un buen El arquitecto debe tener las siguientes habilidades:
Un arquitecto es excelente en la descomposición de problemas . La descomposición de problemas 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 hacerse para comenzar a descomponer el problema en componentes alcanzables, para descomponer los objetivos de los componentes en subproyectos alcanzables. y descomponer esos subproyectos en tareas de programación alcanzables. 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 fiables. 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 clases o esquemas, son la herramienta principal necesaria para gestionar la complejidad de los proyectos cuando hay contratistas e implementadores independientes. Al conocer el proceso de definir interfaces nítidas e inequívocas que son 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 entiende 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 mínima o nula redundancia de implementación de función. Pueden reconocer rápidamente algoritmos e implementaciones que son demasiado específicas o demasiado genéricas, y guiar a quienes desarrollan para crear componentes que realicen la función correcta. A menudo, las herramientas para administrar la complejidad son cosas como el ocultamiento de datos, la programación orientada a objetos, los sistemas de autovalidación y los planes de prueba completos para interfaces estándar. Pero un buen arquitecto no es dogmático acerca de las herramientas y tecnologías porque tiene una comprensión académica integral de los fundamentos y las razones por las que la ocultación de datos funciona, y por qué ciertos lenguajes apoyan buenos principios de diseño y otros no.
Un El arquitecto es un buen comunicador, un buen y prolífico escritor y documentalista , y es bueno para hablar el lenguaje de programación, así como el lenguaje común de quienes 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 para la propia o la de los programadores involucrados en el proyecto.
Un buen arquitecto es un buen líder y es excelente para ganarse el respeto de todos los técnicos trabajan con .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 frente al 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 conjuntos de herramientas. Estas cosas son etiquetas actuales para varias técnicas cuya base debe entenderse bien, no aceptarse porque son actualmente en boga. Entonces, 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 utilizando la lógica para que, a medida que las palabras de moda de la industria van y vienen 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 papel 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 restricciones con las que debe lidiar el arquitecto, al igual que si fuera parte de su problema de diseño.