What type of IT architect are you?

 

Fuente: https://www.redhat.com/architect/what-type-it-architect-are-you

Eligiendo un camino: ¿Arquitecto de Software o Líder Técnico?

¿Cuál es la diferencia entre un Arquitecto de Software y un Líder Técnico?

La diferencia entre un arquitecto de software y un líder técnico puede variar según la organización, el proyecto y el contexto específico en el que se encuentren. Sin embargo, a grandes rasgos, se pueden identificar algunas diferencias clave:

1. Enfoque: Un arquitecto de software se enfoca principalmente en la arquitectura y diseño de soluciones de software. Su objetivo es definir y garantizar la integridad, calidad y viabilidad técnica del sistema. Por otro lado, un líder técnico se enfoca en liderar y gestionar un equipo técnico, así como coordinar su trabajo con otros equipos y áreas de la organización.
2. Responsabilidades: El arquitecto de software es responsable de diseñar y mantener la arquitectura de software, tomar decisiones técnicas clave, y garantizar la calidad y la escalabilidad del sistema. El líder técnico es responsable de liderar y motivar al equipo técnico, coordinar sus tareas, establecer metas y objetivos, y asegurarse de que se cumplan los plazos y presupuestos del proyecto.
3. Conocimientos técnicos: Ambos roles requieren un conocimiento sólido de la tecnología y las herramientas utilizadas en el proyecto, pero un arquitecto de software se centra más en la comprensión de las necesidades técnicas del sistema, mientras que un líder técnico se enfoca en la gestión y liderazgo del equipo.
4. Nivel de experiencia: En general, un arquitecto de software se considera un rol más especializado y senior, con experiencia en la arquitectura y diseño de sistemas complejos y en la toma de decisiones técnicas críticas. El líder técnico, aunque también es un rol senior, puede requerir menos experiencia técnica y enfocarse más en la gestión de equipos y proyectos.

En resumen, mientras que un arquitecto de software se enfoca en la arquitectura y diseño de soluciones de software, un líder técnico se enfoca en liderar y gestionar un equipo técnico, coordinando su trabajo y asegurándose de que se cumplan los objetivos del proyecto. Ambos roles son importantes para el éxito de un proyecto de software y a menudo trabajan juntos para lograr los objetivos técnicos y empresariales.

¿Puedo pasar de Desarrollador de Software a Líder Técnico o necesito pasar antes por el rol de Arquitecto de Software?

Es posible pasar de desarrollador de software a líder técnico sin necesidad de haber desempeñado previamente el rol de arquitecto de software. Sin embargo, hay algunas habilidades y conocimientos que son importantes para ser un buen líder técnico y que pueden ser desarrollados a través de la experiencia previa en el diseño y la arquitectura de software.

Algunas habilidades que son importantes para un líder técnico incluyen la capacidad de comunicarse eficazmente con el equipo de desarrollo y otros stakeholders, la capacidad de liderar y motivar a un equipo, la capacidad de tomar decisiones técnicas y la capacidad de resolver conflictos. También es importante tener una comprensión sólida de los principios y prácticas de la ingeniería de software, incluyendo la metodología de desarrollo de software, los patrones de diseño y las mejores prácticas de codificación.

Si bien la experiencia previa en arquitectura de software puede ser útil para desarrollar estas habilidades, no es un requisito previo para convertirse en líder técnico. En su lugar, puede ser útil buscar oportunidades para liderar pequeños equipos o proyectos dentro de su función de desarrollador de software actual, y buscar capacitación y orientación en habilidades de liderazgo y gestión de proyectos. También puede ser útil buscar mentores en su empresa o en la comunidad de desarrollo de software para obtener asesoramiento y orientación sobre cómo desarrollar sus habilidades de liderazgo técnico.

Material de lectura

Software Engineering Design

Software design is an indispensable phase of the software engineering process for creating and evaluating software models that guide the construction effort for developing high-quality software systems on time and within budget. 

Conceptually, design is the process of transforming functional and nonfunctional requirements into models that describe the technical solution before construction begins. To achieve this, the concept of software design, its activities, and tasks must be well understood so that a problem-solving framework for designing quality into software products can be established. 

In today’s modern software systems, there are numerous design principles, processes, strategies, and other factors affecting how designers execute the software design phase. When equipped with the proper design foundation knowledge, an understanding of the designer’s roles and responsibilities can be acquired, allowing designers to become effective in designing large-scale software systems under a wide variety of challenging conditions.

Aplicando TDD a la arquitectura

¿Qué es la arquitectura?

La arquitectura implica la toma de decisiones relevantes de diseño. 

Ahora la pregunta clave es ¿cómo nos ayuda TDD a tomar estas decisiones relevantes? Básicamente tenemos que plantear pruebas que nos ayuden en la definición de la arquitectura.

El proceso de construcción

Podemos plantear el proceso con un esquema de alto nivel:

Para cual consideramos algunas premisas y técnicas que nos ayudarán a definir nuestra arquitectura.

• Premisas:
• El resultado es consecuencia del proceso
• El desarrollo es guiado por pruebas
• El proceso es iterativo y los incrementos son pequeños
• Al trabajar de forma iterativa hay desperdicios
• Integración, verificación y entrega continua
• Mantenerlo estúpidamente simple (KISS)
• Técnicas:
• BDD/TDD
• Integración continua / Despliegue continuo
• Walking Skeleton
• Arquitectura Hexagonal

Arrancamos de forma temprana teniendo un pipeline de deployment y un ambiente en el cual desplegar. En la primera semana del proyecto se puede armar el esqueleto del proyecto, subirlo a un repositorio, que compile y despliegue.

Ciclo BDD/TDD

• Arrancamos con una funcionalidad desde la perspectiva del usuario.
• Para esta funcionalidad escribimos pruebas de aceptación (los tradicionales casos de prueba). Esto es una prueba a nivel de requerimiento.
• Para satisfacer estas pruebas de aceptación voy a tener que crear un conjunto de objetos y es aquí donde entramos en el ciclo de TDD. Escribo pequeñas pruebas para cada uno de los objetos que van a intervenir en resolver esa transacción de negocio.

Si bien es cierto que escribimos una prueba de aceptación y de repente para que pase una sola prueba de aceptación voy a tener que dar varias vueltas al ciclo de TDD. Por ejemplo, puedo tener 1 prueba de aceptación y 10 pruebas unitarias.

---

Bibliografía

• Ports-And-Adapters / Hexagonal Architecture
• TDDeando la arquitectura, Nicolas Paez - Meetup ArqConf

Claves del pensamiento arquitectónico

 A diferencia de un desarrollador, un arquitecto debe cultivar un punto de vista arquitectural que le permita tener una visión amplia del sistema que se está construyendo. Según el libro Fundamentals of Software Architecture (by Mark Richards, Neal Ford) existen cuatro aspectos clave para desarrollar el pensamiento arquitectónico:

1. Entender cuál es el límite entre la arquitectura y el diseño
2. Tener amplitud técnica
3. Analizar trade-offs
4. Entender los requerimientos de negocio

Desarrollar estas destrezas permitirán al arquitecto tomar mejores decisiones arquitectónicas, las cuales influyen en el diseño, producción y entrega de productos software. A continuación veamos brevemente dichas destrezas..

1. Entender cuál es el límite entre la arquitectura y el diseño 

Es común ver una separación vertical entre las responsabilidades de los arquitectos y desarrolladores.

Punto de vista tradicional de la separación entre la arquitectura y el diseño

Sin embargo, no existe un límite entre la arquitectura y el diseño, sino que están integrados y sincronizados. Para que la arquitectura funcione, los arquitectos y desarrolladores deben trabajar juntos. El papel principal del arquitecto es de liderar y capacitar a los desarrolladores del equipo.

Haciendo que la arquitectura funcione a través de la colaboración

2. Tener amplitud técnica

Mientras que un desarrollador debe mantener una profundidad técnica para realizar su trabajo, un arquitecto debe tener una amplitud técnica para pensar desde un punto de vista de la arquitectura. 

Una gran parte del valor de un arquitecto es una amplia comprensión de la tecnología y de cómo utilizarla para resolver problemas concretos. Por ejemplo, como arquitecto, es más beneficioso saber que existen cinco soluciones para un problema particular que tener conocimientos singulares en una sola.

3. Analizar trade-offs

Pensar como arquitecto implica evaluar los trade-offs de cada alternativa para elegir la mejor solución. Los trade-offs se refieren a las ventajas y desventajas que pueda tener una solución determinada.

Todo en arquitectura es un trade-off, por eso es que la respuesta común a una pregunta de arquitectura es un "depende". Pensar arquitectónicamente implica observar los beneficios de una solución dada, pero también analizar los aspectos negativos.

Subir un extremo de la balanza hace bajar el otro

4. Entender los requerimientos de negocio

Pensar como arquitecto requiere entender los requerimientos de negocio para luego traducirlos en características de la arquitectura (escalabilidad, rendimiento, disponibilidad, etc.). Es una tarea compleja porque requiere conocimiento del negocio y buenas relaciones con los principales stakeholders de la empresa.

¡Gracias por llegar hasta aquí!

La modularidad en la arquitectura

La modularidad es un principio organizador. Si un arquitecto diseña un sistema sin prestar atención a cómo se conectan piezas, termina creando un sistema que presenta innumerables dificultades, pues los sistemas de software modelan sistemas que tienden al desorden. Por esto último es indispensable que los arquitectos inviertan energía en asegurar una buena solidez estructural (algo que no se puede dar por accidente).

Utilizamos la modularidad para describir una agrupación lógica de código relacionado, que podría ser un grupo de clases en un lenguaje orientado a objetos o funciones en un lenguaje estructurado o funcional. La mayoría de lenguajes proporcionan mecanismos de modularidad (paquete en Java, espacio de nombre en .NET, etc.)

Medición de la modularidad

Dada la importancia de la modularidad para los arquitectos, necesitan herramientas para entenderla. Los investigadores han creado una variedad de métricas agnósticas de los lenguajes para ayudar a los arquitectos a entender la modularidad. Estas métricas son:

• Cohesión
• Acoplamiento
• Connascence

De módulos a componentes

Los módulos son una colección de código relacionado. Es un nombre genérico para un paquete de código relacionado. Sin embargo, los arquitectos suelen pensar en términos de componentes, la manifestación física de un módulo.

Los desarrolladores empaquetan físicamente los módulos de diferentes maneras, a veces dependiendo de su plataforma de desarrollo. La mayoría de los lenguajes soportan el empaquetamiento físico: archivos jar en Java, dll en .NET, gem en Ruby, etc.

¡Gracias por llegar hasta aquí!

Identificar características arquitectónicas

Para crear una arquitectura o determinar la validez de una arquitectura existente se empieza por identificar las características arquitectónicas ("-ilities"). Para lograr esto el arquitecto debe:

• Comprender el dominio del problema.
• Trabajar con los stakeholders para establecer lo que es verdaderamente importante desde la perspectiva del negocio.

Un arquitecto extrae las características arquitectónicas de al menos tres fuentes:

• Requerimientos de negocio
• Requerimientos funcionales y restricciones
• Del conocimiento implícito del dominio

En esta oportunidad hablemos sobre lo que implica extraer las características arquitectónicas a partir de los requerimientos de negocio.

Extraer las características arquitectónicas desde los requerimientos de negocio

Los requerimientos de negocio describen las metas de una organización. Un arquitecto debe ser capaz de identificar las características arquitectónicas correctas. Por ejemplo, ¿es la escalabilidad la característica más importante, o es la tolerancia a fallos, la  seguridad o el rendimiento? Tal vez el sistema requiere las cuatro características combinadas.

La comprensión de los objetivos de negocio permite al arquitecto traducirlas en "-ilities", lo que luego constituye la base de decisiones arquitectónicas correctas y justificables. La mayoría de las características arquitectónicas se obtienen  escuchando a los stakeholders y colaborando con ellos para determinar qué es importante desde la perspectiva del negocio.

Aunque esto puede parecer una actividad sencilla, el problema es que los arquitectos y los stakeholders del negocio hablan idiomas  diferentes. Los arquitectos hablan de escalabilidad, interoperabilidad, tolerancia a fallos y disponibilidad. Los  stakeholders del negocio hablan de fusiones y adquisiciones,  satisfacción del usuario, time to market y ventaja competitiva.

Lo que sucede es un problema de "lost in translation" en el que el arquitecto y el stakeholder del negocio no se entienden entre sí. Los arquitectos no tienen ni idea de cómo crear una arquitectura que apoye la satisfacción del usuario, y los stakeholders del negocio no entienden por qué los arquitectos ponen tanta atención y hablan de disponibilidad, interoperabilidad y tolerancia a fallos en la aplicación. Los arquitectos deben a menudo decodificar el lenguaje del dominio en equivalentes de ingeniería.

Afortunadamente, suele haber una traducción de los objetivos del negocio a las características arquitectónicas, tal como se describe en la siguiente imagen:

Recuerda que normalmente un objetivo de negocio implica satisfacer la combinación varias características arquitectónicas y hay que tener cuidado de no caer en la trampa de concentrarnos en uno sólo de ellos.

Particionamiento de la arquitectura

Una de las principales decisiones que un arquitecto debe tomar se refiere a la división de alto nivel de la arquitectura. Para esto, los arquitectos suelen pensar en términos de componentes, la manifestación física de un módulo. Los componentes representan la unidades de construcción básica en la arquitectura, lo que los convierte en una consideración crítica para los arquitectos.

Los componentes se pueden manifestar de diferentes formas:

• Library
• Layer
• Event Processor
• Distributed service

Por lo general, el componente es el nivel más bajo del sistema de software con el que un arquitecto interactúa directamente. Los componentes consisten en clases o funciones (dependiendo del paradigma de programación), cuyo diseño es responsabilidad de los desarrolladores. 

Tipos de particionamiento

Cuando un arquitecto realiza la división de alto nivel de la arquitectura, genera componentes utilizando un tipo de particionamiento en particular, que puede ser:

• Particionamiento técnico
• Particionamiento por dominio

Tipos de particionamiento de alto nivel

El particionamiento de alto nivel es de particular interés para los arquitectos porque define el estilo de arquitectura a usar, ya sea monolítico o distribuido:

• Monolithic: Layered architecture, Pipeline architecture, Microkernel architecture
• Distributed: Service-based architecture, Event-driven architecture, Space-based architecture, Service-oriented architecture, Microservices architecture

Por eso pregúntate ¿qué tipo de particionamiento soporta el estilo arquitectónico que estoy analizando?

Particionamiento técnico

Consiste en dividir la arquitectura en capacidades técnicas. Un ejemplo de esto es la arquitectura en capas, la cual representa una división técnica de alto nivel: presentación, reglas de negocio, servicios, persistencia, etc.

Particionamiento por dominio

Este tipo de particionamiento está inspirado en el libro de Eric Evans Domain-Driven Design (DDD) en donde explica una técnica de modelado para descomponer sistemas complejos. En DDD el arquitecto identifica los dominios o flujos de trabajo independientes y desacoplados entre sí. El estilo arquitectónico de microservicios se basa en este enfoque.

Flujo de identificación de componentes

La propuesta para la identificación de componentes es seguir una serie de pasos bajo un enfoque iterativo. Ya sea para la identificación de componentes candidatos o el refinamiento de los mismos.

• Identifying Initial Components: Basándose en un tipo de particionamiento de alto nivel, determinar con qué componentes comenzar. Es difícil empezar con algo concreto cuando un arquitecto diseña un sistema desde cero. Para lograr un buen diseño no queda otra opción que iterar.
• Assign Requirements to Components: Mapear los requisitos funcionales con los componentes. Esto puede implicar la creación de nuevos componentes, la consolidación de los existentes o la separación de los mismos porque tienen demasiada responsabilidad.
• Analyze Roles and Responsibilities: Pensar tanto en los roles y responsabilidades que la aplicación debe soportar para descubrir la granularidad correcta de los componentes.
• Analyze Architecture Characteristics: Mientras se asignan los requisitos funcionales a los componentes también se debe observar las características arquitectónicas descubiertas anteriormente. La idea es pensar en cómo las características arquitectónicas podrían afectar a la división y granularidad de los componentes. Por ejemplo, mientras que una parte del sistema pueden ocuparse de la entrada del usuario, la parte que trata con ciento de usuarios concurrentes necesitará diferentes caraterísticas arquitectónicas a diferencia de la otra parte.
• Restructure Components: Los arquitectos deben iterar continuamente en su diseño de componentes con ayuda de los desarrolladores. A medida que los desarrolladores profundizan en la construcción de la aplicación, se adquiere una comprensión más matizada de dónde deben estar el comportamiento y los roles.

Enlaces:

• Fundamentals of Software Architecture - Neal Ford, Mark Richards
• Arquitectura de software. Conceptos y ciclo de desarrollo - Humberto Cervantes Maceda