El término arquitectura siempre había estado asociado a cosas tangibles, es decir, que se pueden ver y tocar.
La arquitectura de software viene a cambiar eso.
El software es puro conocimiento, instrucciones que una máquina puede ejecutar.
Por lo tanto, a diferencia de las cosas que se pueden ver y tocar, el software nunca se rompe (el software que falla siempre ha estado malo) ni se gasta, el software bueno puede funcionar para siempre, está hecho de bits (la máquina en la que funciona sí se rompe y se gasta, está hecha de átomos).
Las ingentes cantidades de tiempo, esfuerzo y dinero que consume el mantenimiento de software se deben a dos motivos únicamente: o el software está malo y por lo tanto debe ser corregido, o los requerimientos cambian y por lo tanto debe ser modificado.
Existe la creencia de que la arquitectura del software es un asunto muy técnico que únicamente compete a los informáticos y expertos en computación.
Sin embargo, si se considera que el factor más importante en la contención del gasto en mantenimiento de software es la arquitectura, y dado que el mantenimiento consume la mayoría del gasto total en las tecnologías de la información (TI) –el mayor rubro de gasto de capital del mundo occidental– se hace obvio que los gerentes y jerarcas se deberían preocupar por entender la arquitectura del software.
El software monolítico dio paso, hace 15 años, al software cliente/servidor y este, a su vez, dio paso (hace 5 años) al software construido a base de componentes y orientado a servicios.
Es la arquitectura (no la tecnología) la que hace a un software flexible o no, capaz de adaptarse rápidamente a los nuevos requerimientos.
Con un software flexible es posible obtener agilidad empresarial. Los que dejan la arquitectura del software en manos de los técnicos se merecen lo que les pase.
Artículo publicado en el periódico La Nación
