Post N°4 - Arquitectura de Software: cómo convertirse en una o un arquitecto

¡Hola! En este nuevo artículo voy a tratar de plasmar una serie de conceptos, que bajo mi consideración, son cruciales para lograr ser una o un Arquitecto de Software exitoso. Abordaré temas y términos que seguro serán de tu agrado e interés; aunque, adelanto que en un principio te podrían llegar a sonar un tanto confusos. De todas formas, los iré explicando conforme avances con la lectura. También, hay una serie de documentos que dejé hace unas semanas en esta misma sección, que podrán orientarte un poco más si aún tenés dudas sobre qué es la Arquitectura de Software y cuáles son las funciones principales de una o un arquitecto.

Ahora si, empecemos!

Más allá del código:

Cuando una persona inicia en el desarrollo de software es muy probable que su interés va a estar fuertemente ligado a lo que se denomina profundidad técnica. Es decir, ser una o un experto en algún lenguaje de programación, ya sea Javascript, C++, Elixir, PHP, Python, Ruby, etcétera., que supone poseer una base de conocimientos muy sólidos en cosas como frameworks, funciones especiales, palabras reservadas, versiones, librerías, entre otras. Pero al momento de hablar de la formación de una o un Arquitecto de Software, la cuestión es diferente. El objetivo consistirá en tener un conocimiento amplio de múltiples herramientas, y no tanto en la especialización de una sola.

En relación con lo último mencionado del párrafo anterior, si al igual que yo querés convertirte en Arquitecto/a de Software, debés saber que es fundamental estar al tanto de distintas tecnologías, plataformas, ambientes y lenguajes. Me refiero, existe Mobile - Kotlin, Cordova, Swift, Rust, Ionic, Java, React Native, Flutter, x.. -, lo que se conoce como Aplicaciones de Escritorio - Python, C, Electron JS, .NET, PHP(GTK), C#, x...-, servicios Cloud - AWS, Digital Ocean, Google Cloud, Azure, Salesforce, x...-, el desarrollo de contenedores para desplegar aplicaciones - Kubernetes, Amazon Fargate, OpenShift, Docker, Rancher, x... -, base de datos - Oracle, MySQL, MariaDB, PostgresSQL, x... -, seguridad informática - Reverse Engineering, Sniffing, SQL Injection, Brute-Force Attack, x... -, y más escenarios y entornos de los cuales hay que tener noción de cómo operar en ellos, comprendiendo la importancia de cada uno.

Ahora bien, de la mano del siguiente ejemplo hay que entender que si una o uno como desarrollador trabaja con React, Vue, Angular, y desea incrementar su amplitud técnica, por lo que opta en aprender - que no está mal - a implementar Svelte para sus proyectos, no sería lo correcto. Sería, bajo este esquema, más coherente optar por conocer otras tecnologías como Python, Bash, C++, y salir del área de confort.

Más allá de lo funcional:

En varias ocasiones ya he comentado sobre las características de arquitectura, conocidas como los atributos de calidad. En pocas palabras, esta expresión significa qué es lo que se debe ponderar y aplicar, para que un proyecto progrese de la manera más eficiente, de modo que no solo cumpla con todos los parámetros establecidos y su propósito, sino que posteriormente se pueda mantener, añadir o quitar funcionalidades, y su rendimiento sea el más óptimo. Entre los atributos de calidad, destacaré algunos:

• Usabilidad: Se realizan pruebas para ver qué tan sencillo resulta utilizar la interfaz de usuario.
• Testabilidad: Si la capacidad de prueba del artefacto de software es alta, entonces es más fácil encontrar fallas en el sistema (si las tiene) mediante pruebas.
• Seguridad: Comprobar las credenciales de los usuarios que acceden a la aplicación, verificar que las personas autorizadas puedan realizar ciertas acciones o cambios, etc.
• Robustez: Óptimo estado asegurado a mediano y largo plazo. No surgen errores aleatorios y puede ser modificado sin que ocurran problemas.
• Rendimiento: El comportamiento del sistema durante un período determinado de tiempo. Por ejemplo, la latencia que significa cuánto es el tiempo de respuesta de una acción. Otro sería la capacidad del canal, que quiere decir el número de eventos que ocurren en un momento específico.
• Escalabilidad: Es la capacidad del sistema para manejar aumentos de carga sin disminuir el rendimiento. Dicho de otra forma, se mide la capacidad del sistema para operar, por ejemplo, con un mayor volumen de datos. Para ser más explícito, existe la escalabilidad horizontal y vertical. Por un lado, la primera hace alusión a trabajar con múltiples servidores trabajando como un todo. Se crea una red de servidores conocida como cluster, con la finalidad de repartirse el trabajo entre todos nodos del cluster. Cuando la performance se ve afectada con el incremento de usuarios, se añaden nuevos nodos, de esta forma a medida que son requeridos, más y más nodos son agregados. Dificultad para esto: alta. Por otro lado, la escala vertical se refiere a la utilización de más recursos físicos. Como puede ser mayor cantidad de unidades de almacenamiento, procesadores más eficientes, incorporar un mejor sistema de refrigeración, etc. El software con este caso no se ve afectado.
• Fiabilidad: Riesgo de fallo de software y la estabilidad de un programa cuando se expone a condiciones inesperadas. Un software fiable tiene un tiempo de inactividad mínimo, buena integridad de los datos y no hay errores que afecten directamente a los usuarios.

Y podría seguir, pero sino esto se hace interminable! Acá dejo unos cuantos más para que investigues y pienses cuáles aplicarías y cuáles sacrificarías. ¿Por qué "sacrificio"? Porque cuanto más atributos un proyecto posea, la complejidad crecerá de forma exponencial.

Agilidad - desplegabilidad - disponibilidad - facilidad de desarrollo - accesibilidad - interoperabilidad - mantenibilidad - modificabilidad - portabilidad - evolución - extensabilidad - elasticidad.

Además de tener en claro lo comentado anteriormente, es clave entender cómo funcionan los patrones de arquitectura y los patrones de diseño. Si una aplicación posee la arquitectura y el patrón correcto, será mucho más fácil detectar inconsistencias y desvíos que podrían afectar el buen desempeño. Cabe resaltar que los patrones de diseño nos van a ayudar a estructurar mejor las soluciones.

Otro aspecto relevante a tener en cuenta, es cómo implementar herramientas de integración continua y despliegue continuo.

Hace unos pocos años aparecieron los DevOps, quienes surgieron para participar tanto en entornos de desarrollo como en la aprobación manual del buen rendimiento de los distintos componentes y funcionalidades de las apps, y a su vez la supervisión de operaciones automatizadas, cuyo fin es el mismo: evaluar que todo esté ok. Esto significa hacer pruebas unitarias durante todo el ciclo de vida de la aplicación. Una vez cubiertos todos los criterios definidos, se pasa a producción. Es decir, los usuarios pueden utilizar la aplicación. Herramientas hay muchísimas. Algunas de ellas son: Jenkins, GitLab, TeamCity, Drone, ContainerOps, Travis CI, etc. Saber utilizar cualquiera o varias, más cómo mejorar ciertas cargas operativas es muy importante. En otro post explicaré con más detenimiento esto.

No pasar por alto el desarrollo:

Opinión personal: saltarse este paso, es cómo decir que uno es chef profesional, pero que nunca preparó ni siquiera una ensalada.

Se podrá ser flexible, pero no se puede saltar ningún paso en la Arquitectura de Software, mucho menos este punto. Terminar el instituto o la carrera universitaria, no significa que ya seas arquitecto/a. Es imprescindible tener experiencia. Lo ideal, full-stack (conocimientos en Front y Back). Hay que pensar que esto es crítico, ya que lo que uno crea y diseña va a afectar a un equipo de desarrollo. Recordar:

• Haber desarrollado aplicaciones, independientemente de los lenguajes empleados, permitirá conocer como piensan otras y otros desarrolladores y cómo abordan los problemas.

Habilidades blandas:

Conocidas también como Soft Skills, son parte fundamental de la formación de una o un arquitecto de software. ¿Y en qué consiste esto? Dejo las siguientes características:

• Saber trabajar en equipo.
• Ser pragmático/a.
• Ser habilidoso/a en cuanto a negociación.
• Capacidad de abstracción.
• Liderazgo.

Un ejemplo adicional, sería la buena comunicación. Saber explicarle a alguien que no posea conocimientos técnicos. - Aún trabajo en ello! -

Conclusión:

Lograr ser una o un arquitecto de software no es tarea sencilla, hay muchos pasos y experiencias por las cuales se deben pasar. Si bien en el último punto no hice demasiado hincapié, en relación a las habilidades blandas, creo que es uno de los aspectos más importantes. Lo demás, todo a su tiempo. Es cuestión de mucha práctica, de ensayo y error, y paciencia.

Esto igual, es el comienzo.

En fin, ¡gracias por llegar hasta acá! Nos vemos en el siguiente post.