Tabla de contenidos
1. ¿Qué es la arquitectura de software para ti?
La arquitectura de software es el juego de las compensaciones, como suelo llamarlo. Necesita equilibrar diferentes aspectos del sistema socio-técnico para tener una arquitectura coherente y al mismo tiempo entregar valor. Cada contexto es único, y hay diferentes heurísticas y patrones en nuestra industria que pueden apoyar nuestro proceso de toma de decisiones.
2. ¿Cuáles son las tres principales habilidades sociales que crees que necesitan los arquitectos de software?
Creo que un arquitecto de software necesita tener fuertes habilidades de comunicación, capacidad de negociación a todos los niveles y tener habilidades de facilitación. El papel de un arquitecto de software está cambiando ya que las organizaciones están adoptando tecnologías como la nube; debido a su naturaleza dinámica y efímera, permite que los sistemas crezcan en complejidad, y es difícil tener un modelo mental único del sistema técnico. Tener esas 3 habilidades suaves permite a los arquitectos de software navegar en la complejidad, teniendo una acción coherente a la vez que fomenta la diversidad.
3. ¿Cuáles son las tres principales responsabilidades de un arquitecto de software dentro de la empresa?
Depende en gran medida del tamaño de la organización, la industria e incluso la zona geográfica. Estoy en Europa, y la mayoría de mis experiencias están en países europeos. Se puede argumentar que un arquitecto de software es responsable de: 1) ayudar a la organización a traducir las opciones en planes estratégicos; 2) facilitar que la organización dé sentido a la realidad, desde el punto de vista de la teoría de la complejidad; 3) facilitar, entrenar y asesorar a los equipos que crean el software, permitiendo que la agencia de un departamento y/o organización.
4. ¿Cuáles son los atributos clave de la arquitectura de software?
La arquitectura de software debe ser comparada con un edificio. Construimos y vivimos en él. Por lo tanto, los atributos como aptos para el propósito, la capacidad de adaptarse (en un tiempo viable) a las nuevas/diferentes necesidades y la resistencia a las condiciones adversas son atributos clave.
5. ¿Cuáles son las métricas clave de la arquitectura de software?
Soy fan del libro Accelerate, el trabajo iniciado por la Dra. Nicole Forsgren. Utilizo las cuatro métricas que predicen la entrega del software y el rendimiento operativo: (1) tiempo de espera para los cambios, (2) frecuencia de despliegue, (3) tiempo para restaurar el servicio, (4) tasa de fallo de los cambios. Además, también recomiendo usar una quinta métrica del Chaos Engineering communication, el tiempo medio de detección.
En un nivel más granular, las métricas de cohesión y acoplamiento son importantes. Por último, pero no menos importante, la métrica de equipo: la felicidad, la capacidad de reentrada y la agencia son cruciales para equilibrar el sistema socio-técnico.
6. Pensamiento crítico vs. pensamiento de sistema en la arquitectura de software, ¿qué significa para ti?
Soy un estudiante de la teoría de la complejidad, en particular del Cynefin de Dave Snowden. Lo uso diariamente, para ayudar a dar sentido a la realidad. Como tal, utilizo diferentes métodos de pensamiento dependiendo del dominio (desde el punto de vista del Cynefin) en el que nos encontremos. En los dominios ordenados, claro y complicado, el pensamiento de sistema es muy poderoso. Sin embargo, la mayoría de las veces estamos en los dominios no ordenados, es decir, Complejos. Necesitamos diferentes métodos, técnicas y herramientas para navegar por esos desafíos ya que tienen un atributo interesante: cada vez que interactuamos con un problema complejo, el problema cambia por sí mismo. Podemos tener consecuencias intencionadas y no intencionadas, y es por eso que algunos métodos que asumen una visión ordenada del mundo se quedan cortos.
En términos de arquitectura de software, me permite tener la conversación adecuada en el momento adecuado. Basado en el dominio (claro, complicado, complejo, caótico o confuso) puedo manejar mis propias expectativas y otras expectativas, usando métodos o herramientas adecuadas para el desafío en cuestión.
7. ¿Cuál es tu opinión sobre la Innovación vs. Pragmatismo?
Depende. Corto y dulce (también la jerga preferida de los consultores). Hay múltiples dimensiones, y tiendo a recurrir al trabajo de Simon Wardley para ayudarme a elegir el enfoque correcto en lo que respecta a la fase de evolución del producto (asumiendo los atributos digitales donde la arquitectura del software es clave). También lo combino con el modelo X3 de Kent Beck. Diciendo que se necesitan ambos, sin embargo, las herramientas, las técnicas y el comportamiento son diferentes.
Si estamos innovando, tratando de perturbar un mercado, creando un producto, necesitamos mantener la capacidad de ser flexibles y pivotar. La estabilidad del sistema no es lo primero que se piensa. Las «cosas» tienden a ser caóticas, y si estamos innovando, es importante leer las señales débiles para ayudar a mover el producto (y la arquitectura) en la dirección correcta. ¿Cuál es la dirección correcta? Es la difícil, ya que la innovación es incierta, y los experimentos y esfuerzos fallan. La capacidad de hacer experimentos seguros de fallar es crucial para innovar.
Por otro lado, tenemos el pragmatismo. Si el producto y la arquitectura subrayada están en una fase de evolución como el producto (+alquiler, usando la jerga de Simon Wardley), la eliminación de los residuos y ser pragmáticos es clave. Permitirá retener las capacidades centrales del producto y centrarse en las partes de la arquitectura del software que necesitan aumentar la resistencia y la estabilidad, eliminando las características que no son necesarias para esta fase de evolución.
Una vez más, como arquitecto de software es nuestro trabajo facilitar a la organización el uso de métodos adecuados para la resolución de problemas. Tener en cuenta las múltiples dimensiones dará los puntos de datos necesarios para tomar una decisión.
8. ¿Qué opinas sobre el control intelectual?
Para enmarcar mi respuesta, supongamos que estamos usando la definición de control intelectual de George Fairbanks (puede ver la nota clave aquí). A medida que la industria del software evoluciona, perdemos el control intelectual sobre toda la pila. Cuando digo pila completa es desde la página web presentada en el navegador, hasta los impulsos eléctricos en los cables de fibra óptica. Es demasiado conocimiento para saber todos los detalles. Afrontémoslo, el control es una ilusión.
Basándonos en esta premisa, tenemos que mirar al valor que creamos. Una vez más, usando el trabajo de Simon Wardley, cada vez que algo es comercializado somos capaces de crear un sistema de alto orden. Hagámoslo tangible. Con el aumento de la nube, empezamos a tener recursos de mercancías, como una máquina virtual iniciada. La forma de operar una flota de máquinas virtuales en la nube se estandariza al compararla con las que operamos en nuestro centro de datos. Esto permitió que surgieran diferentes paradigmas, como por ejemplo las funciones como servicio (diferentes nombres en diferentes proveedores de nube). Aunque se trata de una abstracción (todavía tenemos servidores y componentes de red), nos centramos en la creación de valor en diferentes áreas. Todo evoluciona y tenemos que aceptarlo. Por lo tanto, perder el control intelectual de toda la pila es una compensación para poder crear sistemas de alto orden.
9. ¿Qué opinas sobre el rendimiento y la capacidad de respuesta?
Veo que la gente los usa como si los conceptos fueran intercambiables, pero en mi opinión, no lo son. El rendimiento es un concepto que tiene diferentes atributos en diferentes contextos, y la capacidad de respuesta es más estrecha. Por ejemplo, Amazon tiene una capacidad de respuesta asombrosa, en la que incluso si su método de pago no es correcto (más allá de las validaciones básicas), lo aceptan. El sistema entre bastidores necesita tener un rendimiento (manejar los pagos a escala de Amazon) para darme una respuesta oportuna. Una vez, mi tarjeta de crédito expiró, y aún así aceptaron el pedido, pero unos minutos más tarde recibí una notificación de que necesito revisar mi método de pago.
Espero que con este ejemplo se pueda pensar en la aplicabilidad más amplia del rendimiento, es decir, en lo que es aceptable desde el punto de vista de una persona.
10. ¿Cuáles son sus expectativas con respecto a los eventos de arquitectura de software, cree que en 2021 todo estará en línea?
Creo que la mayoría de los eventos serán sólo, con algunos de forma híbrida. Todavía tenemos desafíos en cuanto a la pandemia, pero los dejaría en manos del especialista y de mi parte: quedarse en casa y usar una mascarilla.
11. ¿Qué tendencias de arquitectura de software has notado este año?
Patrones de arquitectura de flujo e implementaciones, y adopción de componentes nativos de la nube. Está llevando a las organizaciones a cuestionar el status quo actual, y si necesitan adaptar la forma en que el flujo de valor pasa a través de la organización.
En el reverso, los microservicios están llegando a lo que yo llamo la iluminación, con las empresas dándose cuenta de que no se trata de lo pequeño que es, sino de cómo razonar sobre los límites correctos. Por eso veo que el Diseño Basado en el Dominio continúa teniendo un crecimiento constante, ayudando a los equipos y organizaciones a razonar sobre los límites de sus sistemas antes de empezar a construir la siguiente cosa nueva.
12. ¿Crees que existen balas de plata en la arquitectura de software?
No creo en las balas de plata. Creo en la heurística (dependiente del contexto) y en los patrones (heurística probada que funcionó en diferentes contextos). Esos son los bloques de construcción que uso para construir una arquitectura coherente para el contexto en cuestión.
Lo que creo profundamente es que la diversidad es la clave para fomentar una arquitectura sólida, ¡y debería ser la primera preocupación de cualquier organización!
13. ¿Cuál es tu opinión sobre la Elasticidad vs. Escalabilidad?
Diferentes atributos, con diferente peso para diferentes arquitecturas. La elasticidad suele ser un atributo que los arquitectos de software buscan en los proveedores de nubes, donde la escalabilidad suele discutirse cuando tenemos limitaciones de gobierno como nuestros centros de datos.
Por otro lado, en un sistema sociotécnico, podemos pensar en la escalabilidad de una organización, donde es difícil de escalar de forma lineal, al menos en el ámbito del software. Añadir más gente a los equipos no significa necesariamente que se tendrá más rendimiento. A veces sólo contribuye a una complejidad accidental, y hace que el sistema se detenga para hacer todas las partes móviles. Es crucial entender el paisaje, y como escribí antes, usando marcos, herramientas y técnicas como Cynefin y Wardley Maps para usar los conceptos correctos en los lugares correctos.
14. ¿Podrías compartir tus ideas sobre los patrones de la arquitectura de software?
Los patrones son útiles, nos dan un lenguaje común, y pueden enmarcar soluciones potenciales para o desafíos. Como arquitecto empecé a coleccionar heurística después de que Rebecca Wifrs-Brock me desafiara. Es interesante pensar en eso (heurística y patrones), discutir con los colegas, comprometerse con la comunidad. Genera nuevas percepciones, y ayuda a avanzar en la profesión.
15. ¿Qué recomendación le darías a las grandes empresas internacionales en cuanto a la arquitectura de software?
No hay una bala de plata, una salsa mágica y un enfoque de talla única. Reconocer la complejidad y aceptarla.
16. ¿Qué recomendación darías a las empresas de nueva creación en términos de arquitectura de software?
Todo es efímero, y lo que estáis arquitecturando hoy puede no encajar en el mercado mañana. Diciendo que daré dos recomendaciones concretas: usar el Domain-Driven Design para diseñar los límites del sistema, incluyendo los modelos (lo que está dentro y lo que está fuera), e implementarlo usando el patrón de Puertos y Adaptadores. Es un patrón poderoso que permite a las empresas de nueva creación pivotar cuando lo necesitan, redireccionando el software, o incluso cambiar de plataforma debido a su propio éxito, sin afectar el núcleo del software.
17. ¿Cuáles son los principales problemas de la arquitectura de software?
En mi opinión, las balas de plata. Como industria tenemos patrones, y los combinamos de diferentes maneras. Cuando no lo entendemos aquí, asumimos que debemos desechar el pasado y abrazar el sabor del día.
Ser capaz de reconocer los patrones mitigará este problema.
18. Tu recorrido de arquitectura: ¿lecciones aprendidas?
Comprender qué sistema socio-técnico es primordial. Al principio de mi viaje pensé que dominar las técnicas y plataformas era el ingrediente del éxito. Aprendí de la forma más dura que la comunicación es clave, y luego las estructuras culturales y sociales dictan cómo se propagan las ideas en una organización. Hoy en día me centro en las personas, equipos y estructuras de apoyo que permiten la autonomía y la agencia. La tecnología viene después.
19. Tu BIO, nombre, email, web, redes sociales (cualquier cosa que quieras compartir)
João es un CTO interino y un consultor de entrega de software estratégico en Xebia. Se centra en ayudar a los equipos y organizaciones a tomar decisiones estratégicas en relación con el software, alineando los equipos y el software para optimizar el valor basado en la corriente. Cree en el poder de la colaboración y es un fanático de las herramientas visuales de colaboración.
Es el curador de Visual Collaboration Tools y el anfitrión del podcast Software Crafts Podcast.
Cuando no está haciendo sus deberes, puedes encontrarlo viajando con su hija y su esposa, o tumbado en la playa leyendo un libro. João también es un cocinero aficionado en el tiempo libre que le queda.
