Descubre las herramientas y técnicas esenciales para arquitectos de software para abordar desafíos organizacionales, desde entrevistas con stakeholders hasta foros de arquitectura y registros de decisiones.
Complete 4-part guide series
The first days as a Software Architect can be both exciting and challenging. Learn what to do right after landing in this position, starting with the most important task: talking to people.
Discover the essential tools and techniques for software architects to tackle organizational challenges, from stakeholder interviews to architecture forums and decision records.
Learn why understanding organizational goals and product vision is essential before jumping into technical solutions, and discover practical tools to clarify objectives.
Learn how to sketch your platform's current state, highlighting its key characteristics, issues, and advantages as a software architect
En la primera parte de esta serie, Navegando los primeros días como Software Architect, describí la importancia de identificar a tus stakeholders, hablar con ellos y recopilar tanta información como sea posible. Es hora de procesar esa información y determinar qué herramientas pueden ayudarte a enfrentar los desafíos.
Tendrás un buen conjunto de notas adhesivas con información valiosa si usas la plantilla Miro que compartí en el primer artículo o cualquier otra herramienta de tu (o de tu organización) preferencia. Luego, puedes identificar y extraer algunos de los desafíos que tienes por delante usando esta información.
Supongamos que las entrevistas fueron bien y pudiste resumir ideas genéricas. Esos desafíos probablemente estén en las primeras dos filas: “Sus expectativas y tu responsabilidad” y “Resultado tangible para corto y largo plazo.” En mi ejemplo (ver la imagen arriba o la plantilla), estos desafíos son elementos como:
Si las notas no son suficientes para destilar los desafíos, puedes crear nuevas notas que los resuman en one-liners y colocarlas junto a las originales.
Las herramientas son formas poderosas de mejorar y facilitar cualquier tarea: taladros percutores, licuadoras, lavadoras a presión, etc. En el desarrollo de software, hay muchas herramientas disponibles: IDEs, frameworks y soluciones de CI/CD, repositorios de código, co-pilotos impulsados por IA, etc. Para la gestión de productos o proyectos, también hay muchas de ellas: Basecamp, Airfocus, Asana, MS Project, etc. Muchas de estas herramientas de producto y desarrollo de software tienen formas integradas de seguir metodologías o procesos específicos: Agile (por ejemplo, Scrum/Kanban), MVP, DevOps…
La gente usa estas herramientas diariamente, y les dan estructura y guía sobre cómo hacer sus trabajos. Usando su caja de herramientas, pueden enfocarse en crear valor.
Pero ¿qué pasa con la arquitectura de software? ¿Qué herramientas ayudan a la gente a mapear ideas de producto y negocio en una solución de software? Nota: No podré explicar en este artículo por qué necesitas esas herramientas y la arquitectura de software como una preocupación diferente de tu organización; eso es para una publicación de blog separada. Asumo que ya entendiste que necesitas un paso entre definir los requisitos del producto y saltar a codificar, sin importar quién haga eso en la organización.
Déjame resumir lo que descubrí en el mundo salvaje de la arquitectura de software.
Estas son palabras de moda como Domain-Driven Design, Microservice Architecture, Event-Driven Architecture, Hexagonal Architecture, Clean Architecture, Blockchain Architecture, Service Mesh, ServiceBus (¡qué!), etc.
Seamos claros: estas no son herramientas para estructurar y guiar tu trabajo sino más bien formas de resolver un problema. Puede que ya sepas cuán valiosas son estas herramientas, así que te diré cómo pueden dañarte:
La más popular en esta categoría es el modelo C4. Otras en esta categoría incluyen ArchiMate, Architectural Decision Records (ADRs), UML (diagramas de Clase, Secuencia, Componente, Despliegue, etc.), etc.
Estas son herramientas para capturar conocimiento y decisiones arquitectónicas. Están destinadas a proporcionar una estructura para documentar software, desde alto nivel hasta detalle. Por naturaleza, son estáticas y mayormente orientadas a resultados. Algunas personas pueden encontrarlas valiosas para diseñar nuevas funcionalidades, pero se basan en la suposición de que tienes toda la información y claridad necesarias para describir esa solución de software que ya tienes.
De nuevo, estas no son herramientas que te ayuden a construir arquitectura de software; solo están destinadas a capturar el resultado.
Estos funcionan bien para organizaciones que los usan y los consultores que van con ellos. TOGAF, Zachman Framework, FEA, y muchos más son los nombres de algunos de estos frameworks de Enterprise Architecture.
Será mejor que tengas un departamento de arquitectura central que defina todo el plan de antemano si quieres trabajar con estos, o puedes contratar a los grandes tiburones consultores para que lo hagan por ti.
Después de diez años de experiencia, puedo compartir con confianza mi caja de herramientas como arquitecto de software. Hay 14 herramientas aquí. Aunque hay toneladas de artículos sobre algunas de ellas, compartiré mi punto de vista, considerando esos desafíos que queremos abordar:
Cada una de estas herramientas sirve para un propósito específico en el trabajo diario del arquitecto, desde entender el espacio del problema hasta facilitar soluciones y asegurar alineación a través de la organización.
La clave es que la arquitectura de software no se trata de imponer soluciones desde una torre de marfil. Se trata de:
Estas herramientas te ayudan a lograr estos objetivos mientras mantienes la transparencia y construyes confianza con tus stakeholders.
No necesitas implementar las 14 herramientas de una vez. Comienza con:
A medida que construyas confianza y demuestres valor, puedes introducir gradualmente más herramientas basadas en las necesidades específicas de tu organización.
La caja de herramientas del Software Architect no se trata de soluciones técnicas o formatos de documentación. Se trata de crear estructuras y procesos que permitan un trabajo de arquitectura efectivo. Estas herramientas te ayudan a:
En la siguiente parte de esta serie, profundizaremos en entender los objetivos de tu organización y cómo alinear el trabajo de arquitectura con los objetivos de negocio.
Recuerda: la mejor arquitectura emerge de la colaboración, no del aislamiento. Usa estas herramientas para construir puentes, no muros.
Complete 4-part guide series
The first days as a Software Architect can be both exciting and challenging. Learn what to do right after landing in this position, starting with the most important task: talking to people.
Discover the essential tools and techniques for software architects to tackle organizational challenges, from stakeholder interviews to architecture forums and decision records.
Learn why understanding organizational goals and product vision is essential before jumping into technical solutions, and discover practical tools to clarify objectives.
Learn how to sketch your platform's current state, highlighting its key characteristics, issues, and advantages as a software architect
Join hundreds of software architects and engineers getting practical insights delivered to their inbox.