Arquitectura de TI: De los monolitos a los microservicios y el pensamiento sistémico
El paso hacia la arquitectura no suele planificarse: surge del crecimiento de los proyectos. Cuando un equipo ya no puede con la carga, y las decisiones deben mantenerse durante años, un desarrollador naturalmente evoluciona hacia la arquitectura. Philippe Delgado, arquitecto de fintech, comenzó en los años 90 con mantenimiento de sistemas; apenas seis meses después de su primer trabajo, asumió la totalidad del proyecto. Esto lo obligó a pensar más allá de las solicitudes inmediatas y centrarse en la evolución a largo plazo.
La educación superior proporciona una base para gestionar la complejidad: las matemáticas enseñan la abstracción—pasar de ideas a implementación. Aunque las universidades rara vez enseñan arquitectura directamente, cultivan el pensamiento sistémico. Libros de McConnell, patrones de diseño GoF y el trabajo de Fowler sentaron las bases mediante refactorización y estructura de código.
Conferencias como Highload++ desde 2007 cierran la brecha entre teoría y práctica: conversaciones con desarrolladores de distintas pilas tecnológicas revelan la distancia entre ideales y realidad.
El rol del arquitecto en el equipo
Un arquitecto es un papel de coordinación, no solo un título. En los años 90, los arquitectos principales gestionaban la alineación global. Hoy en día, se trata más bien de ingenieros principales o de nivel alto—responsables del sistema completo, no solo de un módulo.
En proyectos complejos como el procesamiento de tarjetas o versiones tempranas de Yandex.Money, los arquitectos anticipan escenarios, equilibrando rendimiento y restricciones del dominio. El orgullo viene al ver sistemas en producción resistir estrés real. Los startups enseñan adaptabilidad, pero muchos nunca llegan a lanzar.
Principales desafíos:
- Brecha entre arquitectura teórica y requisitos reales.
- Adaptarse al cambio sin reconstruir todo.
- Equilibrar velocidad y escalabilidad.
Los arquitectos enfrentan tareas repetitivas, no siempre delegadas. La concentración es clave: 2 horas para entender el contexto, 3 para reflexionar, a veces días para resolver.
Monolito frente a microservicios: el contexto define la elección
La decisión entre monolito y microservicios depende de la etapa del proyecto y la dinámica del equipo. Los monolitos convienen en fases iniciales cuando un equipo estrecho trabaja juntos. Los microservicios tienen sentido cuando hay conflictos de requisitos y se necesita despliegue independiente. No hay respuesta universal—las decisiones evolucionan con el crecimiento de la complejidad.
Los arquitectos deben comprender la implementación: un diagrama 'hermoso' falla sin conocimiento de la pila. Un arquitecto de soluciones puede omitir el código, pero un arquitecto de software necesita experiencia práctica con frameworks—para prever costos e riesgos de implementación.
Habilidades y herramientas del arquitecto
El pensamiento sistémico se afina con la práctica—ver el sistema desde arriba y desde múltiples ángulos. Disfruta la responsabilidad y la autonomía: tomar decisiones que impactan la calidad durante años.
Odia la rotación: menos código, más rutina. Cambiar de proyecto es difícil—depende mucho de la familiaridad con el dominio.
Habilidades clave para roles intermedios/senior:
- Moverse entre niveles abstractos.
- Predecir la evolución del sistema.
- Contabilizar el costo de implementación.
- Gestionar requisitos contradictorios.
- Enfocarse en problemas complejos.
Se prefieren libros sobre videos: el texto permite repasar y construir lógica lineal. Los videos son excelentes para demostraciones de código, pero no para comprensión profunda.
Lecturas recomendadas para el pensamiento arquitectónico
Para desarrollar mentalidad arquitectónica:
- Harry Potter y los métodos de la racionalidad (Yudkowsky) — racionalidad y probabilidad.
- Libros de TRIZ, por ejemplo, Un mes bajo las estrellas de la fantasía.
- La paradoja de Prometeo (Mesterházi) — análisis crítico.
- Obras de Lotman sobre semiótica.
- Sun Tzu con comentario de Conrad.
Estos textos entrenan el pensamiento analítico sin ataduras tecnológicas.
Lo que realmente importa
- La arquitectura trata de gestionar la complejidad, no de dibujar diagramas.
- El salto de programar a arquitectura ocurre con el crecimiento de la responsabilidad.
- Experiencia con la pila es obligatoria para la arquitectura de software.
- El pensamiento sistémico mejora con práctica y lectura.
- ¿Monolito o microservicios? Elige según el contexto del proyecto.
— Editorial Team
Aún no hay comentarios.