Cet ouvrage et des milliers d'autres font partie de la bibliothèque YouScribe
Obtenez un accès à la bibliothèque pour les lire en ligne
En savoir plus

Partagez cette publication

Serna, M. E. (2009). La ingeniería de sistemas y su evolución hacia la arquitectura de sistemas.
Revista Digital Lámpsakos, No. 2, pp. 96-105.
LA INGENIERÍA DE SISTEMAS Y SU EVOLUCIÓN
HACIA LA ARQUITECTURA DE SISTEMAS

Edgar Serna Montoya
Grupo de investigación SISCO. Funlam, Colombia.
gruposisco@gmail.com

(Artículo de TRADUCCIÓN) (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 decisión lógica la
inspira la actual evolución de la Ingeniería de Sistemas que, como área de conocimiento, genera
los mismos subgrupos como agentes para formación. Además, la evolución y complejidad de los
sistemas de información en medio de la sociedad del conocimiento, con exigencias y
expectativas muy complejas, también determinan la necesidad de esta especialización. En este
documento, una traducción casi literal de un white paper que publicó la empresa Quidnunc -
www.quidnunc.com consultado en abril del año 2000- especializada en gestión de configuración,
se detalla la importancia de esta división y las pautas a seguir a la hora de diseñar la
arquitectura de sistemas de una empresa.

Palabras clave: Arquitectura de sistemas, Ingeniería de sistemas, Arquitecto de sistemas,
infraestructura.

INTRODUCCIÓN sencilla -micro arquitectura- y la que existe
entre y a través de las distintas aplicaciones -Entendemos por arquitectura en un proyecto
informático a la disposición conjunta y macro arquitectura-, por mucho, más
ordenada de elementos del software y del compleja e importante.
hardware con el objetivo de cumplir una
determinada función. No es difícil DIVIDE Y VENCERÁS
comprender que al mezclar arquitecturas ¿Cuál es el papel de la arquitectura en una
distintas e inconsistentes sin ningún tipo de organización? Imaginemos una organización
orden o planificación, el proyecto se puede que consta de cuatro capas: la capa superior,
convertir fácilmente en inmanejable, tanto o formada por las actividades propias de la
más cuanto mayor sea el tamaño del mismo. organización; debajo de éstas, las
aplicaciones informáticas que las soportan y
facilitan; más abajo de las aplicaciones, la La mayoría de las organizaciones
arquitectura que facilita que se desarrollen y tradicionalmente favorecen -de forma
ejecuten; y en último lugar, la planificada o no- unas configuraciones
infraestructura del hardware o las redes concretas. La arquitectura de cada empresa
físicas. Esta subdivisión facilita determinar el debería describir estas configuraciones, así
papel que desempeña la arquitectura al como el entorno que facilite la creación de
interior de una organización: cada capa actúa nuevas funcionalidades que encajen en ella:
como cliente de la capa inferior a ella y directivas, componentes de software
como servidor de la capa superior. Los reutilizables, herramientas, entre otras. Para
arquitectos no deben malgastar su tiempo en facilitar que las nuevas funcionalidades
temas relacionados con la infraestructura, implementadas en la nueva arquitectura sean
como el sistema operativo; la mejor forma de consistentes con el sistema actual y sus
separar la arquitectura de la infraestructura posibles modificaciones futuras, es necesario
es pensar en el esquema de cuatro capas conocer dicha arquitectura, pero es mucho
mencionado: la infraestructura debe de dar más importante conocer la arquitectura
soporte a la arquitectura, ya que mezclar operativa y organizacional de la empresa.
conceptos de una y otra capa es un error muy
común en las organizaciones. Una distinción importante es la que existe
entre la arquitectura de una aplicación
~ 96 ~
Un error en el que no debe de caer un planificación para completarla dentro de
arquitecto de sistemas es en ser demasiado unos plazos determinados. La principal
preceptivo: introducir demasiadas normas ventaja de este enfoque es que la hace
que creen en excesiva rigidez, generará pro- comprensible a los ejecutivos, pues es similar
blemas en el desarrollo de aplicaciones. Un a la forma en que tienen que dirigir sus
buen arquitecto de sistemas debe tener negocios. El principal inconveniente es que
siempre en mente que su finalidad principal no funciona, ya que comienza por la
es permitir la creación de aplicaciones, a la definición de una arquitectura objetivo y
vez que facilitar la creatividad y la esto es un error. El único objetivo que debe
innovación de los creadores de las mismas. tener en mente el arquitecto de sistemas es
el de la organización para la que trabaja, si
no tarde o temprano entrará en conflicto con La arquitectura de sistemas en los tiempos en
él. La arquitectura del sistema debe de ser lo los que sólo existían los grandes
suficientemente flexible como para computadores era muy sencilla: existía un
adaptarse a los cambios de objetivos lugar para cada cosa y cada cosa tenía su
organizacionales, esta es la clave principal lugar adecuado. Con el paso de los años, y
para asegurar su longevidad. siempre en busca de una mayor flexibilidad,
se introdujeron estructuras cada vez más
complejas: arquitectura cliente/servidor, La segunda clave a tener en cuenta es la que
arquitectura a tres capas, message brokers, proporciona la mejor forma de medir la
data warehouses, objetos distribuidos, ar- bondad de una arquitectura: la forma en que
quitectura web... Un buen arquitecto debe sustenta las aplicaciones que a la vez
empezar recordando que su trabajo es hacer sustentan la organización. La mejor forma de
la vida más fácil a los desarrolladores, y no al verlo es estudiar, dada una nueva
funrevés. cionalidad necesaria para la empresa, cómo
la arquitectura del sistema facilita su
Existe otra idea que subyace tras todos los desarrollo e integración con el resto de las
enfoques: especialización. Dividir los aplicaciones.
problemas en sus partes constituyentes y
resolverlas separadamente con equipos de Los elementos claves que debe cumplir la
especialistas centrados en una sola área. La arquitectura, para facilitar el desarrollo de
especialización deja dos interrogantes sin nuevas aplicaciones, son: tener directivas
respuesta: cómo dividir los sistemas para que claramente definidas, no rígidas ni
puedan ser definidos separadamente y cómo dictatoriales en cuanto al uso de
unirlos posteriormente para formar un todo determinadas tecnologías o fabricantes;
homogéneo. Estos son los principales retos de favorecer el uso de aplicaciones que posean
la moderna arquitectura de sistemas. una funcionalidad base y sean
personalizables por el usuario; y facilitar el
ARQUITECTURA EVOLUTIVA uso y desarrollo de componentes y plug-ins y
Y, desde el punto de vista de la empresa, aplicaciones que los admitan. Este enfoque
¿qué características debería reunir la permite, en la mayoría de los casos,
arquitectura de sistemas? Si mejorar los encontrar la forma más rápida y sencilla de
procesos y las aplicaciones genera un mejor desarrollar una nueva funcionalidad para el
rendimiento de la empresa, y si para mejorar sistema, en los casos en los que lo más
las aplicaciones necesitamos mejorar los importante es tener una aplicación que haga
sistemas, entonces la arquitectura de lo que queremos y no tener la mejor
sistemas debe ser el vehículo de desarrollo aplicación que haga lo que no queremos.
para ambos. En la práctica, la arquitectura Actualmente, en la práctica, esta es la
de los sistemas actuales constituye, en solución que se necesita en la mayoría de los
muchos casos, grandes obstáculos para los casos, y son los principios del enfoque
dos. conocido como evolutivo.

A principios de los 90 la arquitectura de El modelo evolutivo al que la arquitectura
sistemas no iba más allá de simple del sistema se adapta paso a paso surge del
planificación: se define una arquitectura concepto de dependencia, en el que cada
objetivo y se idea una estrategia y una uno de ellos se basa en los anteriores para
~ 97 ~
perfeccionarse y evolucionar en cada Usan tecnología orientada a componentes.
momento, sin seguir un plan maestro pero de La historia de la ingeniería de sistemas
acuerdo con una “evolución natural”. Esta describe un viaje inexorable hacia la
evolución posee dos elementos cruciales: un especialización. Los componentes de hoy
método para producir variantes -la son más flexibles y es posible ya reutilizar
reproducción- y un método para elegir la el software que prometiera desde hace
mejor entre ellas -la supervivencia de los tiempo la programación orientado por
más fuertes. objetos.
Juzgan la arquitectura del sistema desde
el punto de vista del usuario. Los métodos evolutivos también son
Invierten en infraestructura. Ahorrar populares en el desarrollo de software a
gastos en hardware o comunicaciones es a medida: las aplicaciones suelen construirse
menudo un falso ahorro: un efecto de los mediante una serie de pasos consecutivos y
días en que estas cosas eran caras. no de una sola vez, lo que reduce
Ahorrar dinero ahora traerá otros gastos considerablemente el riesgo de fallos y el
posteriores. costo de desarrollo. En este caso y dado que
Reflejan la arquitectura de su no existe variación ni selección, el término
organización en la arquitectura del “evolución” no se aplica adecuadamente, y
sistema. Por ejemplo, organizaciones por el contrario el término más adecuado
centralizadas necesitan un sistema sería “desarrollo incremental”.
centralizado, mientras que organizaciones
descentralizadas se adaptan mejor a Igual que en la evolución natural, las
sistemas distribuidos. Esto es una directiva variantes en el mundo de la informática son
más que una regla. abundantes y sólo los sistemas más abiertos
A la hora de elegir entre distintas sobreviven. Es fundamental crear un entorno
aplicaciones toman como principales que propicie la tecno-diversidad en la
criterios la facilidad de uso y el impacto arquitectura del sistema, y una excepción a
en el negocio. esta teoría la constituyen, en sí mismos, los
Eliminan los proyectos fallidos o débiles mainframes, que han resistido más de lo que
rápidamente. Cada dólar invertido en un se podía esperar, incluso luego de la
proyecto débil o fallido es un dinero epidemia del año 2000. El problema es cómo
malgastado dos veces: aprende la lección, crear un entorno que facilite la
tecnoevita recriminaciones y corrige el diversidad, en el que las arquitecturas
problema. preestablecidas sobrevivan donde sea
Valoran el capital intelectual. El principal necesario, pero sin bloquear el paso a los
activo de un departamento de nuevos esquemas.
arquitectura de sistemas son las personas
y los procedimientos que conocen o Las organizaciones con arquitecturas
desarrollan. Es preciso cuidar evolutivas poseen ciertos rasgos en común:
apropiadamente esos aportes. Prefieren las directivas a los estándares.
Evitan innovaciones. Los estándares reales son minimistas y
usualmente “de hecho” como Windows;
Estos puntos no pretenden ser una línea de las directivas pueden obviarse si existe
actuación para beneficiar una arquitectura una razón lo suficientemente buena. La
evolutiva, son una lista de observaciones mayoría de las organizaciones mantienen
procedente de organizaciones que manejan demasiados de ellos, motivados por la
arquitecturas con estas características. reducción de costos -por ejemplo,
mantienen UNIX en el back-end para
LA REVOLUCIÓN DE LOS COMPONENTES minimizar el costo de reeducación-, pero
Dos décadas después de comenzar a recorrer fallan al ignorar el costo que supone
el camino, por fin se tiene la tecnología forzar a determinadas aplicaciones que
suficiente para crear y ensamblar requieren en realidad tomar una línea
componentes que otras ramas de la diferente. La flexibilidad es una necesidad
ingeniería disfrutan desde hace mucho fundamental en la arquitectura de los
tiempo. Hasta hace poco la industria del sistemas modernos.
software atravesaba una grave crisis: las
~ 98 ~
empresas demandaban desarrollos cada vez como ampliaciones de la aplicación original,
más y más complejos, en plazos de tiempo mientras que en las verdaderas aplicaciones
cada vez más ajustados, y a precios más basadas en componentes, éstos constituyen
competitivos. La actividad de desarrollar casi la totalidad de la aplicación.
software es ya de por si lo suficientemente
lenta y frustrante como para tener que Las tecnologías recientes van más allá:
aguantar esto. En la historia se encuentran Actives, Java Beans, componentes
deotros sectores de la industria que atravesaron sarrollados con herramientas que cumplen las
por estos problemas: el ejemplo más claro lo especificaciones CORBA, SAP, etc. Estas
representa la industria automovilística. tecnologías potencian los dos principales
Actualmente el trabajo en las plantas donde beneficios de la tecnología de componentes:
se construyen los autos se limita al ensamblar La división en componentes reduce la
componentes; estos componentes se complejidad, permite la reutilización y
suministran listos para que los proveedores, acelera el proceso de ensamblaje de
especializados en la fabricación 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 más complejos y de mayor calidad.
componentes distintos. La tecnología de La interoperabilidad entre componentes
componentes va de la mano de la de distintos fabricantes aumenta la
especialización. competencia, reduce los costos y facilita
la construcción de estándares. El software
Pero la especialización no fue inventada por se hace cada vez más rápido, de mejor
la industria del automóvil, la naturaleza la calidad y a menor costo.
usa desde hace millones de años. Los seres La principal implicación para la industria
vivos se constituyen de órganos, y cada uno del software es que se dividirá en dos:
es un conjunto de células 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
automóviles, las interfaces y especificaciones de los años 90 ¿por qué ahora suponen una
de todos sus componentes se acuerdan de revolución? Porque los beneficios son
antemano para que no haya sorpresas alcanzables sólo ahora, cuando la tecnologías
durante el proceso. Estas interfaces entre para empaquetarlos alcanza la suficiente
componentes se definen de la forma más 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 código, de
del software se tienen otras peculiaridades: forma que pueden ser manejados sin
la replicación masiva nunca ha sido importar el lenguaje en el que están escritos.
problema, el principal objetivo es la
personalización masiva: disponer de una El empaquetado del código tardó tanto en
amplia variedad de productos basados en un desarrollarse debido a que va en contra de la
esqueleto común. norma de la mayoría de los programadores
quienes persiguen la eficiencia del código 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 informática las máquinas
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. código innecesario, con el único propósito de
Fueron pasos importantes, pero aún tenían facilitar el desarrollo de aplicaciones,
dos defectos importantes por superar: sólo parecía impensable.
servían para un producto específico y, por
tanto, de valor limitado, y se concibieron
~ 99 ~
Hoy, por el contrario, las máquinas son enviando y recibiendo eventos, y
baratas y la gente que sabe trabajar con ellas comunicándose con otros componentes y
muy cara. Entonces aparecieron las técnicas el resto de la aplicación a través de la
orientadas por objetos: colocar datos y red.
funciones juntas para formar objetos, fue un Introspección. Una forma de aislar el
gran paso sin el que ninguna de las componente del mundo exterior, lo que
tecnologías de empaquetado de componentes permite centrarse solamente en lo que
actuales hubiera prosperado. La orientación hace y cómo lo hace.
por objetos es el mayor paradigma que jamás Distribución. Los componentes pueden
existió en el mundo de la informática. No transmitirse a través de una red.
obstante, los primeros intentos de
empaquetado de código fueron un fracaso: La explosión de la tecnología de
los desarrolladores no podían creer que el componentes fue lenta, en parte debido al
envoltorio fuese más complejo que el código sentimiento de insatisfacción que la
que contenía. Actualmente, el empaquetado orientación por objetos dejó en sus inicios:
de código sigue siendo complejo y arrastra las promesas de facilidad en la reutilización
considerables problemas: aumenta de código nunca fueron cumplidas, hasta
considerablemente el tamaño de los pro- ahora.
gramas, empeora el rendimiento de éstos y
hace consumir más recursos en las máquinas CREAR LA ARQUITECTURA DE UNA EMPRESA
donde se ejecutan. Exactamente los mismos Diseñar la arquitectura de sistemas de una
problemas que se les atribuyen a las GUI y a gran organización es una tarea que puede
pesar de ello prácticamente todo el mundo resultar intimidatoria a mucha gente; son
usa alguna. tres los requisitos para empezar: un
departamento de arquitectura, la redacción
de un anteproyecto de diseño de la A pesar de estos problemas las ventajas
arquitectura y un documento que recoja los superaron a los inconvenientes y, aunque las
valores que impulsará. Es fácil de olvidar, tecnologías de empaquetado de código
dado el alcance actual, que el uso de la siguen siendo muy complejas de construir,
informática en las organizaciones es un alcanzaron un alto grado de facilidad de uso,
fenómeno relativamente reciente. No es de de forma que los desarrolladores dedicados a
extrañar que las estructuras y procesos, para la fabricación de componentes sólo tienen
obtener un valor real de esta inversión, que ocuparse de desarrollar cada vez
hayan retrasado la inversión en sí misma, y el mejores componentes, sin preocuparse de
resultado fue un gigantesco enredo. nada más.

A pesar de que hoy existen diversas técnicas La tónica aplicada hasta el momento por la
de empaquetado de componentes, con mayoría de las empresas es buscar la
grandes diferencias según de donde robustez de los estándares, a través de
procedan, también tienen importantes compra de tecnología a un único fabricante o
similitudes: exigiendo el desarrollo de aplicaciones que
Transparencia en cuanto a la localización, funcionen sobre una rígida arquitectura. Lo
lo que permite usar un componente sin la primero es crear la dirección de
preocupación de dónde se encuentra arquitectura, que coordine y se asegure de
físicamente, incluso si éste se cambia de que la arquitectura del sistema facilita a las
sitio. aplicaciones existentes -y futuras- la
Definición de la interfaz. Especifican la consecución 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 visión de la actividad de la
programación o del sistema operativo organización, estar al día de los más
donde se usará. Normalmente se inspiran relevantes progresos tecnológicos 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
Invocación. 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 técnico; debe ser pragmático 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 diseño debe
confianza del director de sistemas de la responder a dos preguntas: de qué servicios
organización. existentes se puede hacer uso y a qué nuevo
servicio se puede contribuir. Esto supone no
volver a pensar en aplicaciones aisladas, para Para comprender donde no se debe de meter
comenzar a pensar en términos de compartir el departamento de arquitectura, volvamos
servicios de aplicaciones. al modelo de cuatro capas de la
organización: los desarrolladores son sus
El último punto es crear un documento con clientes y los responsables de la
los valores de la arquitectura. Debe ser un infraestructura sus proveedores. Los
ardocumento breve, de menos de 1000 quitectos de sistemas que pasan demasiado
palabras, distribuido a todo el personal de tiempo eligiendo sistemas operativos o
sistemas de la empresa. Debe cubrir puntos rediseñando las líneas de negocio de su
como: definir cuando se deben usar dos organización, no invierten el tiempo
capas y cuando tres; qué middleware se necesario en su trabajo.
usará y que estándares -sistemas operativos,
de mensajería, etc.- no están abiertos a De cualquier modo, la línea de división entre
debate; ser un documento deliberadamente infraestructura y arquitectura puede ser muy
minimalista, permitiendo libertad a la gente difícil de ver: muchos de los elementos que
con creatividad para elegir cuál es la mejor en un momento dado forman parte de la
solución para resolver su problema arquitectura, posteriormente se consideran
particular. parte de la infraestructura, como ocurre con
las redes locales y ocurrirá con los sistemas
de mensajería. 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 estériles al
como es lógico, con una débil infraestructura señalar claramente qué puntos no están
no es posible edificar una sólida abiertos a debate, de forma que el personal
arquitectura. se centre en debatir los problemas reales; 2)
ayuda a identificar al personal que cumple
los mejores requisitos para trabajar con la Una importante clave en el enfoque moderno
arquitectura, de forma que se puede utilizar de la informática es ver las aplicaciones
este documento como criterio de selección como una colección de servicios. Estos
de los nuevos técnicos; y 3) le proporciona a servicios deberían ser, hasta donde sea
los técnicos la posibilidad de enfocar sus posible, independientes unos de otros, de
esfuerzos y su creatividad en campos en los forma que se puedan sustituir, eliminar o
que realmente serán apreciados. añadir nuevas funcionalidades sin demasiado
esfuerzo. Separar de esta forma los servicios
proporciona el valor añadido de poder elegir A continuación se muestra un ejemplo muy
la mejor tecnología para cada uno de ellos: simple a partir del cual se podría empezar a
los datos de los clientes en una base de datos trabajar:
Este documento, que muestra nuestra posición relacional, los de los empleados en un
frente a los más relevantes puntos de la directorio que cumpla las especificaciones
arquitectura de sistemas de esta empresa, fue LDAP y las descripciones de los productos en
redactado por [el jefe de arquitectura] y un servidor web.
ratificado por [el director de sistemas]. Fue

revisado por última vez en [fecha] y, si ha
El problema en este idílico paisaje es que la transcurrido más de un año, probablemente
mayoría de los servicios con las que ya tienes en tus manos una versión obsoleta.
cuenta la organización no están
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
de [nombre de la organización] y no para encuentran sepultados bajo aplicaciones
censurarlo ni limitarlo. Si tienes una razón lo existentes, en paquetes cerrados de sistemas
suficientemente fuerte como para contravenir propietarios. Por esto es necesario un
~ 101 ~
alguno de los puntos aquí indicados, documéntala servicios de aplicaciones, deberían ser
y hazla llegar. rechazados.
9. Esperamos que la comunicación entre
aplicaciones se realice mediante RPC y 1. Nunca olvides que la actividad de nuestra
productos de mensajería. empresa está encaminada a [actividad de la
10. Toma como inamovible la actual empresa] y que en el departamento de
infraestructura. En ella incluimos Windows 7 sistemas nuestra principal prioridad es
y Office 2007. No desarrolles nada sobre desarrollar sistemas que soporten esa línea de
entornos de 32 bits. Utiliza siempre entornos negocios. Dejemos a otros la innovación en la
de 64 bits. tecnología para que nosotros innovemos en
11. Considera la inversión en personal cómo aplicar esa tecnología en una aplicación
específico cuando investigues nuevas real.
herramientas. Para la mayoría de las 2. Debemos maximizar el valor de nuestro
herramientas, esta inversión excede trabajo desarrollando servicios para
cualquier otra diferencia técnica de las aplicaciones en lugar de aplicaciones aisladas,
mismas. Esto significa que tenemos una serie permitiéndonos reutilizar en el futuro esos
de preferencias: Oracle para bases de datos servicios para crear nuevas aplicaciones rápida
relacionales, SQL vía ODBC para el acceso a y fácilmente. Nuestro anteproyecto de
los datos, Microsoft Windows Server como servicio de aplicaciones define los servicios
servidores, C++ o Java como herramientas de que necesitamos y si existen o no en este
desarrollo de tercera generación y .NET momento. Cuando diseñes nueva aplicaciones
como herramienta de cuarta generación. te pedimos que uses todos los servicios
12. Evita reemplazar aplicaciones actuales a existentes que necesites y consideres a qué
menos que sea totalmente Indispensable. nuevos servicios puede contribuir tu
aplicación.
3. En el nivel más bajo pensamos que todas las LA ARQUITECTURA MODERNA
aplicaciones deben de estar ensambladas por Publicar un conjunto de valores para una
componentes software. La tecnología 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 razón para no hacerlo arquitectura debe contemplar los siguientes
preferimos que uses [tecnología de puntos:
componentes preferida, por ejemplo ActiveX]
Estándares. El desarrollo de Internet y
porque [motivos para preferirla, por ejemplo,
todas las tecnologías que van con ella está parece que dominará el mercado durante
revolucionando el mundo de la algunos años].
informática. Algunos de sus efectos son 4. Deseamos que las herramientas y tecnologías
basadas en Web sean estándares en rápidamente visibles, pero otros no lo son
nuestra empresa de aquí a dos años. Considera tanto. El jefe de arquitectura debe de
esto y realiza una aproximación siempre que estar bien informado de los estándares
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 estándares que,
datos podrían ir sobre dos capas. Esto facilita
aparentemente, poseen la misma el mantenimiento y la reutilización del código
funcionalidad; por ejemplo DCOM y y mejora el rendimiento de las aplicaciones.
CORBA. La decisión debe tomarse 6. Para aplicaciones basadas en objetos
recopilando información claramente distribuidos, preferimos [nombre de la
tecnología, 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 ningún tipo. no usar ninguno de los dos.
Existe una estrategia especial de Data

Warehouse que se encarga de ello.
La capa intermedia. Ya se vio que uno de
8. Si puedes encontrar un paquete desarrollado
los grandes progresos de la arquitectura que realice el 80% de la funcionalidad que
moderna es la subdivisión del software. El buscamos úsalo, en otro caso considera un
“pegamento” que une estas partes para desarrollo a medida: la excesiva
personalización de un paquete conlleva demasiados formar una aplicación 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 colaboración en nuestro anteproyecto de separadamente cada uno en una máquina:
~ 102 ~
A llama a B con un problema; B trabaja en entonces a enriquecer sus productos con
la resolución 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” haciéndose más
esta forma de actuación ¿qué debería pesados y lentos. La alternativa, meter
hacer el proceso A mientras que B trabaja parte de esta nueva funcionalidad en el
en la resolución de su problema? ¿esperar? backend no era demasiado atractiva, así
¿Cómo puede B comunicarle a A algo a que se buscó la solución introduciendo una
menos que éste lo requiera? ¿Cómo puede tercera capa central, situada entre el
B saber dónde 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 A’s 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 añadir excesiva sistemas en tres capas tardaron en
complejidad a la arquitectura. generalizarse debido a que son mucho
más caros y difíciles de desarrollar. La
arquitectura cliente/servidor a dos capas Existen dos tipos esenciales de
sigue siendo útil para la mayoría de los middlewares: los basados en Remote
casos y ahora aparece la tecnología web Procedure Calls RPC y los basados en
para acercar la arquitectura a tres capas Message Oriented Middleware MOM.
a las masas. Middlewares basados en MOM son
inherentemente asíncronos y lo más difícil
La web. La tecnología web cambió en ellos es definir correctamente la
sustancialmente la forma en que las estructura de los mensajes. Los
aplicaciones se desarrollan. Pero la web middlewares basados en RPC son más
tiene muchas más cosas que ofrecer que sencillos de usar, puesto que la sintaxis de
meramente la apariencia externa: Internet las llamadas es prácticamente idéntica a
pronto conectará a la totalidad de la de una llamada en C, pero el
computadores, lo que cambiará por rendimiento de estos sistemas suele ser
completo las reglas del desarrollo de más pobre. Existen algunos fabricantes
aplicaciones; las organizaciones que que distribuyen productos capaces de
permanezcan aisladas no podrán funcionar en uno u otro modo. La mejores
beneficiarse de estas grandes ventajas: herramientas de hoy están basadas en
clientes -actuales y potenciales-, CORBA, están orientadas a mensajes y
empleados y proveedores estarán tienen como inconveniente que son más
continuamente conectados. La web difíciles de usar por los programadores.
popularizó también un gran conjunto de Las herramientas de Microsoft basadas en
tecnologías actuales y pasadas -HTML, COM+ son más limitadas pero muy
TCP/IP, Java, etc. Los arquitectos sencillas de usar y son recomendables si
tenemos ahora un mayor conjunto de anteponemos esta característica a la
herramientas para jugar. longevidad y la calidad del producto.

Veamos un caso típico: una herramienta Estructura cliente/servidor a dos o tres
cliente podría consistir simplemente en capas. La estructura cliente/servidor a dos
una amistosa interfaz HTML utilizable capas nació el día en que alguien conecto
mediante un navegador. Este cliente se su PC a una máquina UNIX. A los usuarios
conecta a través de un servidor web con les gusta la facilidad de uso de los PC y a
una capa intermedia formada por com-los administradores la seguridad que les
ponentes escritos en diversos lenguajes -reporta un servidor UNIX. Nadie lo llamó
C++, Visual Basic y Java- y empaquetados entonces arquitectura a dos capas porque
con Actives o Java Beans. Todo ello se no existía ninguna otra. La novedad de
sustenta sobre un servidor de contar con una interfaz gráfica en lugar de
transacciones -como Microsoft MTS o TP una pantalla verde en modo texto fue bien
Tuxedo- y se conecta a una tercera capa recibida. Los desarrolladores comenzaron
~ 103 ~
de aplicaciones propietarias -mediante arquitectura bien diseñada puede ser muy
Microsoft MQ o IBM MQSeries- y con un beneficioso. La forma de conseguirlo es
servidor de bases de datos vía 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 tecnologías
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 informáti- presentación lógica 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 lógica de la
aplicación. Para ello la aplicación debe de
proporcionarnos un API. Si esto no es Empaquetado. Utilizar tecnología de
posible, la segunda opción sería acceder componentes empaquetados puede
directamente a los datos almacenados. ahorrar años de desarrollo. Se ahorran en
Esto supone un perfecto conocimiento de costos de desarrollo y mantenimiento y se
la estructura de almacenamiento de la logran beneficios como la robustez que
aplicación y, a menudo, tener que proporcionan los componentes que son
solventar problemas de sincronización y testeados por cientos de usuarios. Los
gestión de bloqueos. La última línea de problemas comienzan con la
ataque sería atacar el nivel de personalización. Habitualmente los
presentación. El envoltorio se comunica paquetes de software no cumplen
con la aplicación igual que lo haría un exactamente el 100% de los requisitos, y
usuario. Tecleando datos y recogiendo la arquitectura puede adaptarse a ellos o,
respuestas de la salida por defecto por lo que parece más lógico, adaptarlos a
medio de una interfaz de terminal. Las ella. Por regla general, si se encuentra un
tres técnicas son caras y difíciles, pero paquete que cumple el 80% de los
seguramente usar la aplicación será requisitos, se debe comprar y
mucho mejor que desecharla o desarrollar personalizar; si los requisitos que cumple
otra similar. están por debajo de este porcentaje, es
mucho mejor desarrollar el sistema. Las
CONCLUSIONES personalizaciones complejas pueden ser
Como puede abstraerse del anterior artículo, caras y, a menudo, inviables.
la especialización de la labor de los
Ingenieros de Sistemas es cada vez más Donde mejor se comportan los paquetes es
necesaria. Las funciones que antes se en los procesos que son prácticamente
consideraban simples o de rutina, hoy se iguales en multitud de empresas, como la
convierten en complejas ingenierías de facturación, o cuando lo que se quiere es
intervención, lo que exige a los profesionales personalizar el contenido y no la
de la informática la adquisición de funcionalidad, como en sistemas de datos
conocimientos que la educación de un de gestión documental. A veces ocurre
pregrado no le brinda. que se desea sustituir un paquete, pero
parte de su funcionalidad es indispensable
De acuerdo con esta visión es necesario para otros elementos: el paquete se
dividir la formación en Ingeniería de convierte en parte de la arquitectura.
Sistemas, ciencias computacionales, Para evitar estos indeseables efectos, se
Ingeniería Informática o como se llame en deben envolver los paquetes y realizar la
cada país, en dos áreas claramente integración contra este envoltorio. Esto
establecidas por las exigencias de los encarece el costo de desarrollo pero, a la
actuales Sistemas de Información: larga, mejora la flexibilidad de nuestro
Arquitectos de Sistemas e Ingenieros de sistema.
Software. Los primeros se encargan de
diseñar, construir y mantener la arquitectura Envolviendo sistemas propietarios. Muchos
sobre la que se soportará el core del negocio sistemas propietarios proporcionan
y el manejo de la información que circula en funcionalidades muy valiosas en
todos los procesos de la empresa, y los determinadas misiones críticas. Son fruto
segundos se especializan en diseñar, de años de experiencia y su uso en una
~ 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 información para la toma de de ciclos de formación, hoy es necesaria la
decisiones y el soporte de la empresa. especialización en alguna de las mencionadas
áreas, y la decisión debe tomarse con la
Es el momento preciso para que se actualicen misma prontitud y estructuración con la que
los programas de formación de ingenieros en los desarrollos tecnológicos se producen.
el área de los sistemas, ya no es suficiente





~ 105 ~