¿Qué es la arquitectura de software?

El proceso de arquitectura de software toma los requisitos de los clientes, los analiza y produce un diseño para obtener un software que satisfará sus necesidades. Los diseños exitosos de software deben sopesar las disyuntivas inevitables que surgen debido a requisitos conflictivos; cumplir con los principios de diseño y las buenas técnicas de procedimiento que han evolucionado con el tiempo; y complementar el hardware moderno, las redes y los sistemas de administración. Una arquitectura contundente de software implica tener mucha experiencia en temas teóricos y prácticos, así como la visión necesaria para convertir lo que al parecer son escenarios y requisitos comerciales imprecisos en diseños de trabajo sólidos y prácticos.

La arquitectura de software implica definir una solución estructurada que satisfaga todos los requisitos técnicos y operacionales y, a la vez, optimizar los atributos comunes de calidad como rendimiento, seguridad y capacidad de administración. Además, implica una serie de decisiones basadas en una amplia gama de factores, y cada una de esas decisiones puede tener un considerable impacto sobre la calidad, rendimiento, mantenimiento y éxito general de ese software.

El software moderno rara vez es independiente. Por lo menos, en la mayoría de los casos, interactuará con un origen de datos como una base de datos corporativa que expone la información con la que trabajan los usuarios del software. Habitualmente, el software moderno debe también interactuar con otros servicios y funciones de red para realizar autenticación, obtener y publicar información, y ofrecer una experiencia de usuario integrada. Si no se cuenta con una arquitectura adecuada, puede que sea difícil o incluso imposible implementar, operar, mantener e integrar el software correctamente con otros sistemas, y no podrá cumplir los requisitos del usuario.

La arquitectura de software se puede considerar como un mapeo entre lo que un software debe lograr y los detalles de la implementación como código. Al obtener la arquitectura correcta se garantizará la coincidencia óptima entre requisitos y resultados. El software con buena arquitectura llevará a cabo las tareas especificadas dentro de los parámetros de los requisitos originales y lo hará de una forma que maximice el rendimiento, la seguridad, confiabilidad y muchos otros factores.

En su máximo nivel, el diseño arquitectónico debe exponer la estructura del sistema pero ocultar los detalles de implementación; percatarse de todos los casos y escenarios de uso; intentar abordar los requisitos de todas las partes interesadas; y satisfacer lo más posible todos los requisitos funcionales y de calidad.

¿Por qué es importante la arquitectura de software?

Los requerimientos del software moderno son cada vez más complejos puesto que los usuarios esperan más de sus aplicaciones. Las aplicaciones de escritorio independientes y sencillas ya no son lo suficientemente buenas en la mayoría de los escenarios comerciales y empresariales. En nuestro mundo conectado, la aplicación debe interactuar con otras aplicaciones y servicios y ejecutarse en una serie de entornos, como la nube, y en dispositivos portátiles. Los diseños monolíticos comunes en el pasado se han reemplazado por software componentizado orientado al servicio, que utiliza marcos, sistemas operativos, hosts en tiempo de ejecución y redes para implementar características que eran insólitas hasta hace unos pocos años.

Esta complejidad afecta no sólo al diseño, sino también a la implementación, mantenimiento y administración del software. El costo total de propiedad (TCO) del software ahora se compone predominantemente de costos posteriores a la implementación. Una aplicación con buena arquitectura minimizará el TCO al reducir el costo y tiempo requeridos para implementar la aplicación, mantenerla en ejecución, actualizarla para cumplir con los requisitos cambiantes y solucionar problemas. Además simplificará el soporte técnico y la administración por parte del usuario.

El software también debe cumplir varios criterios fundamentales para tener éxito. Debe proporcionar seguridad de manera que la aplicación y sus datos estén protegidos contra ataques malintencionados y errores accidentales. Debe ser robusto y confiable para minimizar los errores y los costos asociados. Debe ejecutarse dentro de los parámetros requeridos para satisfacer las necesidades del cliente, como un tiempo de respuesta máximo o una capacidad de carga de trabajo específica. Debe ser sostenible para poder minimizar los costos de administración y soporte técnico y suficientemente extensible para permitir los cambios y actualizaciones inevitables que se requerirán con el tiempo.

Todos estos factores implican algunas desventajas. Por ejemplo, la implementación de los mecanismos más seguros mediante un cifrado complejo afectará el rendimiento. La implementación de opciones de configuración y actualización de amplio rango puede hacer que la implementación y administración sean más complicadas. Además, cuanto más complejo sea el diseño, más costará implementarlo. Una buena arquitectura tendrá como objetivo equilibrar estos factores para producir el resultado óptimo en el escenario específico.

¿Qué hace un arquitecto de software?

La arquitectura de software comienza con un conjunto de requisitos. Estos puede expresarse en forma de diagramas, diagramas de flujo de proceso, modelos o listas documentadas de tareas operacionales que el software debe realizar. Es habitual que el cliente o el socio también expresen requisitos menos precisos, como la apariencia o la manera en que ciertas interfaces de usuario deben funcionar en tareas comunes. Los requisitos también deben incluir información sobre el software, sistemas, hardware y redes existentes con que va a interactuar el nuevo software; y otros factores como el plan de implementación y mantenimiento y, desde luego, el presupuesto disponible para el proyecto.

El arquitecto de software debe considerar las necesidades del cliente. Sin embargo, el término general “cliente” habitualmente comprende tres áreas de responsabilidad en conflicto: los requisitos empresariales, los requisitos del usuario y los requisitos del sistema. Los requisitos empresariales por lo general definen una serie de factores, como los procesos de negocios, los factores de rendimiento (como seguridad, confiabilidad y capacidad de proceso) y las restricciones de presupuesto y costos. Los requisitos del usuario incluyen el diseño de interfaz, capacidades operativas y facilidad de uso del software. Los requisitos del sistema incluyen el hardware, las redes y las capacidades y restricciones del entorno en tiempo de ejecución. En la figura 1 se muestra cómo pueden variar estos distintos requisitos, de modo que el arquitecto debe trabajar hasta lograr un diseño que se ajuste al área de superposición.

requisitos conflictivos de un cliente típico
Figura 1: los requisitos conflictivos de un cliente típico

Cada arquitecto de software tiene su propio enfoque para recopilar y analizar requisitos y para definir la arquitectura. No obstante, algunas preguntas que generalmente deben responder son: “¿cómo trabajarán los usuarios con la aplicación?”; “¿cómo se implementará la aplicación en producción y cómo se administrará?”; “¿cuáles son los requisitos de atributos de calidad para la aplicación, como seguridad, rendimiento, concurrencia, internacionalización y configuración?”; “¿cómo se puede diseñar la aplicación para que sea flexible y sostenible a través del tiempo?”; “¿cuáles son las tendencias arquitectónicas que podrían tener impacto en la aplicación ahora o después de su implementación?”

Esta última pregunta es interesante e importante. Un buen diseño de software no sólo satisface los requisitos del cliente ahora, sino que continúa haciéndolo en el futuro inmediato. Esto influye en las decisiones que debe tomar el arquitecto acerca del hardware, los componentes, marcos, plataformas de tiempo de ejecución, sistemas de software de administración y muchos otros factores incorporados en el software o con los que éste debe integrarse.

Al igual que la mayoría de las tareas en el mundo del diseño y desarrollo de software, diseñar la arquitectura es un proceso inicial y a la vez iterativo. Muchas tareas iniciales como el análisis de requisitos, la investigación técnica y la identificación de objetivos habitualmente se producen al comienzo del proceso. El siguiente paso consiste en identificar los escenarios clave para el diseño. Estos son los requisitos primarios que debe cumplir el software y las restricciones dentro de las que debe operar. A partir de esta información, el arquitecto puede generar una descripción general de la aplicación. Esta descripción general abarca detalles de alto nivel, como el tipo de aplicación (web, teléfono, escritorio o nube), la arquitectura de implementación (habitualmente un diseño por niveles con componentes que se comunican sobre límites de hardware y de red), los estilos adecuados de arquitectura que se seguirán (como de n niveles, cliente-servidor u orientada al servicio) y las tecnologías de implementación que se adaptan mejor al escenario.

Desde allí, el arquitecto puede comenzar a generar diseños candidatos que satisfagan los requisitos de alto nivel y los más importantes que se identificaron anteriormente. El diseño después se revisa y se pone a prueba frente a los escenarios clave, a menudo en conjunto con las observaciones del cliente y versiones de ensayo o prueba, para garantizar que ofrezca la solución óptima. Esto es poco probable durante la primera iteración, pero a medida que el ciclo se repite el diseño finalmente convergirá en los requisitos y escenarios clave. En la figura 2 se muestra este enfoque iterativo.

proceso de diseño arquitectónico iterativo
Figura 2: un proceso de diseño arquitectónico iterativo

A medida que el diseño se vuelve más pormenorizado y se identifican las tareas y componentes individuales, el arquitecto puede seguir refinando y agregando detalles a cada etapa. Por ejemplo, luego de identificar el estilo arquitectónico y el enfoque de implementación, el arquitecto puede tomar decisiones respecto a la comunicación entre niveles y componentes. Es posible que esto incluya la elección de un protocolo según los requisitos actuales y futuros y la consideración de presentaciones preliminares de la nueva tecnología y las capacidades definidas en próximos estándares.

El producto final del trabajo de un arquitecto generalmente es un conjunto de esquemáticas, modelos y documentos que definen la aplicación desde varias perspectivas de manera que, al combinarse, proporcionen a los desarrolladores, equipos de prueba, administradores y a la administración general toda la información necesaria para implementar el diseño. Esta información describirá la estructura y el diseño de las partes componentes y los niveles de aplicación; la forma en que se manejan asuntos de alcance general como registro y validación; el plan de pruebas e implementaciones; y la documentación para asistir a desarrolladores, administradores y personal de soporte técnico.

El diseño final también debe especificar los atributos de calidad que debe cumplir la aplicación. Estos constituyen el resultado de las decisiones y compensaciones realizadas por el arquitecto con el asesoramiento del cliente. Estos atributos incluyen definiciones de los requisitos de seguridad y su plan de implementación, la escalabilidad y el rendimiento requeridos al implementarse en la plataforma de destino, las formas en que se implementan el mantenimiento y la extensibilidad, y las características que permiten la interoperabilidad con otros sistemas.

¿Qué habilidades necesita un arquitecto de software?

Es evidente que un arquitecto de software requiere una amplia gama de habilidades tanto generales como técnicas. Durante el análisis de requisitos y las etapas de revisión, el arquitecto debe trabajar con el cliente, consultar a socios y otros miembros del equipo y actuar como un intermediario para gerentes, usuarios y administradores de sistemas. Al sobresalir en estas habilidades generales se puede producir un mejor plan inicial y un conjunto más preciso de requisitos, lo que ahorra tiempo y esfuerzo más adelante.

El arquitecto de software también debe poseer las habilidades técnicas que se requieren para comprender cómo los modernos sistemas de software, los marcos y el hardware admiten los requisitos; cómo los factores de red y sistema operativo pueden afectar las decisiones de diseño; y cómo las tendencias y los cambios en estas áreas tendrán un impacto sobre el diseño. Después del análisis inicial de requisitos, el arquitecto de software también debe aplicar sus habilidades técnicas en torno a patrones de diseño, estándares de comunicación y mensajería, capacidades de código, problemas de seguridad y restricciones de rendimiento. Todos estos requieren un conocimiento profundo de las tecnologías que se usarán para implementar el software final.

Por supuesto, la arquitectura de software también requiere visión. El ser capaz de ver cómo los sistemas se integrarán y pueden interoperar, cómo serán particionados e implementados y cómo interactúan con los usuarios a menudo sólo se puede determinar una vez que el arquitecto ve en su mente la solución en general. Esto requiere un enfoque organizado y mucha atención a los detalles para intercalar y comprender todos los requisitos y restricciones, y para transformarlos gradualmente en un diseño técnico fluido e integral. Sin embargo, también se requiere talento e imaginación para poder visualizar el resultado final y luego trabajar metódicamente hacia la solución ideal.