---
# System prepended metadata

title: Guía para ser Architecture Owner (AO)

---

# Guía para ser Architecture Owner (AO)
## Qué es el AO
El rol de Architecture Owner es guiar la creación y la evolución de la arquitectura de la solución del proyecto de un equipo. El Architecture Owner **no** es el único responsable de la arquitectura, pero si es responsable de liderar las discusiones técnicas que brindaran las alternativas que existen para la solución del proyecto. El AO debe tener conocimiento sobre patrones, frameworks, así como un sólido entendimiento del dominio de negocio de las soluciones construidas.

## Labores para con las personas
* Capacitar a los demás en el uso de herramientas y metodologias tecnicas;
* Invitar a participar en discusiones técnicas;
* Conocer las habilidades y las fortalezas de cada miembro del equipo; y
* Monitorar y couchear las prácticas y situaciones de otras personas que tengan que ver con arquitectura. 

## Labores para con el departamento
* Entender la dirección arquitectónica y estándares de la organización; y si es que existen
* Asegurar que el departamento siga lo estándares técnicos a nivel organización o crearlas si no se tienen;
* Compartir el estado de calidad y cobertura de pruebas del proyecto en el reporte de estado; y
* Trabajar de cerca con otros AOs existentes en el departamento, para compartir conocimiento y solucionar posibles problemas. 

## Labores para con los equipos
* Guiar la creación y evolución de la arquitectura de la solución que el equipo está trabajando; 
* Analizar los atributos de calidad necesarios para el proyecto y asegurase que el diseño de la arquitectura cumpla con estos;
* Trabajar en work items como cualquier otro team member;
* Desarrollar y modificar documentación que si sea utilizada por el equipo;
* Asegurar que la solución sea integrada y probada regularmente;
* Verificar que la solución cumpla con los estándares de calidad establecidos;
* Identificar riesgos que nacen del diseño de arquitectura;
* Asegurar que la solución es integrada y probada regularmente, idealmente via una estrategia de integración continua (CI); y
* Trabajar de cerca con el Product Owner (PO) para ayudarlo o ayudarla a entender las necesidades de los stakeholders técnicos, las implicaciones de la deuda técnica y la necesidad de invertir tiempo en pagarla. 
