Hablando con el arquitecto: Luis Carballo

En esta ocasión presento en esta columna una entrevista con Luis Carballo, Arquitecto de software de uno de los sistemas más críticos para México. Luis trabaja desde hace 7 años en la Bolsa Mexicana de Valores (BMV) en el área de sistemas en una empresa llamada Bursatec. Él es egresado de la UAM en donde estudió Ingeniería Electrónica y posteriormente realizó una maestría en el ITAM de TI y Administración (luis.carballo@mac.com).

¿Puedes platicarnos un poco acerca del proyecto en el cual estás trabajando?
Es un proyecto de renovación tecnológica del motor central de negociación de la bolsa que inició en el 2009. El sistema sustituye a tres sistemas legados, dos que corrían en Tandem que eran propietarios y un tercero que se le compró a la bolsa española. Se instaló en producción la primera parte, que corresponde al mercado accionario, en Septiembre de 2012 y la segunda parte, que corresponde al mercado de derivados, en Abril de 2013.

¿Puedes hablar un poco acerca de lo que llamamos los “drivers” y en particular los atributos de calidad del sistema?
Uno de los objetivos de reemplazar los antiguos sistemas era de reducir el costo total de propiedad pues el costo de mantenimiento de los sistemas Tandem, escritos en Cobol, era muy alto. Otro objetivo era aumentar el desempeño pues el sistema anterior iba a tener un límite con el cual se iba a topar pronto. La idea era reemplazarlo por uno nuevo que pudiera tener muchas más capacidades sobre todo en rendimiento, en baja latencia, en alta disponibilidad y que fuera mucho más fácil de probar y de integrar continuamente.

De estos drivers que mencionaste, ¿cuál ha resultado el más complejo?
Creo que el más difícil de todos es el de latencia porque toca todo el flujo de código por el cual se va a ejecutar una transacción. La latencia se refiere al tiempo de procesamiento dentro del motor desde que llega un mensaje (por ejemplo una compra de una acción) hasta que el motor responde (ej. aceptada o rechazada o hizo “match” contra otra orden). El promedio de latencia del sistema anterior era 24 milisegundos. El requerimiento original era que fuera menos de un milisegundo pero durante el análisis que se hizo contra otros mercados, se decidió bajar el tiempo para hacerlo más competitivo y que fueran menos de 100 microsegundos, o sea, 240 veces más rápido que el sistema anterior. El rendimiento se refiere a la cantidad de transacciones que se pueden ejecutar en un segundo dado. El sistema anterior tenía una capacidad de procesamiento de transacciones baja y el sistema actual está diseñado para soportar más de 100,000 transacciones por segundo. Al ser un sistema de misión crítica, la alta disponibilidad también es un factor importante y se consideran dos escenarios: en caso de falla de uno de los nodos primarios tiene que hacer “failover” (tolerancia a fallas) a otro en el mismo centro de datos y, el otro es que, en caso de falla del centro de datos primario, se pueda seguir la operación en un centro de datos secundario. Para el primer caso hoy en día tarda entre 5 y 10 segundos hacer la transición de una máquina a otra.

¿Qué tan importante es considerar la arquitectura para un sistema como éste?
Creo que es de los factores de éxito más importantes porque, de haber construido sin tener en mente la latencia, el rendimiento o la alta disponibilidad, hubiera hecho que al final del proyecto fuera prácticamente imposible el tratar de satisfacer esos atributos de calidad. El haber hecho el diseño desde el inicio de tal forma que hubiera foco en la latencia desde el diseño original permitió que el sistema fuera exitoso. Hubo un momento durante las pruebas en el cual la latencia se disparaba poco a poco hasta llegar a segundos y todo por una sola línea de código. Generamos ciertas métricas y guías para evitar usar cosas que sabemos que son dañinas para efectos de latencia. Yo creo que ese tipo de problemas no los hubiéramos encontrado si no nos hubiéramos enfocado constantemente en que los atributos de calidad se cubrieran.

¿Cómo le hicieron para desarrollar esta arquitectura?
Contratamos al SEI para que nos asesorara en el diseño de la arquitectura y utilizamos los métodos que ellos proponen para efectos del diseño del sistema [1][2]. Se hizo un Taller de Atributos de Calidad (QAW), ADD con una modificación, documentación basada en atributos de calidad y ATAM (Architecture Tradeoff Analysis Method) para la evaluación. La modificación de ADD consistió en hacer mini-sesiones de cuestionamiento al diseño generado usando ADD para asegurar que el resultado fuera el esperado.

La gente del SEI nos cuestionaba diciendo “oye, el diseño que llevas hasta ahora a ver qué tan efectivo es para resolver problemas de latencia, desempeño...”. Estas sesiones se hacían constantemente como parte de las iteraciones de diseño. Eran prácticamente dos semanas de diseño y después del diseño una sesión de cuestionamiento. Fueron como diez iteraciones de diseño en las cuales se tomaron las decisiones más importantes. Después de eso se hizo la evaluación de la arquitectura usando ATAM con resultados satisfactorios.

A nivel del diseño, ¿qué retos hubo para satisfacer los atributos de calidad más importantes?
Respecto a la latencia, hay cosas como la elección misma de las estructuras de datos pues unas son más rápidas que otras. Aún si en el diseño de la arquitectura pusimos cuotas sobre la latencia de ciertos componentes, durante la ejecución hubo que probar diferentes soluciones y ver cuál era la mejor opción según el caso. Es un tema de ir buscando, aún durante la construcción, las mejores soluciones posibles para poder satisfacer los atributos de calidad. Se hacían prototipos específicos para lo que se quería en ese momento y se determinaba cual era la mejor solución, que “tradeoffs” había, que restricciones pudiera tener y cuáles no y en base a eso, se tomaban las decisiones finales. Afortunadamente el grupo de arquitectura pasó a ser parte del grupo de desarrollo entonces
ellos asesoraban a todos los demás para que supieran cuáles eran las intenciones sobre ciertos componentes y que se apegaran a los lineamientos establecidos.

Con respecto a la documentación, ¿cómo fue ese aspecto?
La hicimos durante el diseño. Durante la ejecución fuimos documentando toda la arquitectura que era requerida para la evaluación. Usamos algo como vistas pero más enfocadas a los atributos de calidad. Teníamos vistas específicas de cómo se resuelven los atributos de calidad. Hay por ejemplo, una vista específica de componentes para el escenario de alta disponibilidad. Se pueden tener varias vistas pero todas orbitan alrededor de un mismo atributo. Esto facilitó la evaluación, pues en esta se toma un escenario y se describe como está el flujo. De hecho durante el ATAM nos saltamos una de las dos fases, porque ya estaba prácticamente hecho.

¿Qué recomendaciones generales harías a los arquitectos en relación con el desarrollo de sus arquitecturas?
Una es que los requerimientos funcionales tienen algún impacto, además de los atributos de calidad, en las decisiones que se toman de arquitectura. Entonces conviene tener una lista lo más amplia posible de funcionalidades que puedan afectar la arquitectura para que se tomen las mejores decisiones al momento de hacer el diseño. La otra es que aunque haya atributos de calidad que aparentemente no sean relevantes para el negocio, siempre hay que considerarlos al momento del diseño, como por ejemplo la facilidad de prueba (testability).
Durante el diseño, que es un proceso iterativo, cuando se agotan los escenarios prioritarios, los que siguen deben analizarse y ahí es donde aparecen los de modificabilidad, testability y otras, además de escenarios adicionales de alta disponibilidad, de recuperación de fallas. Siempre hay escenarios que no son los más críticos pero que
un día van a suceder y por lo tanto son importantes para analizar y considerar en el diseño.

En el desarrollo en general de sistemas, ¿qué tanta importancia crees que haya que darle a la arquitectura? ¿En todo sistema debe cuidarse?
No, no en todo sistema. En sistemas muy pequeños es muy fácil cambiar el sistema para adecuar ciertos atributos de calidad y la arquitectura emerge naturalmente. Mientras más grande el sistema, más importante es. No sé si hay una regla pero al final es el costo de no hacerlo en un sistema chico es menor que en un sistema grande. Por otro lado, aún en sistemas pequeños, si los drivers son muy exigentes, se deben considerar desde el inicio porque después va a ser más difícil satisfacerlos.

Si tuvieras que volver a hacer ese sistema con el conocimiento que tienes hoy en día, ¿qué harías distinto?
Creo que la documentación es algo que siempre es mejorable. Hay muchas decisiones que tomamos en el camino y que no documentamos de la mejor forma o son decisiones implícitas y es mejor hacerlas explícitas desde el momento en que se toman aunque parezcan básicas porque después se olvida. Otra es hacer casos de prueba específicos para la arquitectura desde el principio.

Referencias

1. J. McHale, R. Nord, L. Carballo, “Driving Out Technical Risk by Blending Architecture, Process, and Project Discipline”, http://www.sei.cmu.edu/library/abstracts/presentations/mchale-saturn2012.cfm
2. R. Nord, J. McHale, F. Bachmann, “Combining Architecture-Centric Engineering with the Team Software Process”, http://www.sei.cmu.edu/library/abstracts/reports/10tr031.cfm