PDF de programación - Arquitectura de Sistemas: Un enfoque Evolutivo

Arquitectura de Sistemas 1

Arquitectura de Sistemas:

Un enfoque Evolutivo

Puedes descargar la última versión de este documento de:

http://blog.unlugarenelmundo.es/?page_id=127

(versión 1.2)

José María Morales Vázquez

[email protected]

Resumen. La mayor parte de las empresas modernas comienzan a subdividir
las antiguas unidades de sistemas en dos grupos de trabajo bien difereciados:
aquellos que se encargan de la infraestructura y los que comienzan a denomi-
narse arquitectos de sistemas. Este documento, una traducción al castellano casi
literal de un white paper de Quidnunc, una empresa especializada en gestión de
configuración, que explica la importancia de esta subdivisión y las pautas a
seguir a la hora de diseñar la arquitectura de sistemas de una empresa.

Arquitectura de Sistemas 2

1 Introducción

Entendemos por arquitectura en un proyecto informático a la disposición conjunta y
ordenada de elementos software y hardware para cumplir una determinada función.
No es difícil de comprender que si mezclamos arquitecturas distintas e inconsistentes
sin ningún tipo de orden o planificación el proyecto se puede convertir fácilmente en
ingovernable, tanto o más cuanto mayor sea la envergadura del mismo.

La mayoría de las organizaciones suelen favorecer (de forma planificada o no)
unas configuraciones concretas. La arquitectura de cada empresa debería describir
estas configuraciones y el entorno que facilite crear nuevas funcionalidades que enca-
jen en ella, incluyendo directivas, componentes de software reutilizables, herramien-
tas, etc.

Para facilitar que las nuevas funcionalidades de que dotemos a nuestra arquitectura
sean consistentes con el sistema actual y las posibles modificaciones futuras de este,
necesitamos conocer dicha arquitectura, pero es mucho mas importante conocer la ar-
quitectura operativa y organizacional de la empresa.

Una distinción importante es la que existe entre la arquitectura de una simple apli-
cación (micro arquitectura) y la que existe entre y a través de las distintas aplicacio-
nes (macro arquitectura). No hace falta decir que esta última es la mas compleja e im-
portante.

1.1 Divide y vencerás

¿Cuál es el papel de la arquitectura en una organización? Imaginemos que nuestra or-
ganización consta de cuatro capas. La capa superior está formada por las actividades
propias de la organización en si misma. Debajo se encontrarían las aplicaciones infor-
máticas que soportan y facilitan esas actividades. Por debajo de las aplicaciones se
encuentra la arquitectura que facilita que estas se desarrollen y ejecuten. En último
lugar, yace la infraestructura como el hardware o las redes físicas.

Esta subdivisión en cuatro capas nos facilita determinar el papel que desempeña la
arquitectura dentro de una organización. Cada capa actúa como cliente de la capa in-
ferior a ella y como servidor de la capa superior. Los arquitectos no deben de malgas-
tar su tiempo en temas relacionados con la infraestructura, tales como el sistema ope-
rativo. La mejor forma de separar la arquitectura de la infraestructura es tener en
mente el esquema de cuatro capas antes mencionado: la infraestructura debe de dar
soporte a la arquitectura. Mezclar erróneamente conceptos de una y otra capa es un
error muy común en muchas organizaciones.

Arquitectura de Sistemas 3

Un error en el que no debe de caer un arquitecto de sistemas es ser demasiado pre-
ceptivo. Introducir demasiadas normas que creen una excesiva rigidez provocará pro-
blemas en el desarrollo de aplicaciones. Un buen arquitecto de sistemas debe de tener
siempre en mente que su principal finalidad es permitir la creación de aplicaciones,
facilitando la creatividad y la innovación de los creadores de las mismas.

La arquitectura de sistemas en los tiempos en los que sólo existían los mainframes
era muy sencilla: existía un lugar para cada cosa y cada cosa tenía su lugar adecuado.
Con el paso de los años y siempre en busca de una mayor flexibilidad se han ido in-
troduciendo estructuras cada vez mas y mas complejas: arquitectura cliente / servidor,
arquitectura a tres capas, message brokers, data warehouses, objetos distribuidos, ar-
quitecturas webs...

Un buen arquitecto debería de empezar por recordar que su trabajo es hacer la vida

mas fácil a los desarrolladores, y no al revés...

Existe otra idea que subyace tras todos los enfoques: especialización: dividir los
problemas en sus partes constituyentes y resolverlas separadamente con equipos de
especialistas centrados en un área único. La especialización deja dos puntos sin res-
puesta: como dividir los sistemas para que puedan ser definidos separadamente y
como unirlos posteriormente para formar un todo homogéneo. Estos son los principa-
les retos de la moderna arquitectura de sistemas.

2 Arquitectura Evolutiva

Pero, ¿y desde el punto de vista de la empresa? ¿qué características debería de reunir
la arquitectura de sistemas?

Si la mejora en los procesos y aplicaciones redunda en un mejor rendimiento de la
empresa, y si para mejorar las aplicaciones necesitamos mejorar los sistemas, enton-
ces la arquitectura de sistemas debería de ser el vehículo de desarrollo de ambos. En
la práctica la arquitectura de los sistemas actuales constituyen, en muchos casos,
grandes obstáculos para los dos.

A principios de los años 90, la arquitectura de sistemas no iba mas allá de una
mera planificación. Definimos una arquitectura objetivo e ideamos una estrategia y
una planificación para completarla dentro de unos determinados plazos de tiempo. La
principal ventaja de este enfoque es que la hace comprensible a los ejecutivos, pues es
similar a la forma en que tienen en dirigir sus negocios. El principal inconveniente es
que no funciona. Comienza definiendo una arquitectura objetivo y esto es un error. El
único objetivo que debe de tener en mente el arquitecto de sistemas es el de la organi-
zación para la que trabaja, si no tarde o temprano entrara en conflicto con el. La ar-
quitectura del sistema debe de ser lo suficientemente flexible como para acomodarse

Arquitectura de Sistemas 4

a los cambios de objetivos de la organización. Esta es la clave principal para asegurar
su longevidad.

La segunda clave a tener en cuenta es la que nos proporciona la mejor forma de
medir la bondad de una arquitectura: la forma en que sustenta a las aplicaciones que
sustentan a la organización. La mejor forma de verlo es estudiar, dada una nueva fun-
cionalidad necesaria para nuestra empresa, como la arquitectura del sistema facilita su
desarrollo e integración con el resto de las aplicaciones.

Los elementos claves que debe de cumplir nuestra arquitectura para facilitar el de-
sarrollo de nuevas aplicaciones son: tener unas directivas claramente definidas pero
no rígidas en exceso ni dictatoriales en cuanto al uso de determinadas tecnologías o
fabricantes, favorecer el uso de aplicaciones que posean una funcionalidad base y
sean personalizables por el usuario y facilitar el uso y desarrollo de componentes y
plug-ins y aplicaciones que los admiten.

Este enfoque nos permite en la mayoría de los casos encontrar la forma mas rápida
y sencilla de desarrollar una nueva funcionalidad para nuestro sistema en los casos en
los que lo mas importante es tener una aplicación que nos haga lo que queremos y no
tener la mejor aplicación que haga lo que queremos. Hoy en día, en la práctica, esta es
la solución que necesitamos en la mayoría de los casos. Estos son los principios del
enfoque que se conoce como evolutivo.

El modelo evolutivo, en el cual la arquitectura del sistema va adaptándose paso a
paso, cada uno de ellos basado en los anteriores y siendo el mejor de todos los posi-
bles que podemos dar en cada momento y no siguiendo un plan maestro tiene un po-
deroso antecedente: la evolución natural. Esta posee dos elementos cruciales: un mé-
todo de producir variantes (la reproducción) y un método de elegir la mejor entre es-
tas (la supervivencia de los mas fuertes).

Los métodos evolutivos son también muy populares en el desarrollo de software a
medida: las aplicaciones suelen construirse mediante una serie de pasos consecutivos
y no de una sola vez, reduciendo así considerablemente el riesgo de fallos y el coste
de desarrollo. Estrictamente hablando, en este caso el termino evolución no está bien
usado puesto que no existe ni variación ni selección. Un termino mas adecuado sería
desarrollo incremental.

Al igual que en la evolución natural, las variantes en el mundo de la informática
son abundantes y sólo los sistemas mas abiertos sobreviven. Es fundamental crear un
entorno que propicie la tecno-diversidad en la arquitectura del sistema.

Una excepción a esta teoría la constituyen, en si mismos, los mainframes, los cua-
les han resistido mas de lo que se podía esperar a pesar, incluso, de la epidemia del
año 2000. El problema es como crear un entorno que facilite la tecno-diversidad, don-

Arquitectura de Sistemas 5

de las arquitecturas preestablecidas sobrevivan donde sea necesario pero sin bloquear
el paso de los nuevos esquemas.

Las organizaciones con arquitecturas evolutivas poseen ciertos rasgos en común:

 Prefieren las directivas a los standards. Los standards reales son minima-
listas y usualmente ‘de hecho’ como Windows. Las directivas pueden pa-
sarse por alto si existe una razón lo suficientemente buena. La mayoría de
las organizaciones mantienen demasiados standards motivados por la re-
ducción de costes (por ejemplo, mantienen UNIX en el back-end para
minimizar el coste de reeducación) pero fallan al ignorar el coste que su-
pone forzar a determinadas aplicaciones que necesitan realmente tomar
una línea diferente. La flexibilidad es una necesidad fundamental en la
arquitectura de los sistemas modernos.

 Usan tecnología orientada a componentes. La historia de la informática
descr