¿Puede ejercer de manera efectiva como Arquitecto de empresa o Arquitecto de soluciones sin la capacidad de codificar?

Lamento decir esto, pero todas las personas que respondieron “NO” a la pregunta no entienden qué es Enterprise Architect o Solution Architect. Principalmente porque nunca han estado en el rol de Enterprise Architect. ¿Cuál es la capacidad de codificar? Creo que la “capacidad de codificar” es la capacidad de traducir inmediatamente un algoritmo informático en una unidad de código de trabajo utilizando una u otra semántica de lenguaje de programación. Honestamente, poniendo sinceramente tu mano sobre tu corazón, dime qué tiene esto que ver con la arquitectura empresarial en todo el mundo. No confunda la capacidad de codificar con la comprensión de, por ejemplo, la estructura interna de VM y el ajuste de GC, o la comprensión de cómo funciona la multitarea preventiva, podría haber muchas otras tareas de ingeniería relacionadas con la ejecución de un programa y tener un impacto en la arquitectura de un servicio o componente y posteriormente arquitectura de solución. Es sorprendente cuántas personas tontas piensan que conocer la complejidad de un algoritmo de clasificación los convierte en arquitectos empresariales … No, los desarrolladores no pueden evolucionar a Arquitectos empresariales, a menos que cambien de profesión … Eso es dominar un tema técnico totalmente nuevo.

Incluso mi hijo de 7 años está ‘aprendiendo a codificar ‘ en la escuela. Por lo tanto, supondré que el OP implica “la capacidad de escribir código listo para la producción utilizando los procesos, herramientas y técnicas utilizadas en la organización”. Utilizando este supuesto, mi respuesta es simple:

• Arquitecto empresarial: sí, puede ejercer de manera efectiva como Arquitecto empresarial sin la capacidad de codificar.
• Arquitecto de soluciones: un Sí calificado para este rol también.

¿Por qué digo esto?

Enterprise Architects podría provenir de cualquiera de los dominios BIDAT y solo aquellos de un fondo de aplicación ‘A’ pueden saber codificar. Incluso suponiendo que un EA provenga de un entorno de desarrollo de aplicaciones con experiencia práctica en codificación, es posible que no sea competente en los nuevos lenguajes y paradigmas de programación.

Los ejecutivos que dejan que sus arquitectos empresariales se pongan manos a la obra y el código no están haciendo el mejor uso de su talento (el de EA).

Se espera que los arquitectos de soluciones traigan una profundidad del ciclo de vida de la aplicación, incluido el desarrollo y la integración. Muchos de ellos también pueden tener antecedentes de “codificación”, pero la capacidad de visualizar y comunicar soluciones es más importante que la capacidad de codificar. En organizaciones más pequeñas, no es inusual que las SA se sienten con los desarrolladores para crear prototipos y validar soluciones.

El enfoque en la capacidad de codificar es poco práctico, ya que esto puede significar cualquier cosa. En consecuencia, propondría hacer un acercamiento a la esencia de estos roles de arquitectura para derivar las condiciones previas de eficiencia.

Si bien no recuerdo la fuente original de la imagen a continuación, considero que es una excelente ilustración de la clave para comprender los roles de la arquitectura.

En mi entorno, se distinguen cuatro roles:

• Arquitecto empresarial : elabora una arquitectura de destino (para todo el panorama de la aplicación o dominios significativos) que cumple los objetivos de los administradores de inversiones + define la cartera de proyectos correspondiente que realiza esta arquitectura, así como la arquitectura prescriptiva para cada uno de estos proyectos. Por lo tanto, cada uno de estos proyectos puede asignarse a un Arquitecto de soluciones.
  El desarrollo no es parte de la responsabilidad de este rol, y tampoco lo es revisar ningún desarrollo. Sin embargo, para abogar por la arquitectura prescriptiva (por ejemplo, incluyendo los estándares tecnológicos recomendados), uno debe poder recurrir a la experiencia como Arquitecto de Soluciones.
• (no se muestra en la imagen) Arquitecto de negocios
• Arquitecto de soluciones : elabora una solución que se puede demostrar que satisface los requisitos (de automatización) de un proyecto y se refina lo suficiente como para entregarla a arquitectos técnicos de los diversos subsistemas. Por lo tanto, un Arquitecto de soluciones descompone un problema complejo (el proyecto) hasta el punto en que se distribuyen las responsabilidades de los diversos subsistemas y se aclaran sus integraciones.
  El desarrollo no es parte de la responsabilidad de este rol, sin embargo, las interacciones diarias con los desarrolladores requieren habilidades superpuestas suficientes para que las recomendaciones de solución sean aceptadas.
• Arquitecto técnico : experto en una pila vertical de tecnologías de implementación (esto correspondería al Arquitecto de software como se menciona en las otras respuestas).
  El desarrollo es una parte intrínseca de las tareas diarias de este rol.

Los arquitectos de soluciones pueden provenir de un entorno de desarrollo, pero no es necesario. También pueden provenir de infraestructura, TI, administración de sistemas, análisis de negocios, etc. Entonces, sí, creo que puede ser un Arquitecto de Soluciones efectivo sin poder codificar.

Los arquitectos de software empresarial deben provenir de un entorno de desarrollo, pero en la práctica, muchas organizaciones grandes tienen personas en este rol que no tienen mucha experiencia práctica en la construcción de sistemas reales. En mi experiencia, esto es desafortunadamente común. Los escuché llamados “arquitectos de PowerPoint”. Sus decisiones no están bien informadas, las restricciones que imponen a menudo son inapropiadas y su orientación no es útil. Por lo tanto, no, no creo que pueda ser un arquitecto de empresa eficaz a menos que tenga una experiencia considerable en software de ingeniería (que obviamente incluye la posibilidad de codificar).

Un Enterprise Architect básicamente está analizando y planificando arquitecturas en tres capas: negocios, aplicaciones e infraestructura. Es un rol estratégico muy cercano al CIO.

Por lo tanto, se requiere que tenga un amplio conocimiento de TI. Entonces, NO, no necesita poder codificar. Sin embargo, debe comprender las prácticas de desarrollo de software.

El Arquitecto de soluciones debería tener experiencia en desarrollo de software ya que está diseñando soluciones.

Es un error común ver a un Arquitecto de empresa solo como un “Arquitecto de soluciones senior”. Esos son roles diferentes.

He visto y trabajado con arquitectos con diferentes antecedentes, experiencia y habilidades. He visto a PM convertirse en arquitectos, un desarrollador incondicional convertido en arquitectos y los líderes de desarrollo se convierten en arquitectos.
La pregunta es menos sobre la capacidad de codificar, sino más sobre conocer y comprender los matices más finos de escribir software y procesos a nivel empresarial.
Si nunca ha convertido un requisito en una prueba de diseño, código y unidad, ¿cómo calificaría la complejidad de implementar su solución? Si nunca ha solucionado un error encontrado en las pruebas de rendimiento, ¿cómo puede estar seguro de que su solución se desplegará bien?
En pocas palabras, gran parte de ser Arquitecto es el liderazgo y los líderes deben y deben, a veces, hacer el trabajo que está haciendo su equipo. Es difícil ganarse el respeto de los desarrolladores si su código nunca ha visto la luz del día de producción.

No. No puede comprender los sistemas de software empresarial (en particular) sin experimentar personalmente lo que se necesita para diseñarlos, construirlos, probarlos y, más prácticamente, los errores que se pueden cometer. Exactamente cuánta experiencia es discutible. Actualmente no existe un sistema complejo que no incluya el software como componente principal.

No, eso no es factible.

En mi puesto actual, el arquitecto de la empresa tiene que preguntarme (o cuestionarme) sobre las decisiones que tomé como ingeniero de software líder en el proyecto. Sin la comprensión de los algoritmos y mi componente “en lo pequeño”, no podríamos tener una discusión razonable.

O diría que no, y no me dejaría hacer mi trabajo; o simplemente di que sí y permíteme cometer errores en el diseño del programa.

Depende del rol exacto y la compañía. En algunas tiendas se espera que al menos tenga un fondo de codificación y en otras se espera que realmente haga algo de codificación y en otras no estará expuesto a la codificación más allá de UML.

En mi experiencia, un EA / SA que puede codificar está un paso por delante de aquellos que solo saben diagramar.