Soy Ronan y dirijo el departamento de Ingeniería de Software Cuántico en Equal1. Diseñamos y construimos ordenadores cuánticos totalmente integrados utilizando tecnología avanzada basada en espín. Equal1 tiene oficinas en Irlanda, Estados Unidos, Canadá, Japón, Rumanía y los Países Bajos, donde resido. Anteriormente, trabajé en Qblox, una empresa que fabrica sistemas de control cuántico.
En Equal1, me centro en el desarrollo del sistema integral que impulsa nuestra computadora cuántica de alto rendimiento RacQ. Este sistema está diseñado para escalar a miles de cúbits lógicamente corregidos e incluso más. Algunos lo denominan el «cerebro» de los procesadores cuánticos (QPU).
Mi trabajo me fascina porque cada día aprendo algo nuevo y tengo la oportunidad de trabajar con compañeros excelentes y muy capacitados. Empecé este blog para compartir lo que he aprendido; ¡por supuesto, sin revelar ningún secreto!
No dudes en escribirme a ronan ¡O conéctate en LinkedIn si quieres saber más!
***Disclaimer: While I work at Equal1 by the day, this blog is a personal project and does not reflect the views of my employer. The thoughts, ramblings, and opinions shared here are mine alone and haven’t been vetted, approved or modified by anyone but myself.
***Arquitectura del sistema de un vistazo
Link to heading
Durante mi etapa en Qblox, mi función era la de arquitecto de sistemas. A continuación, se incluye un memorándum sobre el puesto que ocupaba en aquel entonces.
Esa es una pregunta que me hacen con frecuencia: ¿Qué se espera exactamente de un arquitecto de sistemas (sysarch)? La respuesta varía según la empresa, el país de operación y el sector. Sin embargo, un concepto permanece constante: Comunicación.
Sí, la función del arquitecto es comunicar ideas complejas de forma sencilla, ya sea a los equipos de desarrollo e ingeniería, a los altos ejecutivos o a los clientes. Todo comienza con la comprensión del problema junto al cliente y el equipo de producto, lo cual es una parte apasionante del puesto: ¡crear una solución que satisfaga al cliente!
A partir de ahí, se procede al análisis tradicional de requisitos del sistema y, a menudo, a la creación de prototipos para probar el concepto, en la que suelo participar activamente. Después, se inicia el desarrollo del producto, donde actúo como líder técnico, colaborando con equipos multidisciplinarios hasta que el producto está listo. Finalmente, se lleva a cabo el soporte post-lanzamiento del producto.
¿Cómo llego a una decisión arquitectónica? El rol del arquitecto no es necesariamente decidir, sino más bien plantear el problema consolidando los insumos necesarios para tomar una decisión. Por ejemplo, el equipo de producto («¿Cuánto cuesta desarrollar este nuevo producto? ¿Cuál es el tiempo de comercialización?») o el equipo de directivos («¿Queremos invertir en esta nueva tecnología? ¿Cuál es el retorno de la inversión y la estrategia a largo plazo?»).
Se trata de adoptar un enfoque cartesiano, investigando y definiendo las ventajas y desventajas de cada posible solución sin juicios subjetivos. También implica evaluar la relación costo-beneficio, considerando no solo el esfuerzo de implementación, sino también el mantenimiento a largo plazo, los costos operativos y la carga cognitiva del equipo.
Más importante aún, se trata de negociar la alineación social, ya que cualquier decisión arquitectónica que los ingenieros detesten o los gerentes de producto no comprendan está destinada al fracaso. Tomar una decisión implica involucrar a todos en el proceso. En el ciclo de Producto y Negocio, asegúrese de que la elección genere valor para el negocio. En el ciclo de Ingeniería, solicite la opinión de ingenieros sénior para que se responsabilicen de su implementación.
Esta es una pregunta recurrente para todas las empresas con un producto de software: ¿Por qué y cuándo debemos refactorizar? Es común pensar que cuando los productos existentes son lentos e inestables, y se tarda demasiado en solucionar los problemas debido a la deuda técnica acumulada, es momento de refactorizar. Pero la respuesta no siempre es la correcta; en realidad, el rol del arquitecto es prevenir el efecto del segundo sistema.
Mi filosofía personal es aplicar las decisiones del día 1 y comprobarlas con la prueba de la “puerta de doble sentido”: ¿La refactorización es una puerta de un solo sentido (casi imposible de revertir, como elegir un paradigma de base de datos principal) o una puerta de doble sentido (fácil de cambiar más adelante, como la elección de una biblioteca interna)? Las puertas de un solo sentido requieren una validación profunda; las puertas de doble sentido requieren rapidez.
A primera vista, la función del arquitecto de sistemas también consiste en abogar por la cultura de ingeniería adecuada que genere valor tanto para los equipos de ingeniería (menos problemas urgentes) como para los equipos de producto (tiempo de comercialización más rápido).
Si bien la idea general es invertir ahora en tu pila de ingeniería/software para ahorrar tiempo más adelante en el desarrollo, el verdadero desafío es lograr el equilibrio adecuado entre invertir y sobreingeniería: desarrollar las herramientas y los componentes de software adecuados para facilitar el desarrollo y el mantenimiento del producto, en lugar de sobreingeniería algo que no agrega valor.
Esto también significa que el arquitecto debe comunicarse con frecuencia con los equipos de producto y de la alta dirección para promover el trabajo de los equipos que invierten sus esfuerzos en una ingeniería adecuada y preparada para el futuro, en lugar de estar constantemente apagando incendios.
En algún momento, refactorizar el sistema no es suficiente, ya que entra en juego la Ley de Conway: “Cualquier organización que diseñe un sistema producirá un diseño cuya estructura es una copia de la estructura de comunicación de la organización.”
La solución no siempre consiste en reubicar al personal, sino más bien en alinear el trabajo del equipo con la organización empresarial, de manera que el resultado de ambos sea mayor que la suma de sus partes. Si un equipo no genera suficiente valor debido a la ineficiencia de su estructura de comunicación, se debe crear un sistema en el que el resultado del equipo se defina mediante mejores componentes y promesas de API que aporten mayor valor a la empresa. Y si el equipo no logra crear nuevos componentes, se debe dividir el trabajo en componentes más sencillos con promesas de API más directas.
Pero, aún más importante, se trata de fomentar la alineación social entre el equipo y la organización: imagina una empresa donde el equipo se transforma para generar más valor. ¿No sería esa la situación ideal?
¿Cómo cambió la IA mi forma de trabajar? ¡Muchísimo! Al igual que los desarrolladores crean código que transmite sensaciones, los arquitectos necesitan mejorar en la redacción de “diseños que transmiten sensaciones” (así como en los requisitos del sistema que transmiten sensaciones) que puedan introducirse directamente en los modelos LLM como entrada para generar código.
La IA resulta muy útil al iterar sobre el diseño, ya que puede generar rápidamente muchas variaciones del mismo, lo que permite explorar con mayor rapidez diferentes opciones. Estos diseños pueden prototiparse rápidamente para verificar sus supuestos y complejidades de desarrollo.
Pero, sobre todo, es fundamental recordar que la IA no está aquí para reemplazar a los ingenieros, sino para potenciar sus capacidades y creatividad. Es una herramienta para mejorar el proceso de diseño, no para sustituir el criterio y la experiencia de los ingenieros.
Por ejemplo, observe el siguiente diagrama: ¿Cuántos LLM le dirán que el diagrama de la derecha muestra un error en el cúbit 3 (Z 2 Z 3 ), cuando en realidad se trata de un error bizantino en los cúbits 1 y 2? (explicaciones completas)
***Algunas ilustraciones seleccionadas
Link to heading