Cómo hice la transición de desarrollador a arquitecto de software

Cuando comencé mi carrera en Ciencias de la Computación en una gran empresa de consultoría, rápidamente identifiqué algunos roles comunes dentro de la empresa. Hicimos que los desarrolladores de backend se inclinaran sobre sus teclados produciendo código a prueba de fallas para nuestros clientes, los desarrolladores de frontend leyendo sobre los últimos marcos de JavaScript, los consultores de administración caminando por la oficina hablando en voz alta sobre su última sesión de gimnasio.

Y luego tuvimos a los arquitectos. Algo así como un cruce entre los desarrolladores de backend y los consultores de gestión. Algunos vestían trajes y solo asistían a reuniones, y algunos estaban ocupados dibujando diagramas complejos de sistemas que hablaban entre sí.

Después de trabajar para varios clientes diferentes como desarrollador de backend y desarrollador de frontend, rápidamente me di cuenta de la necesidad del rol de arquitecto. El arquitecto estuvo allí para asegurarse de que lo que desarrollamos se ajustara a los objetivos a largo plazo de nuestro cliente y de que diseñáramos nuevas funciones de forma escalable y segura. Para mí estaba claro que para poder establecer estas pautas y decisiones de alto nivel, se necesitaba un cierto nivel de experiencia y conocimiento.

Cuando terminó mi última asignación como desarrollador de backend, mi gerente se acercó a mí con una asignación. Una gran empresa de telecomunicaciones estaba creando una aplicación y su arquitecto acababa de dimitir de la empresa. Necesitaban a alguien rápido. Me preocupaba mi falta de experiencia en el puesto de arquitecto, pero el desafío era tentador. Al final, dije que sí.

Instantáneamente fui arrojado a un montón de problemas urgentes. El cliente había solicitado un diseño de alto nivel de una implementación de chat de video. El equipo de backend no tenía un entorno de desarrollo en ejecución. El equipo de frontend aún no había comenzado a integrarse con el backend, ya que no había ningún entorno activo.

Por decir lo menos, tuve un comienzo desafiante. Usando las habilidades que había adquirido durante mis años como desarrollador de backend y algunas largas noches de conferencias telefónicas, pude solucionar los problemas más urgentes y entregar el proyecto a tiempo.

Durante esa primera asignación como arquitecto, adquirí muchas habilidades y experiencia. Estas son las lecciones clave que creo que debería saber antes de pasar de desarrollador a arquitecto.

¿Qué hace un arquitecto?

Anteriormente, describí a los arquitectos como asistentes a muchas reuniones y dibujando diagramas. Pero, ¿qué hacen realmente en las reuniones y qué diagramas están dibujando? Si bien esas no son, por supuesto, las únicas actividades que realiza un arquitecto, usémoslas como punto de partida para profundizar en el día a día de un arquitecto.

El trabajo principal de un arquitecto es establecer la hoja de ruta técnica de alto nivel de la aplicación en la que están involucrados en el desarrollo. Para poder hacer eso, el arquitecto necesita interactuar con una serie de partes interesadas para comprender sus necesidades y traducirlas en requisitos técnicos. Las partes interesadas pueden ser clientes, miembros del equipo de desarrollo o gerentes de producto. Aquí es donde suelen entrar las reuniones.

Entonces, ¿qué pasa con estos diagramas? Los requisitos técnicos que los arquitectos deciden deben ser documentados y comprendidos por los desarrolladores que los implementarán.

Si bien el texto puede ser un buen punto de partida, los diagramas y otras herramientas visuales son una muy buena forma de expresar cómo debería funcionar algo. A menudo, ve diagramas como mapas sobre cómo los sistemas interactúan entre sí o diferentes tipos de diagramas de flujo que representan un caso de uso en una aplicación.

Como ya comprenderá, las habilidades de comunicación son muy importantes para un arquitecto. En la siguiente sección, profundizaremos un poco más en las habilidades que necesita como arquitecto.

¿Qué necesita saber como arquitecto?

Si bien hay muchas cosas que necesita saber sobre el desarrollo de software para asumir el rol de arquitecto con confianza, hay algunas áreas en las que creo que debería concentrarse.

Comunicación

La habilidad más importante que necesita como arquitecto es la comunicación. Debe poder comunicarse sobre problemas técnicos profundos con el equipo de desarrollo, así como explicar conceptos técnicos en un nivel superior a los clientes u otras partes interesadas.

Para comunicarme de forma eficaz, me aseguro de adaptar el lenguaje que utilizo para el público objetivo. El equipo de desarrollo probablemente sepa qué es una API, aunque es posible que eso no quede completamente claro cuando habla con un cliente. Por lo tanto, siempre me aseguro de preparar material como documentación o ejemplos de código para reuniones o tutoriales basados ​​en los participantes. Al hablar con los desarrolladores, puede ser más fácil mostrarles un fragmento de código, mientras que la documentación de alto nivel puede ser suficiente para el personal no técnico.

Otra herramienta que necesitas dominar son los diagramas. Algunos desarrolladores desaprueban a los arquitectos y dicen que solo dibujan recuadros con un par de líneas entre ellos y esperan que los desarrolladores resuelvan el resto. Si bien eso puede ser cierto en algunos casos, la capacidad de visualizar una solución es muy importante para transmitir su punto de vista tanto a los desarrolladores como a los demás.

Algunos diagramas que son particularmente útiles son los diagramas de relaciones de bases de datos, los diagramas de secuencia y los diagramas de arquitectura del sistema. Para mejorar en el dibujo de estos, recomiendo comenzar con la creación de diagramas para una parte existente de una aplicación y usarlos para explicar cómo funciona a un desarrollador. Esto también puede difundir conocimientos y funcionar como documentación en el futuro.

Mejores prácticas

A veces, la gente le preguntará cómo hacer algo de la mejor manera posible y esperará que encuentre la mejor solución posible. Diseñar una solución desde cero no es fácil, ya que cualquier problema dado suele tener muchas soluciones diferentes. En situaciones como esta, las mejores prácticas vienen al rescate.

Dado que los desarrolladores de software son solucionadores de problemas por naturaleza, tenderán a aceptar estándares ampliamente aceptados como mejores prácticas. Si alguien se acerca a usted con un problema, asegúrese de buscar las mejores prácticas para ese dominio y utilícelas al máximo. No tiene sentido inventar soluciones a problemas que ya se han resuelto de forma fiable durante muchos años.

Me viene a la mente una historia de mi primera asignación como arquitecto: una parte interesada del proyecto me llamó y afirmó que había habido una brecha de seguridad en la aplicación que estábamos construyendo. Los detalles no estaban muy claros, pero aún quería saber si podría haber sido posible una violación de la seguridad. Para calmar al cliente, revisé la colección de OWACP de los principales riesgos de seguridad para las aplicaciones web y cómo habíamos mitigado cada riesgo con una práctica recomendada.

El dominio de seguridad es siempre una prioridad máxima y, afortunadamente, existen muchas mejores prácticas documentadas con respecto a la seguridad en las que puede apoyarse cuando se discute. Para comenzar a aprender más sobre la seguridad desde la perspectiva de un desarrollador, recomiendo memorizar el Top Ten de OWACP, así como leer “5 conceptos de seguridad que todo desarrollador debería entender” de Justin Boyer.

Para encontrar las mejores prácticas en otros dominios de la ingeniería de software, hay toneladas de recursos accesibles en línea. Si prefiere un libro para obtener una descripción más completa de las mejores prácticas de ingeniería de software, puede elegir las mejores prácticas de ingeniería de software de Capers Jones.

API

Cuando se habla de arquitectura de sistemas, a menudo se habla de cómo se comunican los diferentes sistemas entre sí. Por lo general, la comunicación de sistema a sistema se realiza mediante el uso de API.

Eso significa que es muy importante para usted, como arquitecto, saber cómo diseñar API y cómo integrar diferentes API entre sí. Trabajar con API significa encontrar soluciones para analizar datos, almacenar datos de diferentes fuentes, encontrar las API correctas para integrarlas, etc.

Mi experiencia trabajando mucho con API más tarde me llevó a crear un inicio de herramienta de API simulado donde pude aplicar todo mi conocimiento para construir mi propio producto.

Bredes asic

Cuando se habla de cómo se comunican los sistemas entre sí, es importante saber cómo hacerlo de forma segura. Ahí es cuando entra en juego la creación de redes. ¿Cómo accedemos al Sistema A detrás del Firewall Z? ¿Qué puertos necesitamos abrir? Estas son preguntas típicas con las que debe lidiar cuando se integra en sistemas empresariales.

Por lo general, solo necesita comprender los conceptos de direcciones IP, firewalls y subredes para poder discutir asuntos relacionados con la red a nivel de arquitectura. Sin embargo, puede depender del tipo de infraestructura en la que se ejecuta la aplicación que está creando. Antes de una asignación, siempre trato de tomarme un tiempo para familiarizarme con la infraestructura que se utiliza.

Para comenzar a aprender redes básicas, recomiendo tomar una clase como redes para desarrolladores web. Además, es ventajoso comprender las arquitecturas con una subred pública para la aplicación pública y una subred privada para el servidor de base de datos. Esto se describe bastante bien por Amazon Web Services en su documentación de redes.

¡Entonces eres arquitecto! ¿Ahora que?

Por supuesto, su trayectoria profesional no ha terminado solo porque sea arquitecto. Hay múltiples caminos que puedes tomar después de unos años como arquitecto. Una forma de hacerlo es acercarse a la administración y convertirse en arquitecto empresarial. Este rol generalmente implica la creación de estrategias de TI dentro de una empresa a un nivel superior, como decidir en qué tecnología invertir.

También puede avanzar más hacia un rol centrado en el producto en el que decide qué funciones priorizar y crear diseños de soluciones para ellas. Después de mi primera asignación como arquitecto, asumí un puesto similar en una empresa de telecomunicaciones.

Los roles centrados en el producto generalmente requieren experiencia con el producto en el que está trabajando. En mi caso, había estado involucrado con el producto durante aproximadamente un año antes de tener la confianza suficiente para asumir un rol de arquitectura más centrado en el producto.

La arquitectura empresarial, por otro lado, brinda muchas oportunidades para obtener una certificación para demostrar sus habilidades. Uno de los certificados de arquitectura empresarial más reconocidos es The Open Group Architecture Framework (TOGAF), que todavía tengo que asumir.

Estás en tu camino

Ser arquitecto es un desafío y requiere mucho conocimiento y experiencia. Al mismo tiempo, no necesita ser un experto en ningún área en particular del desarrollo de software para convertirse en uno. Es mejor tener una comprensión amplia del desarrollo de software y poder comunicar esa comprensión de manera efectiva respaldada por las mejores prácticas.

La comunicación se realiza mejor adaptando el mensaje a los receptores y utilizando herramientas visuales.

Se deben utilizar las mejores prácticas siempre que sea posible para evitar reinventar la rueda al diseñar nuevas soluciones.

Las API son necesarias cuando necesita hacer que los sistemas se comuniquen entre sí.

La creación de redes es algo que debe comprender para integrarse con los sistemas de forma segura.

Si utiliza esta guía para orientarlo en la dirección correcta, estará en camino de convertirse en arquitecto. ¡Les deseo la mejor de las suertes en sus proyectos futuros!