// Technical Lead · Solution Architecture · Software Engineering · Chile
const johnny = {
};
Construyo software y lidero decisiones técnicas sobre sistemas productivos, soluciones regionales y plataformas que deben evolucionar sin detener el negocio.
Mi trabajo combina arquitectura, desarrollo hands-on, modernización, seguridad, deuda técnica y acompañamiento de equipos.
Soy Technical Lead y Software Engineer con más de una década construyendo y operando software en producción.
Durante los últimos años mi trabajo evolucionó desde el desarrollo y liderazgo de equipos hacia responsabilidades cada vez más transversales: diseño de capacidades regionales, modernización de plataformas, assessments técnicos, seguridad, estrategia de deuda técnica y definición de estándares de ingeniería.
Me interesa especialmente la intersección entre arquitectura e implementación. No quiero alejarme del código para hacer arquitectura: prefiero entender los sistemas desde su comportamiento real, sus restricciones operacionales y las decisiones que condicionan su evolución.
Mi siguiente etapa profesional está orientada a profundizar en Solution Architecture y liderazgo técnico transversal, manteniendo una base hands-on.
Ports and adapters no es un patrón para tutoriales. Es una forma de impedir que decisiones de infraestructura contaminen reglas de negocio que deberían sobrevivir a un cambio de proveedor, framework o mecanismo de persistencia.
La deuda técnica puede ser una decisión válida. Lo peligroso es la deuda que nadie conoce, nadie mide y nadie puede priorizar. Prefiero hacer explícito qué estamos sacrificando, cuánto cuesta y qué condición debería gatillar su resolución.
Microservicios, eventos y componentes independientes tienen un costo operacional. Prefiero empezar con límites claros y distribuir cuando existen razones de escala, autonomía, resiliencia o ownership que justifiquen pagar ese costo.
Un diseño perfecto en un diagrama puede ser incorrecto en producción. Cuando una decisión enfrenta pureza conceptual contra consistencia, trazabilidad o capacidad de recuperación, prefiero optimizar para el comportamiento real del sistema.
Timeouts, retries, idempotencia, observabilidad y degradación controlada no son detalles posteriores. Son parte de la arquitectura.
Una decisión arquitectónica debe poder observarse en contratos, código, despliegues, métricas y operación. Si solo existe en una presentación, todavía no es arquitectura implementada.
Un TL no debería convertirse en el único capaz de responder preguntas difíciles. Documentación, automatización, mentoring, PR reviews y diseño colaborativo deben hacer al equipo progresivamente más autónomo.
No la uso como autocompletado. Exploro y propongo antes de escribir código, documento decisiones no obvias como ADR, y someto cada cambio a revisión acotada antes de un PR. El criterio técnico sigue siendo mío.
Diseño boundaries de dominio, contratos, estrategias de integración, modelos de persistencia y decisiones arquitectónicas considerando restricciones reales de operación, seguridad y evolución.
Transformo sistemas legacy y ecosistemas fragmentados mediante planes incrementales, estrategias de migración, automatización y reducción progresiva de riesgo.
Analizo productos y plataformas desde arquitectura, seguridad, deuda técnica, operación, documentación y capacidad del equipo, convirtiendo hallazgos en roadmaps priorizados.
Acompaño equipos mediante diseño, mentoring, PR reviews, dojos y resolución de problemas complejos. Busco aumentar autonomía, no centralizar conocimiento.
Realizo revisiones técnicas y post-incidente, priorizando vulnerabilidades, autenticación/autorización, secretos, datos sensibles, testing, observabilidad y mantenibilidad.
Diseño de una capacidad regional para consultar productos sobre múltiples fuentes heterogéneas y países, entregando un contrato consistente a sus consumidores. El diseño priorizó adapters por origen, aislamiento por tenant, resiliencia, contratos versionables y evolución incremental, evitando distribuir prematuramente una solución que aún podía conservar boundaries claros dentro de una arquitectura modular.
Demuestra: integración · multi-tenancy · resiliencia · API design · decisiones de distribución.
Diseño de una capacidad regional de almacenamiento abstraída del proveedor cloud, utilizando Valet Key para transferencia directa, metadata persistente y procesamiento asíncrono. La arquitectura separa control plane y data plane y utiliza patrones de consistencia como Transactional Outbox.
Demuestra: cloud architecture · seguridad · async processing · consistencia · portability.
Diseño de una capacidad regional de notificaciones orientada a eventos, con contratos estándar, aislamiento multi-tenant y publicación confiable. El objetivo fue evitar que cada producto desarrollara una implementación distinta para resolver el mismo problema transversal.
Demuestra: event-driven architecture · contracts · platform thinking · multi-tenancy.
Diseño de un modelo regional canónico para consolidar implementaciones existentes de gestión de tareas. La estrategia utiliza state machine, reconciliación y migración incremental tipo Strangler Fig para reducir riesgo durante la transición.
Demuestra: domain modeling · legacy modernization · migration strategy · distributed systems.
Assessment transversal de infraestructura, datos, observabilidad, servicios, librerías compartidas, seguridad y documentación. El resultado no fue una lista de problemas, sino un conjunto de habilitadores, estándares y líneas de acción para reducir deuda de forma repetible entre equipos.
Demuestra: arquitectura transversal · technical strategy · governance · prioritization.
Evaluación de dominios tecnológicos considerando producto, arquitectura, operación, demanda, UX, seguridad, documentación y capacidad. Los hallazgos se transforman en planes de corto, mediano y largo plazo con métricas, responsables y mecanismos de priorización.
Demuestra: technology strategy · product thinking · governance · portfolio.
Auditoría técnica post-incidente sobre una SuperApp mobile compartida por múltiples aplicaciones. El análisis separó riesgo inmediato y deuda estructural, priorizando exposición de secretos y PII, almacenamiento, autenticación/autorización, logging, testing y mantenibilidad.
Demuestra: application security · code review · risk prioritization · engineering quality.
Liderazgo técnico de soluciones regionales y trabajo transversal sobre productos internos de retail. Mi alcance combina desarrollo hands-on, diseño de arquitectura, modernización, assessments técnicos, seguridad y acompañamiento a equipos.
Ingresé como Software Engineer y progresivamente asumí liderazgo técnico sobre módulos regionales.
Lideré el diseño inicial de una nueva plataforma para estaciones de servicio basada en Azure, DDD y Event-Driven Design, coordinando decisiones con stakeholders técnicos y funcionales.
Modernización y regionalización del core de facturación, aplicando arquitectura hexagonal a la integración por país.
Co-lideré la evolución técnica de ClassTrack, plataforma SaaS de gestión curricular utilizada por aproximadamente 200 colegios y 50.000 estudiantes.
Earlier Experience
Modernización de plataforma educativa y migración de infraestructura a AWS.
Modernización de sistemas internos, adopción de Git/Jira y evolución de ERP.
Desarrollo de aplicaciones web y soluciones para distintos clientes.
Ingeniería que se puede defender
Escribo sobre arquitectura, decisiones técnicas, modernización, herramientas de ingeniería y aprendizajes obtenidos trabajando con sistemas reales.
Leer en Medium →> Consultoría de Arquitectura & Engineering
Trabajo con equipos que ya construyen software pero necesitan una segunda mirada para enfrentar modernizaciones, deuda técnica, diseño de sistemas, seguridad o decisiones arquitectónicas complejas.
Áreas donde puedo aportar
Desarrollo
Trabajo en proyectos de desarrollo de cualquier tamaño: desde un formulario o un ajuste puntual hasta una plataforma completa. Aplico el mismo criterio de arquitectura sin importar la escala.