3/5 Arquitectura
Capacidades necesarias en torno a la arquitectura para un mejor desarrollo de software.
Típicamente las discusiones en torno a la arquitectura tienden a enfocarse en el uso de tal o cual herramienta o tecnología. ¿Debería la empresa adoptar una solución de microservicios o arquitectura serverless ? ¿Usaremos Kubernetes o Apache Mesos?¿Qué framework o lenguaje de programación será el estándar de la empresa? Perdón pero, me parece que todas ellas son preguntas incorrectas...
Definir qué herramienta o tecnología deberá utilizar un equipo es irrelevante si las personas que la usarán la detestan. O sería intrascendente si la herramienta escogida no aporta en el cumplimiento de los objetivos que esperamos para la empresa.
14. Loosely Coupled Architecture
Lo que realmente es importante es que los equipos pueden realizar los cambios a sus productos y servicios sin depender de otros equipos o sistemas. Los arquitectos deben apoyar y colaborar a los equipos de desarrollo para alcanzar los objetivos de la empresa, proporcionándoles las herramientas y tecnología necesaria que les permita alcanzar dicha meta.
Por lo demás, los objetivos que deberían estar buscando las áreas de arquitectura son en torno a la escalabilidad, resiliencia y eficiencia. Y todo eso se logra en la medida en cómo se comunican los componentes y servicios entre sí.
Algunas prácticas comunes de los arquitectos deben ser:
- Definir los principios y prácticas recomendados para el desarrollo.
- Sugerir la tecnología adecuada para los proyectos estratégicos. O bien de qué tecnologías deberían abstenerse. Ojo, no se está imponiendo, sólo recomendando.
- Conocer y promover nuevas tecnologías que sean un incentivo para los MVP o experimentos.
- Generar instancias de colaboración con los equipos de desarrollo en donde se pueda dialogar y comentar abiertamente como se han tomado las decisiones de arquitectura.
- Tener todo el contexto del negocio para tomar buenas decisiones. Esto implica conocer en profundidad los procesos y flujos de negocio.
- Escribir documentación —RFC o RFC— referente a las decisiones que se tomaron para el diseño de la solución.
- Entregar ayuda y apoyo a los distintos equipos de desarrollo.
Por último, destacar que el costo es un aspecto sumamente relevante. No tiene sentido construir un tanque para matar una mosca. El diseño de la arquitectura debe ser proporcional al desafío.
Si implementamos una arquitectura independiente del resto de los sistemas, suceden 2 cosas. Primero, se optimiza los pasos a producción y aumenta la frecuencia y estabilidad del servicio, y a la vez disminuye el burnout del equipo. Segundo, el número de profesionales podrá aumentar, y así también aumentará la productividad.
15. Equipos empoderados
En la mayoría de las grandes empresas en Chile, los ingenieros deben escoger las herramientas y el framework de una lista de tecnologías pre-aprobadas. Esta lógica tiene los siguientes propósitos —loables pero erróneos—:
- Reducir la complejidad de los ambientes de desarrollo.
- Asegurar que todas las capacidades para administrar la tecnología estén disponibles en la empresa.
- Estandarizar procesos de capacitación, mantención y documentación. Lo mismo para la configuración de ambientes y la gestión de infraestructura.
- Asegurar que toda la tecnología cumple con los criterios de seguridad y licenciamiento.
Sin embargo, existe una gran desventaja a este modelo de “camisa de fuerza”: impide que los equipos escojan las tecnologías adecuadas para el cumplimiento de los objetivos, y sobre todo, inhibe la innovación y experimentación con nuevas tecnologías que permitan resolver sus problemas.
El estudio realizado por el equipo de Nicole demostró y validó que la elección de la tecnología es una aspecto clave del trabajo técnico. Cuando los equipos pueden decidir que herramientas van a utilizar, contribuyen a mejorar el rendimiento del desarrollo de software, y por ende, en el rendimiento de la empresa. También otros estudios sugieren lo mismo, las ventajas de delegar la elección de la tecnología a los equipos supera sus desventajas.
Ahora bien, dicho lo anterior, sí hay un plano de estandarización necesario: la infraestructura. Facilita mucho la gestión de la operación de las aplicaciones una definición común en torno a construcción de los contenedores, un formato común de registros de errores, un formato común de “salud” de la aplicación, etc.
Continuación ...
Si quieres seguir leyendo esta serie de 5 posts, a contiuación seguimos con las 4 capacidades sobre el producto y los procesos.
Nicolás Mella
