Nota de opinión de Adrian Anacleto publicada en el Cronista Comercial 14/06/2011 edición impresa
Arquitectura de software: el negocio de la calidad en IT
Arquitectura en práctica. Piense, rápidamente, en una empresa a la que se le caen las aplicaciones, funcionan lentas o le roban datos. Seguro que encontró varios ejemplos. Esto ocurre a menudo y es más común de lo que parece.
Los usuarios de sistemas suelen evidenciar en el uso cotidiano algunas cuestiones de calidad de los sistemas, programas o aplicaciones. Detrás de las expresiones o quejas más comunes que suelen hacer, podemos encontrar referencias a atributos de calidad de una aplicación de software. Al decir: la aplicación anda lento, se habla de performance; si escuchamos la aplicación se cae, el atributo de calidad referido es disponibilidad y si alguien dice no entiendo esta aplicación, es muy compleja, está hablando de usabilidad. Y podríamos seguir nombrando ejemplos, porque las aplicaciones tienen cientos de atributos de calidad, entre los más famosos están: seguridad, facilidad de mantenimiento, de modificación, de testing y muchos otros. Estos se encuentran definidos por normas y estándares de calidad de injerencia mundial como ser ISO, la IEEE (www.ieee.org) y Mitre (www.mitre.org).
Por otro lado, más del 65% del costo total de propiedad de una aplicación se gasta en la etapa de mantenimiento del sistema, es decir, una vez que el software ya está construido. Quiere decir que, si el desarrollo de un producto cuesta u$s 700.000, el mantenimiento le llevará al menos u$s 1,3 millón. Por lo cual, si un arquitecto de software pudiera reducir este costo en un 15%, significaría un ahorro de u$s 195.000. Sin embargo, es posible tener un producto de software económico y fácil de mantener; todo tiene que ver con la calidad. Vale la pena analizar el negocio de la calidad de software y cuál es el rol que juega la arquitectura de en este proceso.
El papel del arquitecto
Muchas veces, al querer optimizar una aplicación para que alcance muchos de estos atributos de calidad a la vez, el costo se dispara y, en muchos casos, lo hace de forma exponencial. Se puede decir que, para que una aplicación funcione correctamente, no sólo tiene que cumplir con la funcionalidad para la cual fue diseñada, sino que lo tiene que hacer en forma ágil, segura y a bajos costos de manutención.
Analicemos el caso de Twitter. ¿Por qué es tan sencillo? Principalmente, porque es usable (en este caso amigable y simple) y tiene un corto tiempo de respuesta (performance) en general, lo que nos lleva a pensar que hay cosas que quedan afuera. ¿Qué pasa con la disponibilidad? ¿Twitter funciona 24 horas los siete días de la semana? La respuesta es no. Cuando queremos hacer algo que pone en riesgo la performance de Twitter, aparece una pantalla con un mensaje que nos explica que Twitter is over capacity(Twitter sobrepasó su capacidad), lo cual indica que el sitio no se cayó, pero, en ese momento, no se puede operar. No obstante, no hay dudas de que, cuando anda bien, es rápido y usable. Ahora, ¿qué pasaría si Twitter permitiera 50.000 caracteres en vez de 140? ¿Qué impacto cree que tendría en la performance? ¿En la disponibilidad? ¿Y en la facilidad de uso? Detrás de los atributos de calidad de una aplicación hay un ser responsable de los mismos, que balancea las ecuaciones: el arquitecto. Para poder visualizarlo, se puede pensar en el personaje de la película Matrix, aquel señor de barba que, en una sala llena de pantallas, le decía Neo (el protagonista) que él era el responsable de mantener el balance de todas las ecuaciones para que la matrix funcione. Este arquitecto era el diseñador de la matrix, la persona detrás del sistema. Un arquitecto de software debe no solo lidiar con la aplicación en sí, sino que debe ser capaz de diseñar y construir con las restricciones intrínsecas del negocio (dinero, staff actual, equipo disponible, tecnología, entre otros). Es el responsable de la plataforma, tecnología y arquitectura definida, de tal forma que la misma escale y pueda hacer frente a los desafíos futuros del negocio.
La raíz de muchos fracasos en proyectos de software suele estar en una deficiente arquitectura. Los números hablan por sí solos: el 70% de las aplicaciones tienen problemas de disponibilidad o performance. El arquitecto tiene que lidiar con todos estos factores y, además, debe saber explicarlos. Para esto, existen métodos formales de evaluación de arquitectura, y grupos de trabajo donde aprender y formarse.
Todo, más sencillo
Para llevar adelante la tarea de definición y mantenimiento de una arquitectura de software, existen métodos formales de evaluación de arquitecturas. Si bien la mayoría de los métodos trabajan sobre una definición y sobre los requerimientos, existen formas innovadoras para trabajar sobre aplicaciones sin documentación (o con escasa documentación) e incluso hacerlo sobre la misma aplicación en producción.
Todo resulta más sencillo cuando se vuelve natural identificar qué hay detrás de las aplicaciones con calidad deficiente y de aquellas con mucha funcionalidad y poca performance o poca seguridad, las que son muy costosas de mantener. Detrás, estará el rol del arquitecto de software y la arquitectura de software como práctica en esa empresa. La pregunta entonces debería ser: ¿hay un arquitecto de software en esa compañía? ¿Tiene los conocimientos necesarios? ¿Son respetadas y seguidas su definiciones a lo largo del ciclo de vida del producto? ¿Hay un proceso de arquitectura?
Aunque probablemente las respuestas a muchas de esas preguntas sean negativas, nunca es tarde para empezar a trabajar sobre la arquitectura de software y ocuparse de los atributos de calidad más importantes, para que la aplicación cumpla con la funcionalidad para la que fue diseñada.
