Table of Contents
1. ¿Qué es la arquitectura de software para ti?
La arquitectura de software es una intersección de la comprensión de la tecnología y los negocios para que puedas sintetizar una solución tecnológica para un problema de negocios.
2. ¿ Cuáles son las 3 principales habilidades de software que crees que necesitan los arquitectos de software?
Comunicación, comunicación, comunicación 🙂 No, en serio, la comunicación es TAN importante, y la comunicación del arquitecto a todos los niveles – desde C-suite y producto hasta desarrolladores y testeadores. Si lo desgloso, hay tres áreas de comunicación:
- Indagación – capacidad de escuchar mientras se dirige la conversación para obtener información crítica.
- Visualización – comunicar tus ideas, solicitar e incorporar la retroalimentación.
- Advocacy o influencia – capacidad de dirigir discusiones constructivas que conducen a una decisión o resultado.
Un arquitecto de software es mitad gerente de producto, mitad gerente de personal y mitad tecnólogo. Sí, son tres mitades. El arquitecto de software hace un trabajo y medio.
3. ¿Cuáles son las tres principales responsabilidades de un arquitecto de software dentro de la empresa?
- Asesorar y formar a los nuevos arquitectos. Siempre es bueno tener compañeros.
- Mantente al día con las tendencias tecnológicas y aprende continuamente. Quieres tener todas las herramientas en tu caja de herramientas y saber cuándo aplicarlas.
- Compartir información a través de la organización. El arquitecto es un centro de información del que muchos se beneficiarán.
4. ¿Cuál es tu opinión sobre la innovación vs pragmatismo?
Soy una gran fan del pragmatismo en la arquitectura de software, pero no creo que el pragmatismo esté reñido con la innovación. El pragmatismo es un gran mecanismo de control para aquellos que quieren ir tras cada nueva tecnología o tendencia, pero el pragmatismo también impulsa la innovación. Por ejemplo, hemos evolucionado desde el uso de metal desnudo a la infraestructura virtual y a la nube por diversas razones pragmáticas, como la escalabilidad (sin gastos de capital), la simplificación de los despliegues, etc.
5. ¿ Cuáles son tus expectativas en relación a los eventos de arquitectura de software, crees que en 2021 todo será online?
Espero que no. No hay nada que sustituya a la comunicación en persona y a la realización de conexiones. Aunque espero que una buena parte del año sea online, espero que veamos un regreso progresivo a las conferencias presenciales en la segunda mitad de 2021.
6. ¿Crees que existen balas de plata en la arquitectura de software?
No. Nunca hay nada que resuelva todos los problemas. En la arquitectura de software, todo se trata de hacer concesiones – lo que es correcto para tu empresa o proyecto en el momento de la implementación con las restricciones y los impulsores existentes. Las restricciones y los impulsores cambiarán con el tiempo, y también lo hará la arquitectura para apoyar el negocio. Se puede argumentar a favor de la construcción de un monolito si se ajusta a las restricciones y los impulsores – los microservicios no siempre son la respuesta 🙂
7. ¿Podrías compartir tus ideas sobre los patrones de arquitectura de software?
Las tendencias son geniales, pero asegúrate de que el patrón realmente se ajusta a tu necesidad, no lo elijas sólo porque sea popular. Soy un gran fan de la arquitectura basada en eventos, pero lo que descubrí hace tiempo es que en el mundo de la salud, el orden de los eventos es crítico. Si los eventos se consumen fuera de orden, los flujos de trabajo complejos pueden romperse y tener consecuencias no deseadas. En el mundo de las tecnologías de eventos, el orden de entrega no está garantizado, especialmente si se trata de eventos de diferentes tipos, y es necesario aumentar fuertemente la arquitectura o el conjunto de herramientas para poder utilizar realmente los eventos, y ese aumento puede anular los beneficios de la arquitectura basada en eventos.
8. ¿Qué recomendación darías a las grandes empresas internacionales en cuanto a arquitectura de software?
No hacer la arquitectura demasiado centralizada y pesada instituyendo juntas y comités de revisión. En su lugar, crear un foro para que los arquitectos intercambien ideas, les den dirección y les dejen averiguar la mejor manera de operar entre ellos.
9. ¿Qué recomendación darías a las startups en cuanto a arquitectura de software?
No ignorar por completo la arquitectura de software. El principal objetivo de las startups es moverse rápidamente y descubrir un nicho de mercado que puedan llenar, lo que normalmente significa un desarrollo muy rápido con una alta tasa de cambio de dirección – piensa en un MVP. Cuando la dirección se estabilice y estén listos para llevar su MVP a escala, este es un buen momento para evaluar las lagunas y pensar en la arquitectura de forma holística, antes de que el producto se convierta en un mosaico de código no mantenible con una pesada carga de soporte.
10. ¿Cuáles son los principales problemas de la arquitectura de software?
Puede ser difícil convencer a los ingenieros que no son especialistas en software de que es necesario y explicar los beneficios que aporta. Las preguntas típicas que recibo son «¿Qué tan difícil puede ser?» y «¿Por qué toma tanto tiempo?». Prepárate para dirigirte a ambos en un lenguaje que el negocio entienda y no en lenguaje técnico que los ingenieros usamos entre nosotros.
11. Tu recorrido de arquitectura: ¿lecciones aprendidas?
Tu arquitectura siempre debe apoyar el negocio y satisfacer las necesidades del negocio, sean cuales sean. Si no puedes vincular una iniciativa arquitectónica particular al valor del negocio, piénsalo dos veces: puedes estar haciendo tecnología por el bien de la tecnología.
12. Siéntete libre de compartir cualquier otro pensamiento relacionado con la arquitectura de software
«Un problema bien planteado es un problema medio resuelto» dijo Charles Kettering. Dedica un tiempo a refinar el enunciado de un problema antes de sumergirte en las soluciones. Todos los arquitectos deberían saber cómo obtener un enunciado del problema y cómo es un buen enunciado del problema. Un enunciado del problema nunca empieza con «Necesitamos» – eso es un enunciado de una solución, no de un problema. Un buen enunciado del problema contendrá buenos resultados que no están sucediendo, o malos resultados que sí. Suena sencillo, pero requiere práctica y realmente vale la pena el esfuerzo.
13. Tu BIO, nombre, email, web, redes sociales (cualquier cosa que quieras compartir)
Mi nombre es Sonya Natanzon. Soy arquitecta de software en el sector de la salud, y mis soluciones ayudan a mejorar la vida de los pacientes. Me gusta conocer a otros arquitectos, así que por favor siéntete libre de contactarme a través de LinkedIn
