Está en la página 1de 10

Serna, M. E. (2009). La ingeniera de sistemas y su evolucin hacia la arquitectura de sistemas.

Revista Digital Lmpsakos, No. 2, pp. 96-105.

LA INGENIERA DE SISTEMAS Y SU EVOLUCIN


HACIA LA ARQUITECTURA DE SISTEMAS

Edgar Serna Montoya


Grupo de investigacin SISCO. Funlam, Colombia.
gruposisco@gmail.com

(Artculo de TRADUCCIN) (Recibido el 3 de agosto. Aprobado el 10 de octubre de 2009)

RESUMEN
Muchas de las empresas modernas entendieron que sus antiguas unidades de sistemas ya no son
funcionales, y comienzan a subdividirlas en dos grupos de trabajo diferenciadores: el encargado
de la infraestructura y el de los denominados arquitectos de sistemas. Esta decisin lgica la
inspira la actual evolucin de la Ingeniera de Sistemas que, como rea de conocimiento, genera
los mismos subgrupos como agentes para formacin. Adems, la evolucin y complejidad de los
sistemas de informacin en medio de la sociedad del conocimiento, con exigencias y
expectativas muy complejas, tambin determinan la necesidad de esta especializacin. En este
documento, una traduccin casi literal de un white paper que public la empresa Quidnunc -
www.quidnunc.com consultado en abril del ao 2000- especializada en gestin de configuracin,
se detalla la importancia de esta divisin y las pautas a seguir a la hora de disear la
arquitectura de sistemas de una empresa.

Palabras clave: Arquitectura de sistemas, Ingeniera de sistemas, Arquitecto de sistemas,


infraestructura.

INTRODUCCIN sencilla -micro arquitectura- y la que existe


Entendemos por arquitectura en un proyecto entre y a travs de las distintas aplicaciones -
informtico a la disposicin conjunta y macro arquitectura-, por mucho, ms
ordenada de elementos del software y del compleja e importante.
hardware con el objetivo de cumplir una
determinada funcin. No es difcil DIVIDE Y VENCERS
comprender que al mezclar arquitecturas Cul es el papel de la arquitectura en una
distintas e inconsistentes sin ningn tipo de organizacin? Imaginemos una organizacin
orden o planificacin, el proyecto se puede que consta de cuatro capas: la capa superior,
convertir fcilmente en inmanejable, tanto o formada por las actividades propias de la
ms cuanto mayor sea el tamao del mismo. organizacin; debajo de stas, las
aplicaciones informticas que las soportan y
La mayora de las organizaciones facilitan; ms abajo de las aplicaciones, la
tradicionalmente favorecen -de forma arquitectura que facilita que se desarrollen y
planificada o no- unas configuraciones ejecuten; y en ltimo lugar, la
concretas. La arquitectura de cada empresa infraestructura del hardware o las redes
debera describir estas configuraciones, as fsicas. Esta subdivisin facilita determinar el
como el entorno que facilite la creacin de papel que desempea la arquitectura al
nuevas funcionalidades que encajen en ella: interior de una organizacin: cada capa acta
directivas, componentes de software como cliente de la capa inferior a ella y
reutilizables, herramientas, entre otras. Para como servidor de la capa superior. Los
facilitar que las nuevas funcionalidades arquitectos no deben malgastar su tiempo en
implementadas en la nueva arquitectura sean temas relacionados con la infraestructura,
consistentes con el sistema actual y sus como el sistema operativo; la mejor forma de
posibles modificaciones futuras, es necesario separar la arquitectura de la infraestructura
conocer dicha arquitectura, pero es mucho es pensar en el esquema de cuatro capas
ms importante conocer la arquitectura mencionado: la infraestructura debe de dar
operativa y organizacional de la empresa. soporte a la arquitectura, ya que mezclar
conceptos de una y otra capa es un error muy
Una distincin importante es la que existe comn en las organizaciones.
entre la arquitectura de una aplicacin
~ 96 ~
perfeccionarse y evolucionar en cada  Usan tecnologa orientada a componentes.
momento, sin seguir un plan maestro pero de La historia de la ingeniera de sistemas
acuerdo con una evolucin natural. Esta describe un viaje inexorable hacia la
evolucin posee dos elementos cruciales: un especializacin. Los componentes de hoy
mtodo para producir variantes -la son ms flexibles y es posible ya reutilizar
reproduccin- y un mtodo para elegir la el software que prometiera desde hace
mejor entre ellas -la supervivencia de los tiempo la programacin orientado por
ms fuertes. objetos.
 Juzgan la arquitectura del sistema desde
Los mtodos evolutivos tambin son el punto de vista del usuario.
populares en el desarrollo de software a  Invierten en infraestructura. Ahorrar
medida: las aplicaciones suelen construirse gastos en hardware o comunicaciones es a
mediante una serie de pasos consecutivos y menudo un falso ahorro: un efecto de los
no de una sola vez, lo que reduce das en que estas cosas eran caras.
considerablemente el riesgo de fallos y el Ahorrar dinero ahora traer otros gastos
costo de desarrollo. En este caso y dado que posteriores.
no existe variacin ni seleccin, el trmino  Reflejan la arquitectura de su
evolucin no se aplica adecuadamente, y organizacin en la arquitectura del
por el contrario el trmino ms adecuado sistema. Por ejemplo, organizaciones
sera desarrollo incremental. centralizadas necesitan un sistema
centralizado, mientras que organizaciones
Igual que en la evolucin natural, las descentralizadas se adaptan mejor a
variantes en el mundo de la informtica son sistemas distribuidos. Esto es una directiva
abundantes y slo los sistemas ms abiertos ms que una regla.
sobreviven. Es fundamental crear un entorno  A la hora de elegir entre distintas
que propicie la tecno-diversidad en la aplicaciones toman como principales
arquitectura del sistema, y una excepcin a criterios la facilidad de uso y el impacto
esta teora la constituyen, en s mismos, los en el negocio.
mainframes, que han resistido ms de lo que  Eliminan los proyectos fallidos o dbiles
se poda esperar, incluso luego de la rpidamente. Cada dlar invertido en un
epidemia del ao 2000. El problema es cmo proyecto dbil o fallido es un dinero
crear un entorno que facilite la tecno- malgastado dos veces: aprende la leccin,
diversidad, en el que las arquitecturas evita recriminaciones y corrige el
preestablecidas sobrevivan donde sea problema.
necesario, pero sin bloquear el paso a los  Valoran el capital intelectual. El principal
nuevos esquemas. activo de un departamento de
arquitectura de sistemas son las personas
Las organizaciones con arquitecturas y los procedimientos que conocen o
evolutivas poseen ciertos rasgos en comn: desarrollan. Es preciso cuidar
 Prefieren las directivas a los estndares. apropiadamente esos aportes.
Los estndares reales son minimistas y  Evitan innovaciones.
usualmente de hecho como Windows;
las directivas pueden obviarse si existe Estos puntos no pretenden ser una lnea de
una razn lo suficientemente buena. La actuacin para beneficiar una arquitectura
mayora de las organizaciones mantienen evolutiva, son una lista de observaciones
demasiados de ellos, motivados por la procedente de organizaciones que manejan
reduccin de costos -por ejemplo, arquitecturas con estas caractersticas.
mantienen UNIX en el back-end para
minimizar el costo de reeducacin-, pero LA REVOLUCIN DE LOS COMPONENTES
fallan al ignorar el costo que supone Dos dcadas despus de comenzar a recorrer
forzar a determinadas aplicaciones que el camino, por fin se tiene la tecnologa
requieren en realidad tomar una lnea suficiente para crear y ensamblar
diferente. La flexibilidad es una necesidad componentes que otras ramas de la
fundamental en la arquitectura de los ingeniera disfrutan desde hace mucho
sistemas modernos. tiempo. Hasta hace poco la industria del
software atravesaba una grave crisis: las
~ 98 ~

empresas demandaban desarrollos cada vez como ampliaciones de la aplicacin original,
ms y ms complejos, en plazos de tiempo mientras que en las verdaderas aplicaciones
cada vez ms ajustados, y a precios ms basadas en componentes, stos constituyen
competitivos. La actividad de desarrollar casi la totalidad de la aplicacin.
software es ya de por si lo suficientemente
lenta y frustrante como para tener que Las tecnologas recientes van ms all:
aguantar esto. En la historia se encuentran Actives, Java Beans, componentes de-
otros sectores de la industria que atravesaron sarrollados con herramientas que cumplen las
por estos problemas: el ejemplo ms claro lo especificaciones CORBA, SAP, etc. Estas
representa la industria automovilstica. tecnologas potencian los dos principales
Actualmente el trabajo en las plantas donde beneficios de la tecnologa de componentes:
se construyen los autos se limita al ensamblar  La divisin en componentes reduce la
componentes; estos componentes se complejidad, permite la reutilizacin y
suministran listos para que los proveedores, acelera el proceso de ensamblaje de
especializados en la fabricacin de los software.
mismos, realicen un montaje para el que,  Los creadores de componentes pueden
posiblemente, no tengan idea de los especializarse creando objetos cada vez
conocimientos necesarios para hacer ms complejos y de mayor calidad.
componentes distintos. La tecnologa de  La interoperabilidad entre componentes
componentes va de la mano de la de distintos fabricantes aumenta la
especializacin. competencia, reduce los costos y facilita
la construccin de estndares. El software
Pero la especializacin no fue inventada por se hace cada vez ms rpido, de mejor
la industria del automvil, la naturaleza la calidad y a menor costo.
usa desde hace millones de aos. Los seres  La principal implicacin para la industria
vivos se constituyen de rganos, y cada uno del software es que se dividir en dos:
es un conjunto de clulas altamente fabricantes y ensambladores de
especializadas. La ventaja de este esquema componentes.
es cada uno de ellos puede desenvolverse sin
interferencia de los otros. Volviendo al EL SECRETO ES... EL EMPAQUETADO
ejemplo de la planta de ensamble de Si los componentes existen desde principios
automviles, las interfaces y especificaciones de los aos 90 por qu ahora suponen una
de todos sus componentes se acuerdan de revolucin? Porque los beneficios son
antemano para que no haya sorpresas alcanzables slo ahora, cuando la tecnologas
durante el proceso. Estas interfaces entre para empaquetarlos alcanza la suficiente
componentes se definen de la forma ms madurez. Actives y Java Beans son buenos
simple posible para acelerar el tiempo de ejemplos: ambos proporcionan los
montaje. En cualquier caso, en la industria contenedores donde depositar el cdigo, de
del software se tienen otras peculiaridades: forma que pueden ser manejados sin
la replicacin masiva nunca ha sido importar el lenguaje en el que estn escritos.
problema, el principal objetivo es la
personalizacin masiva: disponer de una El empaquetado del cdigo tard tanto en
amplia variedad de productos basados en un desarrollarse debido a que va en contra de la
esqueleto comn. norma de la mayora de los programadores
quienes persiguen la eficiencia del cdigo por
LA LEY DE MOORE EN EL SOFTWARE encima de la eficiencia en el desarrollo. En
En esencia, un componente de software es los principios de la informtica las mquinas
una pieza que realiza funciones bien eran caras y los programadores baratos, de
definidas y posee una interfaz bien definida. forma que eran programados para
Claros ejemplos de los primeros componentes conseguir los mejores rendimientos con sus
son por ejemplo los VBX, introducidos por desarrollos, y la idea de colocar capas de
Visual Basic, o los plug-ins, de Photoshop. cdigo innecesario, con el nico propsito de
Fueron pasos importantes, pero an tenan facilitar el desarrollo de aplicaciones,
dos defectos importantes por superar: slo pareca impensable.
servan para un producto especfico y, por
tanto, de valor limitado, y se concibieron
~ 99 ~

Hoy, por el contrario, las mquinas son enviando y recibiendo eventos, y
baratas y la gente que sabe trabajar con ellas comunicndose con otros componentes y
muy cara. Entonces aparecieron las tcnicas el resto de la aplicacin a travs de la
orientadas por objetos: colocar datos y red.
funciones juntas para formar objetos, fue un  Introspeccin. Una forma de aislar el
gran paso sin el que ninguna de las componente del mundo exterior, lo que
tecnologas de empaquetado de componentes permite centrarse solamente en lo que
actuales hubiera prosperado. La orientacin hace y cmo lo hace.
por objetos es el mayor paradigma que jams  Distribucin. Los componentes pueden
existi en el mundo de la informtica. No transmitirse a travs de una red.
obstante, los primeros intentos de
empaquetado de cdigo fueron un fracaso: La explosin de la tecnologa de
los desarrolladores no podan creer que el componentes fue lenta, en parte debido al
envoltorio fuese ms complejo que el cdigo sentimiento de insatisfaccin que la
que contena. Actualmente, el empaquetado orientacin por objetos dej en sus inicios:
de cdigo sigue siendo complejo y arrastra las promesas de facilidad en la reutilizacin
considerables problemas: aumenta de cdigo nunca fueron cumplidas, hasta
considerablemente el tamao de los pro- ahora.
gramas, empeora el rendimiento de stos y
hace consumir ms recursos en las mquinas CREAR LA ARQUITECTURA DE UNA EMPRESA
donde se ejecutan. Exactamente los mismos Disear la arquitectura de sistemas de una
problemas que se les atribuyen a las GUI y a gran organizacin es una tarea que puede
pesar de ello prcticamente todo el mundo resultar intimidatoria a mucha gente; son
usa alguna. tres los requisitos para empezar: un
departamento de arquitectura, la redaccin
A pesar de estos problemas las ventajas de un anteproyecto de diseo de la
superaron a los inconvenientes y, aunque las arquitectura y un documento que recoja los
tecnologas de empaquetado de cdigo valores que impulsar. Es fcil de olvidar,
siguen siendo muy complejas de construir, dado el alcance actual, que el uso de la
alcanzaron un alto grado de facilidad de uso, informtica en las organizaciones es un
de forma que los desarrolladores dedicados a fenmeno relativamente reciente. No es de
la fabricacin de componentes slo tienen extraar que las estructuras y procesos, para
que ocuparse de desarrollar cada vez obtener un valor real de esta inversin,
mejores componentes, sin preocuparse de hayan retrasado la inversin en s misma, y el
nada ms. resultado fue un gigantesco enredo.

A pesar de que hoy existen diversas tcnicas La tnica aplicada hasta el momento por la
de empaquetado de componentes, con mayora de las empresas es buscar la
grandes diferencias segn de donde robustez de los estndares, a travs de
procedan, tambin tienen importantes compra de tecnologa a un nico fabricante o
similitudes: exigiendo el desarrollo de aplicaciones que
 Transparencia en cuanto a la localizacin, funcionen sobre una rgida arquitectura. Lo
lo que permite usar un componente sin la primero es crear la direccin de
preocupacin de dnde se encuentra arquitectura, que coordine y se asegure de
fsicamente, incluso si ste se cambia de que la arquitectura del sistema facilita a las
sitio. aplicaciones existentes -y futuras- la
 Definicin de la interfaz. Especifican la consecucin de los objetivos de la empresa.
interfaz que el componente proporciona Las tareas del departamento de arquitectura
de forma independiente al lenguaje de implican: amplia visin de la actividad de la
programacin o del sistema operativo organizacin, estar al da de los ms
donde se usar. Normalmente se inspiran relevantes progresos tecnolgicos y
en la sintaxis usada por las DLL, muy asegurarse de que los equipos que trabajan
similar a la usada en las llamadas a fun- en el desarrollo de aplicaciones cumplen las
ciones en C++. directivas oportunas. El jefe del
 Invocacin. Soporte para cargar y ejecutar departamento de arquitectura debe jugar
los componentes cuando sean necesarios, entre el punto de vista del empresario y el
~ 100 ~

del tcnico; debe ser pragmtico antes que anteproyecto del sistema que se desea tener,
idealista; evangelista antes que dictador; y de forma que se pueda trazar un camino para
debe, por supuesto, ser de la absoluta llegar hasta l. Cualquier nuevo diseo debe
confianza del director de sistemas de la responder a dos preguntas: de qu servicios
organizacin. existentes se puede hacer uso y a qu nuevo
servicio se puede contribuir. Esto supone no
Para comprender donde no se debe de meter volver a pensar en aplicaciones aisladas, para
el departamento de arquitectura, volvamos comenzar a pensar en trminos de compartir
al modelo de cuatro capas de la servicios de aplicaciones.
organizacin: los desarrolladores son sus
clientes y los responsables de la El ltimo punto es crear un documento con
infraestructura sus proveedores. Los ar- los valores de la arquitectura. Debe ser un
quitectos de sistemas que pasan demasiado documento breve, de menos de 1000
tiempo eligiendo sistemas operativos o palabras, distribuido a todo el personal de
rediseando las lneas de negocio de su sistemas de la empresa. Debe cubrir puntos
organizacin, no invierten el tiempo como: definir cuando se deben usar dos
necesario en su trabajo. capas y cuando tres; qu middleware se
usar y que estndares -sistemas operativos,
De cualquier modo, la lnea de divisin entre de mensajera, etc.- no estn abiertos a
infraestructura y arquitectura puede ser muy debate; ser un documento deliberadamente
difcil de ver: muchos de los elementos que minimalista, permitiendo libertad a la gente
en un momento dado forman parte de la con creatividad para elegir cul es la mejor
arquitectura, posteriormente se consideran solucin para resolver su problema
parte de la infraestructura, como ocurre con particular.
las redes locales y ocurrir con los sistemas
de mensajera. En cualquier caso, es Es necesario concentrarse en tres ventajas
responsabilidad del jefe de arquitectura fundamentales que este documento debe
promover este tipo de progresos, porque aportar: 1) elimina los debates estriles al
como es lgico, con una dbil infraestructura sealar claramente qu puntos no estn
no es posible edificar una slida abiertos a debate, de forma que el personal
arquitectura. se centre en debatir los problemas reales; 2)
ayuda a identificar al personal que cumple
Una importante clave en el enfoque moderno los mejores requisitos para trabajar con la
de la informtica es ver las aplicaciones arquitectura, de forma que se puede utilizar
como una coleccin de servicios. Estos este documento como criterio de seleccin
servicios deberan ser, hasta donde sea de los nuevos tcnicos; y 3) le proporciona a
posible, independientes unos de otros, de los tcnicos la posibilidad de enfocar sus
forma que se puedan sustituir, eliminar o esfuerzos y su creatividad en campos en los
aadir nuevas funcionalidades sin demasiado que realmente sern apreciados.
esfuerzo. Separar de esta forma los servicios
proporciona el valor aadido de poder elegir A continuacin se muestra un ejemplo muy
la mejor tecnologa para cada uno de ellos: simple a partir del cual se podra empezar a
los datos de los clientes en una base de datos trabajar:
relacional, los de los empleados en un Este documento, que muestra nuestra posicin
directorio que cumpla las especificaciones frente a los ms relevantes puntos de la
LDAP y las descripciones de los productos en arquitectura de sistemas de esta empresa, fue
un servidor web. redactado por [el jefe de arquitectura] y
ratificado por [el director de sistemas]. Fue
revisado por ltima vez en [fecha] y, si ha
El problema en este idlico paisaje es que la transcurrido ms de un ao, probablemente
mayora de los servicios con las que ya tienes en tus manos una versin obsoleta.
cuenta la organizacin no estn
correctamente empaquetados y con sus Este documento se redact con la idea de
interfaces bien definidas, sino que se facilitar el trabajo a todo el personal de sistemas
encuentran sepultados bajo aplicaciones de [nombre de la organizacin] y no para
existentes, en paquetes cerrados de sistemas censurarlo ni limitarlo. Si tienes una razn lo
propietarios. Por esto es necesario un suficientemente fuerte como para contravenir
~ 101 ~

alguno de los puntos aqu indicados, documntala servicios de aplicaciones, deberan ser
y hazla llegar. rechazados.
9. Esperamos que la comunicacin entre
1. Nunca olvides que la actividad de nuestra aplicaciones se realice mediante RPC y
empresa est encaminada a [actividad de la productos de mensajera.
empresa] y que en el departamento de 10. Toma como inamovible la actual
sistemas nuestra principal prioridad es infraestructura. En ella incluimos Windows 7
desarrollar sistemas que soporten esa lnea de y Office 2007. No desarrolles nada sobre
negocios. Dejemos a otros la innovacin en la entornos de 32 bits. Utiliza siempre entornos
tecnologa para que nosotros innovemos en de 64 bits.
cmo aplicar esa tecnologa en una aplicacin 11. Considera la inversin en personal
real. especfico cuando investigues nuevas
2. Debemos maximizar el valor de nuestro herramientas. Para la mayora de las
trabajo desarrollando servicios para herramientas, esta inversin excede
aplicaciones en lugar de aplicaciones aisladas, cualquier otra diferencia tcnica de las
permitindonos reutilizar en el futuro esos mismas. Esto significa que tenemos una serie
servicios para crear nuevas aplicaciones rpida de preferencias: Oracle para bases de datos
y fcilmente. Nuestro anteproyecto de relacionales, SQL va ODBC para el acceso a
servicio de aplicaciones define los servicios los datos, Microsoft Windows Server como
que necesitamos y si existen o no en este servidores, C++ o Java como herramientas de
momento. Cuando disees nueva aplicaciones desarrollo de tercera generacin y .NET
te pedimos que uses todos los servicios como herramienta de cuarta generacin.
existentes que necesites y consideres a qu 12. Evita reemplazar aplicaciones actuales a
nuevos servicios puede contribuir tu menos que sea totalmente Indispensable.
aplicacin.
3. En el nivel ms bajo pensamos que todas las LA ARQUITECTURA MODERNA
aplicaciones deben de estar ensambladas por Publicar un conjunto de valores para una
componentes software. La tecnologa que uses arquitectura requiere que estar bien
para ello no es tan importante, pero a menos informados. El punto de vista de un jefe de
que tengas una buena razn para no hacerlo arquitectura debe contemplar los siguientes
preferimos que uses [tecnologa de
puntos:
componentes preferida, por ejemplo ActiveX]
porque [motivos para preferirla, por ejemplo,  Estndares. El desarrollo de Internet y
parece que dominar el mercado durante todas las tecnologas que van con ella est
algunos aos]. revolucionando el mundo de la
4. Deseamos que las herramientas y tecnologas informtica. Algunos de sus efectos son
basadas en Web sean estndares en rpidamente visibles, pero otros no lo son
nuestra empresa de aqu a dos aos. Considera tanto. El jefe de arquitectura debe de
esto y realiza una aproximacin siempre que estar bien informado de los estndares
sea posible. emergentes. En algunos casos aparecen
5. Usa tres capas para todas las aplicaciones no problemas serios a la hora de tomar
triviales -por ejemplo, las entradas simples de
partido por dos estndares que,
datos podran ir sobre dos capas. Esto facilita
el mantenimiento y la reutilizacin del cdigo aparentemente, poseen la misma
y mejora el rendimiento de las aplicaciones. funcionalidad; por ejemplo DCOM y
6. Para aplicaciones basadas en objetos CORBA. La decisin debe tomarse
distribuidos, preferimos [nombre de la recopilando informacin claramente
tecnologa, por ejemplo CORBA]. Valoramos el imparcial y, si no es posible o no es lo
tiempo de desarrollo por encima del purismo. suficientemente aclaratoria, deben
7. Excepto para algunos informes especiales, no probarse. Lo peor que se puede hacer es
necesitamos recoger datos de ningn tipo. no usar ninguno de los dos.
Existe una estrategia especial de Data
Warehouse que se encarga de ello.
8. Si puedes encontrar un paquete desarrollado  La capa intermedia. Ya se vio que uno de
que realice el 80% de la funcionalidad que los grandes progresos de la arquitectura
buscamos salo, en otro caso considera un moderna es la subdivisin del software. El
desarrollo a medida: la excesiva perso- pegamento que une estas partes para
nalizacin de un paquete conlleva demasiados formar una aplicacin completa, es lo que
riesgos. Los paquetes que no son lo se conoce como middleware. Por ejemplo,
suficientemente abiertos para jugar su papel dos programas A y B corriendo
de colaboracin en nuestro anteproyecto de separadamente cada uno en una mquina:
~ 102 ~

A llama a B con un problema; B trabaja en entonces a enriquecer sus productos con
la resolucin del mismo y cuando acaba nuevas funcionalidades a sus productos,
devuelve la respuesta a A. El middleware gracias a las mejores herramientas de
es el que permite esta funcionalidad, pero desarrollo existentes para los PC. Los
existen algunos problemas derivados de clientes engordaron hacindose ms
esta forma de actuacin qu debera pesados y lentos. La alternativa, meter
hacer el proceso A mientras que B trabaja parte de esta nueva funcionalidad en el
en la resolucin de su problema? esperar? backend no era demasiado atractiva, as
Cmo puede B comunicarle a A algo a que se busc la solucin introduciendo una
menos que ste lo requiera? Cmo puede tercera capa central, situada entre el
B saber dnde se encuentra A? Qu hace cliente y el servidor, para sostener gran
A si B se cae? Si B es reemplazado? Si parte del peso de esta nueva
cientos de As requieren una respuesta de funcionalidad.
una nica instancia de B? Como vemos, los
middlewares deben resolver complejas Pese a sus evidentes ventajas, los
situaciones pero sin aadir excesiva sistemas en tres capas tardaron en
complejidad a la arquitectura. generalizarse debido a que son mucho
ms caros y difciles de desarrollar. La
Existen dos tipos esenciales de arquitectura cliente/servidor a dos capas
middlewares: los basados en Remote sigue siendo til para la mayora de los
Procedure Calls RPC y los basados en casos y ahora aparece la tecnologa web
Message Oriented Middleware MOM. para acercar la arquitectura a tres capas
Middlewares basados en MOM son a las masas.
inherentemente asncronos y lo ms difcil
en ellos es definir correctamente la  La web. La tecnologa web cambi
estructura de los mensajes. Los sustancialmente la forma en que las
middlewares basados en RPC son ms aplicaciones se desarrollan. Pero la web
sencillos de usar, puesto que la sintaxis de tiene muchas ms cosas que ofrecer que
las llamadas es prcticamente idntica a meramente la apariencia externa: Internet
la de una llamada en C, pero el pronto conectar a la totalidad de
rendimiento de estos sistemas suele ser computadores, lo que cambiar por
ms pobre. Existen algunos fabricantes completo las reglas del desarrollo de
que distribuyen productos capaces de aplicaciones; las organizaciones que
funcionar en uno u otro modo. La mejores permanezcan aisladas no podrn
herramientas de hoy estn basadas en beneficiarse de estas grandes ventajas:
CORBA, estn orientadas a mensajes y clientes -actuales y potenciales-,
tienen como inconveniente que son ms empleados y proveedores estarn
difciles de usar por los programadores. continuamente conectados. La web
Las herramientas de Microsoft basadas en populariz tambin un gran conjunto de
COM+ son ms limitadas pero muy tecnologas actuales y pasadas -HTML,
sencillas de usar y son recomendables si TCP/IP, Java, etc. Los arquitectos
anteponemos esta caracterstica a la tenemos ahora un mayor conjunto de
longevidad y la calidad del producto. herramientas para jugar.

 Estructura cliente/servidor a dos o tres Veamos un caso tpico: una herramienta


capas. La estructura cliente/servidor a dos cliente podra consistir simplemente en
capas naci el da en que alguien conecto una amistosa interfaz HTML utilizable
su PC a una mquina UNIX. A los usuarios mediante un navegador. Este cliente se
les gusta la facilidad de uso de los PC y a conecta a travs de un servidor web con
los administradores la seguridad que les una capa intermedia formada por com-
reporta un servidor UNIX. Nadie lo llam ponentes escritos en diversos lenguajes -
entonces arquitectura a dos capas porque C++, Visual Basic y Java- y empaquetados
no exista ninguna otra. La novedad de con Actives o Java Beans. Todo ello se
contar con una interfaz grfica en lugar de sustenta sobre un servidor de
una pantalla verde en modo texto fue bien transacciones -como Microsoft MTS o TP
recibida. Los desarrolladores comenzaron Tuxedo- y se conecta a una tercera capa
~ 103 ~

de aplicaciones propietarias -mediante arquitectura bien diseada puede ser muy
Microsoft MQ o IBM MQSeries- y con un beneficioso. La forma de conseguirlo es
servidor de bases de datos va ODBC. Todo envolverlo con una interfaz que lo haga
ello permanece unido mediante un comportarse como uno de los paquetes
lenguaje basado en scripts como Java existentes. A pesar de usar tecnologas
Scripts o Visual Basic Scripts. obsoletas, los sistemas propietarios suelen
Arquitecturas como sta popularizan por usar dos capas bien definidas:
primera vez en la historia de la informti- presentacin lgica y almacenamiento de
ca los beneficios de los lenguajes de datos. La mejor forma de envolverla es
componentes y la estructura a tres capas. acceder directamente a la lgica de la
aplicacin. Para ello la aplicacin debe de
 Empaquetado. Utilizar tecnologa de proporcionarnos un API. Si esto no es
componentes empaquetados puede posible, la segunda opcin sera acceder
ahorrar aos de desarrollo. Se ahorran en directamente a los datos almacenados.
costos de desarrollo y mantenimiento y se Esto supone un perfecto conocimiento de
logran beneficios como la robustez que la estructura de almacenamiento de la
proporcionan los componentes que son aplicacin y, a menudo, tener que
testeados por cientos de usuarios. Los solventar problemas de sincronizacin y
problemas comienzan con la gestin de bloqueos. La ltima lnea de
personalizacin. Habitualmente los ataque sera atacar el nivel de
paquetes de software no cumplen presentacin. El envoltorio se comunica
exactamente el 100% de los requisitos, y con la aplicacin igual que lo hara un
la arquitectura puede adaptarse a ellos o, usuario. Tecleando datos y recogiendo
lo que parece ms lgico, adaptarlos a respuestas de la salida por defecto por
ella. Por regla general, si se encuentra un medio de una interfaz de terminal. Las
paquete que cumple el 80% de los tres tcnicas son caras y difciles, pero
requisitos, se debe comprar y seguramente usar la aplicacin ser
personalizar; si los requisitos que cumple mucho mejor que desecharla o desarrollar
estn por debajo de este porcentaje, es otra similar.
mucho mejor desarrollar el sistema. Las
personalizaciones complejas pueden ser CONCLUSIONES
caras y, a menudo, inviables. Como puede abstraerse del anterior artculo,
la especializacin de la labor de los
Donde mejor se comportan los paquetes es Ingenieros de Sistemas es cada vez ms
en los procesos que son prcticamente necesaria. Las funciones que antes se
iguales en multitud de empresas, como la consideraban simples o de rutina, hoy se
facturacin, o cuando lo que se quiere es convierten en complejas ingenieras de
personalizar el contenido y no la intervencin, lo que exige a los profesionales
funcionalidad, como en sistemas de datos de la informtica la adquisicin de
de gestin documental. A veces ocurre conocimientos que la educacin de un
que se desea sustituir un paquete, pero pregrado no le brinda.
parte de su funcionalidad es indispensable
para otros elementos: el paquete se De acuerdo con esta visin es necesario
convierte en parte de la arquitectura. dividir la formacin en Ingeniera de
Para evitar estos indeseables efectos, se Sistemas, ciencias computacionales,
deben envolver los paquetes y realizar la Ingeniera Informtica o como se llame en
integracin contra este envoltorio. Esto cada pas, en dos reas claramente
encarece el costo de desarrollo pero, a la establecidas por las exigencias de los
larga, mejora la flexibilidad de nuestro actuales Sistemas de Informacin:
sistema. Arquitectos de Sistemas e Ingenieros de
Software. Los primeros se encargan de
 Envolviendo sistemas propietarios. Muchos disear, construir y mantener la arquitectura
sistemas propietarios proporcionan sobre la que se soportar el core del negocio
funcionalidades muy valiosas en y el manejo de la informacin que circula en
determinadas misiones crticas. Son fruto todos los procesos de la empresa, y los
de aos de experiencia y su uso en una segundos se especializan en disear,
~ 104 ~

desarrollar y mantener los programas que con tener micro-conocimientos de una
transitan sobre la arquitectura y convierten cantidad de conceptos y materias a lo largo
los datos en informacin para la toma de de ciclos de formacin, hoy es necesaria la
decisiones y el soporte de la empresa. especializacin en alguna de las mencionadas
reas, y la decisin debe tomarse con la
Es el momento preciso para que se actualicen misma prontitud y estructuracin con la que
los programas de formacin de ingenieros en los desarrollos tecnolgicos se producen.
el rea de los sistemas, ya no es suficiente

~ 105 ~