Paso 2: ¿Qué es eso de Arquitectura Técnica?

Si voy a añadir una tercera planta a mi casa de campo de dos plantas, contrataré a un arquitecto que compruebe que los pilares soportan la nueva estructura y que diseñe de forma integrada esa tercera planta. No parece muy sensato que empiece a poner ladrillos sin comprobar que el resto de la estructura puede aguantar el nuevo peso; ni tampoco parece sensato que ponga madera en una casa construida con mármol (es decir, que cambie radicalmente el material de construcción). Tampoco parecería muy sensato que hiciera una larga escalera para acceder a esa tercera planta si voy en silla de ruedas.

Con los Sistemas de Información sucede algo parecido. Es díficil encontrar una organización que no tenga alguna aplicación de negocio con una infraestructura determinada. Lo normal es que cuando construya una nueva aplicación de negocio quiera integrar algo de información de la(s) anterior(es) aplicacion(es) de negocio; incluso, que quiera reutilizar alguna de las infraestructuras (preferentemente la base de datos y los equipos clientes, normalmente con un sistema operativo Microsoft Windows).

En cambio, está muy extendida la idea de que los Sistemas de Información aguantan cualquier cosa. Es verdad que un entorno virtual nos permite más niveles de libertad que un entorno físico; aunque la realidad es que en un entorno virtual las chapuzas se ven menos (aunque se sufren más). 

El segundo paso en el diseño (los planos) de una aplicación de negocio es especificar técnicamente una solución integrada. Se toman los requisitos que nuestro cliente nos ha detallado (las especificaciones funcionales) y se resuelven de forma técnica; en esta resolución técnica, una parte importante es la arquitectura que permite la cohabitación de la nueva aplicación de negocio con el entorno informático existente en la organización. Puede ser muy liviana (la organización no tiene una infraestructura tecnológica específica o la nueva aplicación no necesita una fuerte integración con las aplicaciones existentes) o muy compleja (es una nueva aplicación de negocio que se ubica en el núcleo de la organización con una fuerte integración con aplicaciones complejas existentes definida en un entorno complejo y reutilizable).

Otro aspecto importante a tener en cuenta en una buena arquitectura técnica es el futuro: nos facilitará el mantenimiento y la evolución de la aplicación de negocio. Si está bien planteada no nos encontraremos, en un futuro, con la necesidad de prescindir de nuestra aplicación de negocio (lo que se llama tirar la inversión al cubo de la basura) sino que podremos construir a partir de ella sobre bases sólidas.

Por último, reseñar que una arquitectura técnica ni es tan fácil ni tan díficil de definir como puede parecer; existen modelos de documentos que nos preguntan lo que tenemos que incluir. Por eso es bueno utilizar una Metodología de desarrollo y seguir unos Estándares de documentación. Vamos, no pensar que con unos garabatos en una servilleta de bar ya tenemos hechos los planos de nuestro edificio...