ARQUITECTURA EVOLUTIVA Y, desde el punto de vista de la empresa, qu caractersticas debera reunir la arquitectura de sistemas?

Si mejorar los procesos y las aplicaciones genera un mejor rendimiento de la empresa, y si para mejorar las aplicaciones necesitamos mejorar los sistemas, entonces la arquitectura de sistemas debe ser el vehculo de desarrollo para ambos. En la prctica, la arquitectura de los sistemas actuales constituye, en muchos casos, grandes obstculos para los dos. A principios de los 90 la arquitectura de sistemas no iba ms all de simple planificacin: se define una arquitectura objetivo y se idea una estrategia y una planificacin para completarla dentro de unos plazos determinados. La principal ventaja de este enfoque es que la hace comprensible a los ejecutivos, pues es similar a la forma en que tienen que dirigir sus negocios. El principal inconveniente es que no funciona, ya que comienza por la definicin de una arquitectura objetivo y esto es un error. El nico objetivo que debe tener en mente el arquitecto de sistemas es el de la organizacin para la que trabaja, si no tarde o temprano entrar en conflicto con l. La arquitectura del sistema debe de ser lo suficientemente flexible como para adaptarse a los cambios de objetivos organizacionales, esta es la clave principal para asegurar su longevidad. La segunda clave a tener en cuenta es la que proporciona la mejor forma de medir la bondad de una arquitectura: la forma en que sustenta las aplicaciones que a la vez sustentan la organizacin. La mejor forma de verlo es estudiar, dada una nueva funcionalidad necesaria para la empresa, cmo la arquitectura del sistema facilita su desarrollo e integracin con el resto de las aplicaciones. Los elementos claves que debe cumplir la arquitectura, para facilitar el desarrollo de nuevas aplicaciones, son: tener directivas claramente definidas, no rgidas ni dictatoriales en cuanto al uso de determinadas tecnologas 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 admitan. Este enfoque permite, en la mayora de los casos, encontrar la forma ms rpida y sencilla de desarrollar una nueva funcionalidad para el sistema, en los casos en los que lo ms importante es tener una aplicacin que haga lo que queremos y no tener la mejor aplicacin que haga lo que no queremos. Actualmente, en la prctica, esta es la solucin que se necesita en la mayora de los casos, y son los principios del enfoque conocido como evolutivo. El modelo evolutivo al que la arquitectura del sistema se adapta paso a paso surge del concepto de dependencia, en el que cada uno de ellos se basa en los anteriores para ~ 98 ~ perfeccionarse y evolucionar en cada momento, sin seguir un plan maestro pero de acuerdo con una evolucin natural. Esta evolucin posee dos elementos cruciales: un mtodo para producir variantes -la reproduccin- y un mtodo para elegir la mejor entre ellas -la supervivencia de los ms fuertes. Los mtodos evolutivos tambin son populares en el desarrollo de software a medida: las aplicaciones suelen construirse mediante una serie de pasos consecutivos y no de una sola vez, lo que reduce considerablemente el riesgo de fallos y el costo de desarrollo. En este caso y dado que no existe variacin ni seleccin, el trmino evolucin no se aplica adecuadamente, y por el contrario el trmino ms adecuado sera desarrollo incremental. Igual que en la evolucin natural, las variantes en el mundo de la informtica son abundantes y slo los sistemas ms abiertos sobreviven. Es fundamental crear un entorno que propicie la tecno-diversidad en la arquitectura del sistema,

y una excepcin a esta teora la constituyen, en s mismos, los mainframes, que han resistido ms de lo que se poda esperar, incluso luego de la epidemia del ao 2000. El problema es cmo crear un entorno que facilite la tecnodiversidad, en el que las arquitecturas preestablecidas sobrevivan donde sea necesario, pero sin bloquear el paso a los nuevos esquemas. Las organizaciones con arquitecturas evolutivas poseen ciertos rasgos en comn: Prefieren las directivas a los estndares. Los estndares reales son minimistas y usualmente de hecho como Windows; las directivas pueden obviarse si existe una razn lo suficientemente buena. La mayora de las organizaciones mantienen demasiados de ellos, motivados por la reduccin de costos -por ejemplo, mantienen UNIX en el back-end para minimizar el costo de reeducacin-, pero fallan al ignorar el costo que supone forzar a determinadas aplicaciones que requieren en realidad tomar una lnea diferente. La flexibilidad es una necesidad fundamental en la arquitectura de los sistemas modernos. Usan tecnologa orientada a componentes. La historia de la ingeniera de sistemas describe un viaje inexorable hacia la especializacin. Los componentes de hoy son ms flexibles y es posible ya reutilizar el software que prometiera desde hace tiempo la programacin orientado por objetos. Juzgan la arquitectura del sistema desde el punto de vista del usuario. Invierten en infraestructura. Ahorrar gastos en hardware o comunicaciones es a menudo un falso ahorro: un efecto de los das en que estas cosas eran caras. Ahorrar dinero ahora traer otros gastos posteriores. Reflejan la arquitectura de su organizacin en la arquitectura del sistema. Por ejemplo, organizaciones centralizadas necesitan un sistema centralizado, mientras que organizaciones descentralizadas se adaptan mejor a sistemas distribuidos. Esto es una directiva ms que una regla. A la hora de elegir entre distintas aplicaciones toman como principales criterios la facilidad de uso y el impacto en el negocio. Eliminan los proyectos fallidos o dbiles rpidamente. Cada dlar invertido en un proyecto dbil o fallido es un dinero malgastado dos veces: aprende la leccin, evita recriminaciones y corrige el problema. Valoran el capital intelectual. El principal activo de un departamento de arquitectura de sistemas son las personas y los procedimientos que conocen o desarrollan. Es preciso cuidar apropiadamente esos aportes. Evitan innovaciones

LA ARQUITECTURA DE SISTEMA MODERNO LA ARQUITECTURA MODERNA Publicar un conjunto de valores para una arquitectura requiere que estar bien informados. El punto de vista de un jefe de arquitectura debe contemplar los siguientes puntos: Estndares. El desarrollo de Internet y todas las tecnologas que van con ella est revolucionando el mundo de la informtica. Algunos de sus efectos son rpidamente visibles, pero otros no lo son tanto. El jefe de arquitectura debe de estar bien informado de los estndares emergentes. En algunos casos aparecen problemas serios a la hora de tomar partido por dos estndares que, aparentemente, poseen la misma funcionalidad; por ejemplo DCOM y CORBA. La decisin debe tomarse recopilando informacin claramente imparcial y, si no es posible o no es lo suficientemente aclaratoria, deben probarse. Lo peor que se puede hacer es no usar ninguno de los dos. La capa intermedia. Ya se vio que uno de los grandes progresos de la arquitectura moderna es la subdivisin del software. El pegamento que une estas partes para formar una aplicacin completa, es lo que se conoce como middleware. Por ejemplo, dos programas A y B corriendo separadamente cada uno en una mquina: A llama a B con un problema; B trabaja en la resolucin del mismo y cuando acaba devuelve la respuesta a A. El middlewarees el que permite esta funcionalidad, pero existen algunos problemas derivados de esta forma de actuacin qu debera hacer el proceso A mientras que B trabaja en la resolucin de su problema? esperar? Cmo puede B comunicarle a A algo a menos que ste lo requiera? Cmo puede B saber dnde se encuentra A? Qu hace A si B se cae? Si B es reemplazado? Si cientos de As requieren una respuesta de una nica instancia de B? Como vemos, los middlewares deben resolver complejas situaciones pero sin aadir excesiva complejidad a la arquitectura. Existen dos tipos esenciales de middlewares: los basados en Remote Procedure Calls RPC y los basados en Message Oriented Middleware MOM. Middlewares basados en MOM son inherentemente asncronos y lo ms difcil en ellos es definir correctamente la estructura de los mensajes. Los middlewares basados en RPC son ms sencillos de usar, puesto que la sintaxis de las llamadas es prcticamente idntica a la de una llamada en C, pero el rendimiento de estos sistemas suele ser ms pobre. Existen algunos fabricantes que distribuyen productos capaces de funcionar en uno u otro modo. La mejores herramientas de hoy estn basadas en CORBA, estn orientadas a mensajes y tienen como inconveniente que son ms difciles de usar por los programadores. Las herramientas de Microsoft basadas en COM+ son ms limitadas pero muy sencillas de usar y son recomendables si anteponemos esta caracterstica a la longevidad y la calidad del producto. Estructura cliente/servidor a dos o tres capas. La estructura cliente/servidor a dos capas naci el da en que alguien conecto su PC a una mquina UNIX. A los usuarios les gusta la facilidad de uso de los PC y a los administradores la seguridad que les reporta un servidor UNIX. Nadie lo llam entonces arquitectura a dos capas porque no exista ninguna otra. La novedad de contar con una interfaz grfica en lugar de una pantalla verde en modo texto fue bien recibida. Los desarrolladores comenzaron entonces a enriquecer sus productos con nuevas funcionalidades a sus productos, gracias a las mejores herramientas de desarrollo existentes para los PC. Los clientes engordaron hacindose ms pesados y lentos. La alternativa, meter parte de esta

nueva funcionalidad en el backend no era demasiado atractiva, as que se busc la solucin introduciendo una tercera capa central, situada entre el cliente y el servidor, para sostener gran parte del peso de esta nueva funcionalidad. Pese a sus evidentes ventajas, los sistemas en tres capas tardaron en generalizarse debido a que son mucho ms caros y difciles de desarrollar. La arquitectura cliente/servidor a dos capas sigue siendo til para la mayora de los casos y ahora aparece la tecnologa web para acercar la arquitectura a tres capas a las masas. La web. La tecnologa web cambi sustancialmente la forma en que las aplicaciones se desarrollan. Pero la web tiene muchas ms cosas que ofrecer que meramente la apariencia externa: Internet pronto conectar a la totalidad de computadores, lo que cambiar por completo las reglas del desarrollo de aplicaciones; las organizaciones que permanezcan aisladas no podrn beneficiarse de estas grandes ventajas: clientes -actuales y potenciales-, empleados y proveedores estarn continuamente conectados. La web populariz tambin un gran conjunto de tecnologas actuales y pasadas -HTML, TCP/IP, Java, etc. Los arquitectos tenemos ahora un mayor conjunto de herramientas para jugar.