¿Cómo puede un ingeniero de software convertirse en arquitecto de software?

Un arquitecto de software que valga la pena debe poder hacer lo siguiente:

1. Comprender la tecnología reciente y estar al tanto de los nuevos desarrollos en el mundo del software.

2. Estar expuesto a una gran cantidad de productos / bibliotecas que resuelven diferentes problemas.

3. Poder pensar más allá de un solo idioma y estar preparado para ir más allá de la zona de confort.

4. Aprende cosas nuevas a diario.

5. Comprender los protocolos web Threading, TCP / IP, como HTTP.

6. Poder dividir un problema complejo en problemas más pequeños.

7. Comprender la escalabilidad y el rendimiento.

… Y muchas otras cosas que no puedo enumerar.

Pero ya sabías esto.

Todo lo que se necesita es pasión para aprender cosas nuevas todos los días y aplicarlas en los sistemas que diseñe.

Eres arquitecto si crees que lo eres.

Sé que es grosero, y lo siento, pero no puedo creer que las personas (aparte de Edward Guy Capriolo) escribieran largas respuestas explicando la diferencia entre dos títulos. Los “arquitectos de software” existen solo en películas de ciencia ficción como Matrix.

El título fue inventado por burócratas corporativos para establecer el nuevo tramo salarial no administrativo, donde alguien sin un MBA podría ganar seis cifras. Fue útil durante la “subcontratación”, ya que los pocos desarrolladores restantes no “offshore” o H1B / L1 podrían ser promovidos a “arquitectos” para mantener su salario, ya que todos los ingenieros “regulares” tenían la obligación de ser “recursos de descuento”.

Otra cosa a tener en cuenta: los puestos de asesores inútiles como ese están ocupados por familiares y amigos, por lo que no hay un conjunto de habilidades oficiales para aprender. El valor del “arquitecto” es vago y subjetivo por decir lo menos. TOGAF es quizás la descripción final de las responsabilidades del “arquitecto”. Estudié bien esa basura para mostrarla en entrevistas “arquitectónicas”. Sin embargo, en la vida normal, mi especialidad es iniciar proyectos multimillonarios. Y reviviendo fallas multimillonarias. ¿Me hace un “arquitecto”? Implica mucha codificación, ya sabes. Y cero “marcos” de “arquitectura empresarial”.

Simplemente edite su currículum reemplazando todos los títulos de trabajo anteriores para mostrar los “años de experiencia”. Luego, generosamente espolvoree la jerga de “arquitectura empresarial” en todo el currículum. Permítanme ver la versión del arquitecto de mi currículum (de lo contrario, del desarrollador). Aquí. Cópielo textualmente:

“Desarrollé una visión de tecnología avanzada y capacidades sólidas de arquitectura empresarial dentro de TI. Contenido de hoja de ruta común definido. Desarrollé e implementé la estrategia para la arquitectura empresarial que consta de principios, arquitecturas de referencia, glosarios y taxonomías. Se realizó un análisis continuo de la industria, la tecnología y las tendencias del mercado para determinar los posibles impactos en la empresa “.

¡Felicidades! Has sido promovido oficialmente al “Arquitecto de la empresa”. Lo único que queda por hacer es enviar su nuevo y digno currículum vitae a los empleadores que forman la Gran Cadena Alimentaria de Consultoría de TI, para “post-vender” lo que sea que estén vendiendo: Oracle, IBM, Microsoft, etc. a través de “diagramas de arquitectura”: bloques de colores de los paquetes de proveedores conectados por “integración” imaginaria. No te preocupes por el “mumbo-jumbo técnico”. Usted es un arquitecto de alto nivel que presenta la visión estratégica a “partes interesadas de nivel C” igualmente dignas y altamente no técnicas.

Las grandes empresas a menudo tienen descripciones escritas formales de las responsabilidades laborales de cada grado o nivel de promoción de ingenieros. Estas descripciones escritas pueden incluir frases como:

• Nivel de entrada / Junior: “Codifica de manera eficiente y confiable elementos de trabajo completamente especificados”
• Nivel medio: “Especifica e implementa subsistemas bajo la supervisión del arquitecto principal”
• Senior: “Especifica e implementa independientemente sistemas o colecciones de sistemas; orienta al personal junior en tareas de diseño y arquitectura”

  Y luego, la bifurcación en el camino:

• Arquitecto / Ingeniero del personal: “Trabaja con el equipo de diseño para especificar la arquitectura y el diseño técnico del producto; asigna el trabajo a los asistentes designados según sea necesario”; O
• Líder de grupo / Ingeniero principal: “Administra el desarrollo técnico y las necesidades del personal del proyecto, incluida la asignación de recursos, la asignación de tareas y las responsabilidades de recursos humanos a nivel de línea”

En tales empresas, no se le asciende de, digamos, ingeniero de nivel de entrada a ingeniero de nivel medio, hasta que haya demostrado que es totalmente capaz de realizar las responsabilidades del trabajo. Esto se debe a que, en el trabajo de ingeniería, no hay margen para que las personas “se conviertan” en las responsabilidades de sus trabajos: deben ser capaces de hacerlo desde el primer día.

Incluso en empresas que adoptan estructuras de gestión planas, y que no tienen una bifurcación formal entre la gestión y la progresión técnica, la forma en que se convierte en arquitecto de software es demostrando que es un arquitecto de software confiable, primero asumiendo la responsabilidad del diseño de algo pequeño, y luego para piezas cada vez más grandes hasta que sea capaz de supervisar y ejecutar el diseño técnico de todo el producto.

Lance tiene razón en que los términos carecen de sentido, pero creo que con un poco de esfuerzo podemos entender lo que realmente está preguntando. Supongo que por ingeniero de software te refieres a programador y por arquitecto te refieres a alguien que gestiona proyectos más grandes y tiene una opinión más creativa sobre cómo se desarrolla una solución.

Creo que, bajo esa luz, algunas ideas que consideraría serían:

0. Mientras volvía a leer mi lista, me di cuenta de que hay una más que pertenece al frente. Asumir la responsabilidad

1. Intenta ver el panorama general. No se concentre en soluciones de codificación inmediatas, concéntrese en la solución general independientemente del idioma o la plataforma. Mire más allá de cuáles son sus responsabilidades inmediatas y vea cómo todo está interrelacionado y conectado.

2. Hable con los usuarios, conózcalos, escúchelos y desarrolle confianza y una relación con ellos. Comprender las razones comerciales y la justificación del proyecto.

3. Aprenda a dejar que otros hagan su trabajo y no se involucre demasiado en los detalles de cómo resuelven los problemas. Asegúrese de que estén haciendo su trabajo bien y de manera adecuada, pero si prefiere una lista vinculada y prefieren una matriz, no se deje atrapar por hacer que hagan todo de la manera exacta en que lo haría.

4. Sepa que una solución hermosa que nunca se lanza o usa no tiene valor y que una solución funcional y en uso que es un compromiso es oro.

5. Sepa cuándo ignorar la regla # 4 y no comprometerse.

6. Conozca la diferencia entre problemas perversos y problemas domesticados. Los problemas de domesticación tienden a ser de naturaleza técnica y pueden resolverse. Un problema manso podría ser cómo ordenar una lista o diseñar tablas relacionales. Los problemas perversos tienden a ser de naturaleza humana y difíciles, si no imposibles, de resolver. Los problemas perversos tienden a estar basados ​​en requisitos o en la comunicación, un usuario dice una cosa pero significa algo totalmente diferente, o un grupo de usuarios no le gusta a otro grupo de usuarios y sobreviene el caos. Cuando se resuelve un problema domesticado, permanece resuelto, pero cuando se resuelve un problema perverso, puede resolverse solo si no tiene cuidado.

Creo que lo único que encontrará a medida que avance es asegurarse de saber a dónde se dirige. Puedes mirar a alguien que consideras un arquitecto y pensar que lo hicieron, pero cuando llegues allí, quizás te encuentres mirando hacia atrás y recordando los viejos tiempos cuando todo lo que tenías que hacer era resolver problemas algorítmicos simples.

Es una de esas cosas que es semántica mitad mierda, mitad cosa legítima. Nunca he escuchado una definición muy clara del papel, pero lo intentaré.

Conocí a un par de “arquitectos de software”, y básicamente eran personas normales de software que lo habían estado haciendo durante mucho tiempo y ayudaron a consultar sobre arquitectura, y por lo general tomaron algún tipo de papel de alto nivel en el desarrollo.

Ya sabes … como saber qué tipo de DB usar, en qué tipo de plataforma ejecutarlo, qué idiomas podrían funcionar mejor, qué conectar dónde, cuándo usar el almacenamiento en caché, cuáles son las ventajas y desventajas de las cosas, etc.

Si trabajas en un espacio durante 15-20 años, sabrás cosas como el dorso de tu mano.

Demonios, dame 5–6 años más en el espacio web dentro de una compañía lo suficientemente grande y creo que estaré allí, en cuanto a la capacidad de arquitectura. Pero ahí es donde entra la mierda: dan el título en gran medida para justificar el pago y para dar palmaditas en la espalda de las personas.

Un arquitecto debería poder ofrecer las mejores soluciones para mejorar al menos una de estas áreas:

• Velocidad de ejecución.
• Consumo de recursos (cpu, ram, IO).
• Productividad de la codificación (¿es posible para mí codificar algo una vez y volver a usarlo cientos de veces ?, verifique AOP).
• Seguridad.
• Sistemas distribuidos de comunicación.
• Administre un presupuesto para el costo de sus herramientas / tecnologías que se ajuste al estado monetario de la empresa para el que está trabajando.

Debes leer, leer y leer.

Lea sobre las últimas tecnologías y tendencias, entiéndalas haciendo algunos códigos de prueba y enumere los beneficios y escríbalos en una hoja de papel.

Una vez hecho esto, deténgase por un segundo y analice la estructura actual de la base de código de la compañía e intente ver si puede usar algunos de los beneficios de esa hoja de papel para mejorar la base de código.

Los términos son simplemente juegos de palabras.

Codificador, programador, desarrollador, ingeniero, arquitecto.

Algunas diferencias comunes entre un desarrollador y un ingeniero (aunque generalmente son iguales), es que un ingeniero es capaz de diseñar las estructuras lógicas (componentes) donde un desarrollador es un subconjunto o JR que puede juntar las piezas pero no crear nuevas piezas. .

En la mayoría de los casos, estos se consideran iguales, pero hay una línea sutil que hace que un ingeniero sea eso, sobre todo es actitud.

Un arquitecto es un paso adelante de un ingeniero en el sentido de que pueden trabajar en sistemas de imagen grande, con varios componentes y hacer que funcionen juntos sin problemas al abordar estructuras básicas y crear estándares para hacer que el diseño y el mantenimiento sean más sofocantes.

Entonces, esto no es diferente al ingeniero en concepto, solo que es a una escala mucho mayor. A menudo con una mejor comprensión de los patrones de diseño y los patrones lógicos.

La mejor manera es seguir aprendiendo, especialmente patrones de diseño y algoritmos.

El problema con el término ‘arquitecto’ es que significa cosas diferentes para diferentes personas y empresas. Todos, desde un ‘código mono’ (1) en adelante, podrían tener el título aplicado dependiendo de la compañía.

En una empresa disfuncional, un arquitecto es alguien que se mantiene a un paso de los equipos y dicta los requisitos. En una buena compañía, un arquitecto es alguien que trabaja con equipos para garantizar que se cumplan los objetivos. En una empresa increíble, todos son arquitectos.

Generalmente, un arquitecto trabaja en todos los equipos, mirando la imagen más grande con más detalle que cualquier otro miembro individual del equipo. Ahora sé lo que vas a decir. Todos deberían pensar en el panorama general. Estoy de acuerdo y en un increíble conjunto de equipos es probable que no necesites que el Arquitecto asuma este rol.

También asumen responsabilidad adicional para garantizar que se consideren las habilidades durante el diseño de la pila (nota: pilas de diseño de equipos, no arquitectos). Ahora sé lo que vas a decir. Todos deberían pensar en las -ilicias. Estoy de acuerdo y en un increíble conjunto de equipos es probable que no necesites que el Arquitecto asuma este rol.

Los arquitectos también trabajan con personas como los CTO para garantizar que las estrategias de TI de las empresas sean sensatas y se sigan. Ahora sé lo que vas a decir. Todos deberían pensar que la estrategia de la compañía y el CTO deberían ser accesibles para todos. Estoy de acuerdo y en un increíble conjunto de equipos en pequeñas empresas con CTO increíbles, es probable que no necesite que el Arquitecto asuma este rol.

Al igual que un Scrum Master, un Arquitecto es una mezcla de muletas para equipos que no son asombrosamente (2) y un amortiguador entre el equipo fuera de interferencia. Con la mayoría de los equipos, los roles son muy útiles, ya que los equipos impresionantes son bastante raros.

Nada de esto responde a la pregunta de cómo te conviertes en uno. Básicamente por ser un gran ingeniero y tomar ese camino cuando eres increíble (o estar en un equipo increíble, donde todos ya son Arquitectos).

1) Con esto me refiero a alguien que elimina el código sin preocuparse por los requisitos o cualquiera de las habilidades.

2) Por no asombroso me refiero a cualquier cosa, desde horrible hasta genial.

Un ingeniero de software eventualmente se convierte en un arquitecto de software cuando obtiene suficiente conocimiento y experiencia en la industria para tomar decisiones de diseño de alto nivel y puede dictar estándares técnicos, incluidos estándares, herramientas y plataformas de codificación de software.

El Instituto de Ingeniería de Software (SEI) de la Universidad Carnegie Mellon reunió los deberes, habilidades, conocimientos y responsabilidades de soporte organizacional de un Arquitecto de Software de un gran número de líderes de la industria.
Léalo desde aquí: Deberes, habilidades y conocimiento de un arquitecto de software

Supongo que contiene suficientes contenidos para responder perfectamente a su pregunta.

Leer estudios de casos de la vida real también puede ser útil. He compilado una lista de blogs / revistas que publican artículos impresionantes sobre arquitectura / desarrollo / gestión de software, especialmente cuando se trata de aplicaciones comerciales:

• Incremento número 2: Nube – Publicación de Stripe dirigida por Susan Fowler. Artículos sobre cómo los equipos construyen y operan sistemas de software a escala.
• Ingeniería | Primera ronda de revisión: lecturas largas de alto nivel que presentan estudios de casos de startups exitosas de todo el mundo. Principalmente sobre gestión de productos, habilidades de las personas y escalado.
• DHH – Signal v. Noise – excelente asesoramiento empresarial y de desarrollo de software del CTO de Basecamp, y el creador de Ruby on Rails, David Heinemeier Hansson
• Code as Craft: blog de ingeniería de Etsy, estudios de caso detallados sobre procesos de escala e infraestructura
• Producto | Heavybit Library: muchas sesiones interesantes de oradores (transcripciones incluidas) de compañías populares de herramientas para desarrolladores

Además, me gustaría compartir nuestra publicación. Reunimos un montón de lecciones aprendidas que obtuvimos trabajando con nuevas empresas de rápido crecimiento como equipo tecnológico. La serie trata sobre la creación de aplicaciones comerciales desde cero y se centra en aprovechar las modernas plataformas SaaS y API . Lo publicamos en Hackernoon.

HTH

Un programador sabe programar. Un desarrollador de software sabe cómo juntar piezas de código existentes como marcos y bibliotecas. Un ingeniero de software puede hacer esto en la pila. Un arquitecto de software ha hecho esto durante tanto tiempo que puede comparar y responder preguntas sobre combinaciones de bibliotecas y marcos. Incluso puede responder preguntas sobre cómo pueden escalar y qué conjunto de marcos son adecuados para las necesidades específicas de un cliente.

Típicamente, los prodigios de programación (genios jóvenes) o desarrolladores experimentados (mayores y experimentados) terminan como arquitectos; ¡si aún no se han convertido en emprendedores!

Si el término “ingeniero de software” se compara con “un programador y diseñador de software” y “arquitecto de software” con “un diseñador de sistemas de software”, entonces la siguiente explicación podría ayudar.

Un ingeniero de software se convierte en arquitecto cuando puede ver la imagen de cómo funciona el software dentro de un contexto más amplio o “el sistema de software”. Este sistema de software incluye las redes subyacentes, la integración con otros sistemas de software, el costo y el ciclo de vida, entre otras cosas. Esto requiere habilidades adicionales además de poder programar y diseñar software, que incluyen:

• La capacidad de comunicarse y trabajar con otras personas técnicas, con experiencia y conocimiento en diferentes dominios; y
• La capacidad de comunicarse y trabajar con otras personas no técnicas, que son responsables del presupuesto, el cronograma y la dirección / estrategia de un proyecto.

Hay otras habilidades, pero creo que estas dos son las más importantes.

Al convertirse en la “persona clave” en su EMPRESA que sabe todo sobre un sistema. Y ser un líder informal indiscutible entre colegas. Al escribir documentos sobre el análisis y los detalles de implementación técnica, no solo es la fuerza laboral, sino algo más.

Como dijo un amigo mío: los títulos de trabajo son locales . Las habilidades se pueden medir a nivel mundial.

Puedes llamar a todos los títulos geniales disponibles en tu empresa, nadie lo limita. Tenía un título de “arquitecto” en una pequeña empresa para justificar un salario más alto que el de los otros programadores (los salarios no eran realmente altos, incluso los míos). Eso es. Claro, yo era la persona clave y lo sabía todo, supervisaba a mis colegas de manera informal e hice locuras para implementar requisitos no estándar. Pero en otra compañía, el mismo conjunto de habilidades y experiencia podría llamarse “senior”, por ejemplo.

Una vez escuché que uno de los Arquitectos en Jefe le decía a los otros Arquitectos de Soluciones / Software: “No vengas con un problema. Ven a mí con cinco soluciones. Yo elegiré uno “.

Ahora, esa es la expectativa de un arquitecto.

Un arquitecto no es solo una persona técnica, es un

1. Líder: que influye en el equipo que trabaja con él y en el cliente final de una manera lo suficientemente conductiva como para implementar su solución. Tenga en cuenta aquí que ninguno de este equipo le informa directamente y, sin embargo, puede administrarlos a través de sus habilidades técnicas e interpersonales.
2. Un arquitecto es el que puede ver el punto de vista de los clientes y cuida los intereses de los clientes y aborda sus inquietudes. No está allí para implementar sus propias ideas técnicas a expensas de los clientes. Implementa soluciones que son rentables pero satisfacen los requisitos del cliente. Necesita encontrar el equilibrio adecuado y eso deja al cliente feliz.
3. Experiencia: por su larga experiencia, sabe qué funciona en qué situaciones y cuáles son los pros y los contras de las diferentes opciones. Él sabe cómo mitigar los riesgos. Puede guiar al equipo y tomar posesión cuando surja la necesidad.
4. Puede guiar al cliente en la dirección correcta y convencerlo de que la solución propuesta es la más adecuada dados los requisitos y circunstancias.

Finalmente, TOGAF dice que hay tres tipos de arquitectos:

1. Arquitecto de software: uno que diseña aplicaciones de software
2. Arquitecto de soluciones: alguien que diseña una solución de TI que podría tener múltiples aplicaciones integradas
3. Arquitecto empresarial: uno que diseña los procesos de negocio e informa directamente al CTO. Sus soluciones pueden incluir partes de TI y manuales.

El arquitecto de software se está convirtiendo gradualmente en un papel en declive, ya que en su mayoría es buscado solo por empresas nuevas. Y el papel de dos en uno que se está volviendo popular es ser un CTO. Un CTO necesita tener suficientes años de experiencia particular en la industria con un conocimiento profundo para diseñar un sistema e instruir al equipo de desarrollo para construir hacia esa dirección y muy a menudo involucrado en el motor principal de la codificación. Dejando la parte de la interfaz de usuario cosmética principalmente fuera y enfocar solo la determinación de UX. Todo ingeniero de software que tenga suficiente conocimiento de dominio para lo que está por construirse puede ser un buen arquitecto de software. Pero vas a conocer muy bien tu tema. No solo conociendo la parte de programación.

Para ser un buen arquitecto de software, necesita esa exposición de trabajar en diferentes tipos de sistemas, diferentes integraciones, diferentes plataformas … una vez dicho esto, no importa con qué tecnología se alinee, necesita tener una buena comprensión de los conceptos básicos y un sólido conocimiento básico.

Para desarrollar dicho conocimiento a partir de la experiencia, es necesario pasar por diferentes estudios de caso, pensar y sugerir soluciones a los problemas del mundo real que se plantean en Internet.

¿Has notado que todas las respuestas apuntan a diferentes direcciones?

Es por eso que un arquitecto de software no es fácil de definir, ni siquiera las personas que supuestamente saben están de acuerdo con una definición.

OMI, es solo un juego de palabras.

Ingeniero de software = desarrollador de software = arquitecto de software.

Aparentemente, las personas que piensan que los arquitectos de software solo están en películas de estilo matricial nunca han trabajado en una aplicación a gran escala en los últimos años o simplemente no han hecho su investigación.

Estoy de acuerdo en que puede haber programadores por ahí que puedan comprender un idioma en un tiempo récord, pero la mayoría de los codificadores son personas normales que tienen vidas normales fuera de la codificación. Tienden a ser buenos en algunos idiomas y plataformas y llevan su vida.

A medida que una industria madura, los especialistas se vuelven comunes. Estoy seguro de que el número de radiólogos en la década de 1910 habría sido 0. Al igual que ahora, hay múltiples especialidades de médicos como neurólogo, anatema, pediatría, etc. A medida que la industria madura, las personas se especializan. Esta es la forma en que los humanos optimizan su vida profesional y personal.

La industria de TI no es diferente a este aspecto. En los años 70 y 80, las aplicaciones eran complejas, pero no tenían muchas partes móviles, como en muchos idiomas, herramientas, etc. al igual que el Ford Modelo T frente al nuevo Toyota Camry que contiene altavoces Bluetooth. A medida que la industria de TI evolucionó, muchos especialistas se imaginaron.

Permítanme hacer todo lo posible para ilustrarlo con la analogía de un automóvil.

• Arquitecto empresarial: puede haber un diseñador general del automóvil que probablemente solo sepa que hay 5 tipos (solo un número) de motores de automóviles en el mercado y quiera un sexto tipo de diseño nuevo. Puede o no saber cómo funciona el motor puede diseñarse en un nivel muy detallado, por ejemplo: especificaciones del pistón, tipos de bujías, etc., pero sabe que se puede hacer.
• Arquitecto de aplicaciones: este chico sabe cómo diseñar el motor en detalle e informará a los codificadores (diseñadores individuales). Para trabajar en modelos que reflejan todas las especificaciones técnicas, como el tamaño del pistón, etc.

Quiero enfatizar que, por favor, no se asuste de la profesión de codificación y piense que hay “codificadores de estilo matricial” y que solo se ganan la vida. La mayoría de los codificadores están especializados y esta es la forma óptima de dirigir la industria.

El ingeniero de software a menudo es solo un título glorificado de “programador”, lo que puede indicar que es un poco mayor. El arquitecto de software probablemente encaja aproximadamente con un líder de equipo de alto nivel que tiene la responsabilidad de diseñar la arquitectura general del proyecto. Una persona con experiencia en soluciones de ingeniería de software también puede integrarse en el arquitecto de software y en la ingeniería.