VISION SIMPLIFICADA DE COMO CONSTRUIR UNA ARQUITECTURA

Los ingenieros de sistemas generalmente se concentran en el sistema que se est

desarrollando actualmente, sin ocuparse mucho de la empresa que soporta dicho sistema.
Este artculo explora los puntos de conexin que existen entre la arquitectura empresarial
y la arquitectura de sistemas, y describe cmo la arquitectura empresarial beneficia y a la
vez limita el desarrollo de sistemas. Su objetivo es ayudar a los ingenieros de sistemas a
comprender mejor cmo sus esfuerzos en los proyectos que crean o modifican sistemas
pueden verse limitados por, y pueden a su vez modificar la arquitectura de la empresa a la
cual soportan dichos sistemas. En la empresa de hoy, impulsada por los negocios, existe
una relacin directa entre la capacidad de negocios de la empresa y la funcionalidad
implementada en los proyectos.

El cambiante panorama del desarrollo de sistemas

Las empresas actuales estn dejando de lado los sistemas separados que brindan
funcionalidad aislada, para adoptar sistemas mucho ms integrados en los cuales se
potencian los servicios para ofrecer operaciones robustas y eficientes. Por lo tanto, los
sistemas dentro de la empresa estn ms estrechamente integrados y los esfuerzos por
modificarlos son ms complejos. El ingeniero de sistemas que trabaja en un proyecto ya no
se puede focalizar exclusivamente en el sistema que se est modificando, sino que tambin
debe comprender cmo interacta el sistema con otros sistemas dentro de la empresa.
La Figura 1 ofrece una descripcin general de este cambio de foco. Anteriormente la
arquitectura empresarial contaba con el soporte de sistemas separados independientes.
Haba un discreto distanciamiento entre la arquitectura empresarial y los ingenieros de
sistemas, con sus problemas afines. Hoy en da el desarrollo de sistemas se basa mucho ms
en los negocios. Hay una fuerte necesidad de responsabilidad financiera de TI y los gastos
en sistemas y stos deben ajustarse a su beneficio comercial. Por ello, la alineacin entre
negocio y desarrollo es crucial. Hay una participacin constante entre el arquitecto
empresarial y el ingeniero de sistemas que conduce a una mayor alineacin negocio/TI y
colabora con la gobernabilidad tcnica en todo el ciclo de vida, los arquitectos
empresariales participan durante ms tiempo y los ingenieros de sistemas se involucran
antes. Por ltimo, los servicios implementados soportan la obtencin y el monitoreo de
datos durante la operacin. El anlisis de este intercambio impulsa cambios futuros.

Figura 1: Alineacin de arquitectura e ingeniera al inicio del ciclo de vida

Volver arriba

Definiciones
Al hablar sobre sistemas en diferentes niveles es importante definir explcitamente trminos
que de otra manera seran ambiguos dada la diversidad de significados y usos existentes.

Empresa
Una definicin de empresa es una organizacin de negocios i. La organizacin podra ser
parte de una compaa, una compaa entera o incluso una participacin en varias
compaas. Para simplificar el tema, pensemos en una empresa como una compaa.
Aunque hay una gran cantidad de maneras de analizar una empresa, con el fin de razonar
acerca de la evolucin de una empresa, es til considerarla como un sistema a gran escala.
Como todo sistema: a) tiene una razn de ser, ya que brinda ciertos valores a quienes se
involucran en ella; b) posee una financiacin que le permite operar; c) realiza algunas
acciones, cumpliendo con una serie de requisitos; y d) est integrada por componentes,
trabajadores y sistemas de menor nivel, que colaboran para que logre su funcionalidad. (A
lo largo de este artculo, el trmino componente se utiliza para referirse a una parte del
todo que colabora con otras partes.)

Arquitectura empresarial

Hay muchas definiciones para arquitectura empresarial. Por lo general, el trmino

arquitectura empresarial aparece en maysculas como sustantivo propio (por ejemplo, la
disciplina de la Arquitectura Empresarial), aunque, como usted podr observar, nosotros no
lo estamos usando de esta manera. Nos referimos a la arquitectura empresarial simplemente
como la descripcin de la arquitectura de la empresa en cuestin. La disciplina de la
Arquitectura Empresarial ana negocio, estrategia, proceso, mtodo y componentes desde
una cantidad de perspectivas diferentes. Estas perspectivas estn definidas y varan segn
los diferentes enfoques dados a la Arquitectura Empresarial. Las Arquitecturas
Empresariales son realizadas por Arquitectos Empresariales. Las responsabilidades de un
Arquitecto Empresarial exceden el enfoque de este documento.
Por lo tanto el propsito de un arquitecto empresarial, segn se define en este artculo, es
describir los componentes de una empresa, sus relaciones, cmo colaboran e interactan
entre s con el mundo exterior. Una arquitectura empresarial ofrece la orientacin para
implantar los componentes de la empresa. La implantacin de los componentes produce un
cambio en el estado de la empresa.

Sistema
Un sistema es un grupo de elementos que forman un todo unificado y cumplen un fin
comn ii. El fin comn es la razn de ser del sistema. Uno o ms involucrados reconoce/n la
necesidad que satisface el sistema. Por lo tanto, el objetivo del sistema es satisfacer una
serie de necesidades de los involucrados, es decir los requisitos del sistema. Estos requisitos
incluyen qu funcionalidad se muestra y tambin cmo se muestra la funcionalidad dadas
las cualidades requeridas y las limitaciones existentes (es decir requisitos no funcionales).
El sistema satisface sus requisitos ejecutando un conjunto de acciones. Las acciones
satisfacen las necesidades de los involucrados. Como el sistema es un grupo de elementos,
las acciones del sistema son realmente ejecutadas mediante la colaboracin de estos
componentes.
Cabe destacar que los componentes pueden ser cualquier cosa: hardware, software o
personas. Las personas que participan en un sistema como componentes colaboradores se
llaman trabajadores. Algunos de los componentes en s mismo, se pueden considerar
sistemas en todo su derecho y generalmente se los llama subsistemas. Aunque en realidad
los trabajadores tambin pueden considerarse sistemas, segn lo descripto anteriormente,
no los tratamos as, sino como objetos constitutivos ya que no nos incumbe aqu cmo
colaboran sus partes internamente.

Ingeniero de Sistemas
El ttulo de Ingeniero de Sistemas se ha aplicado a individuos que desarrollan cualquier
actividad vinculada con la ingeniera de sistemas. Hemos observado Ingenieros de
Sistemas responsables de todo, desde planeamiento, hasta obtencin de requisitos, captura
de arquitectura, integracin y testeo. Muchas de sus actividades trascienden la disciplina
tradicional de la Ingeniera de Sistemas. En este artculo, nos focalizamos en el rol del
ingeniero de sistemas para garantizar que el resultado del esfuerzo de desarrollo se

ajustar al resto de la empresa y operar de manera homognea. Esencialmente, es

responsabilidad del ingeniero de sistemas crear o actualizar la arquitectura del sistema,
cumpliendo con todas las restricciones impuestas por la empresa en general.

Programa
Un programa es una iniciativa adoptada para cambar el estado de la empresa, para
proporcionar alguna capacidad nueva o mejorada. Su propsito es mover a la empresa de su
estado actual al estado futuro, modificando alguna parte de la empresa, agregando o
modificando componentes de la empresa. Los programas se ejecutan mediante la
implementacin de uno o varios (normalmente varios) proyectos. Obsrvese que los
programas pueden tener un alcance mucho menor que el de toda la empresa. Sin embargo,
para simplificar el tema a tratar aqu, slo expondremos los programas que impactan sobre
toda la empresa.

Proyecto
Un proyecto es una actividad de desarrollo con un objetivo, inicio y fin especficos,
focalizado en brindar algn resultado de valor mensurable que contribuya con una
capacidad. Es comn que un proyecto se focalice en la introduccin de un sistema nuevo en
la empresa, o la modificacin de un sistema existente, aunque su alcance podra ser mayor
o menor. Los proyectos tienen sus propios objetivos y presupuestos. Normalmente se
combinan con otros proyectos formando parte de un programa (ver la Figura 2).

Figura 2: Cmo los programas y los proyectos afectan a la empresa

Volver arriba

Descripcin del nivel actual de la empresa

Ya sea documentada o no, toda empresa tiene una arquitectura integrada por componentes y
sus relaciones y colaboraciones, a menudo capturadas en dibujos, diagramas, documentos,
modelos, etc. Adems de la arquitectura, la empresa tiene una serie de requisitos que debe
cumplir. Tambin hay pruebas para determinar cuan bien la empresa cumple con sus
requisitos.
Nuevamente, ya sea documentado o no, toda empresa tiene sus requisitos y pruebas.
Cuando se implementa una nueva edicin de algn componente de la empresa, se realizar
una determinada cantidad de pruebas para garantizar que el componente cumpla con sus
requisitos. Esto incluye que no dae cualquier funcionalidad de mayor nivel por la forma en
que interacta con otros componentes. Si estas pruebas detectan algn problema, ste debe
rastrearse como defectos de la empresa hasta tanto se resuelva. (El problema podra ser el
componente recientemente emitido o un comportamiento inesperado de algn componente
interviniente.)
Por ello, observamos que estos artefactos, cuando existen y se combinan, forman una
descripcin completa de elementos clave de la situacin actual de la empresa (ver la Figura
3):

Requisitos (y sus impulsores, como motivacin y objetivos)

Arquitectura (incluyendo diseo e implementacin)

Pruebas

Defectos

Figura 3: Artefactos actuales de la empresa

Volver arriba

Los programas cambian a la empresa

Segn lo definido anteriormente, el propsito de un programa es mover a la empresa del
estado actual al estado futuro. Muchas veces esto incluye crear una serie de artefactos que
describen el estado futuro. Sin embargo, si el estado actual est bien documentado, no es
necesario volver a documentar las porciones de elementos (requisitos, arquitectura y
pruebas) que no son modificadas por el programa. Slo es necesario actualizar los
artefactos actuales con los cambios establecidos por el programa. Estos cambios son deltas
que se necesitan aplicar a los artefactos actuales para describir el estado futuro deseado.
En lugar de empezar desde cero, los artefactos del programa debern describir los cambios
del estado actual. Esto asume que se ha comprendido bien (capturado) el estado actual. Si
esto no fuera as, no todo est perdido. Como de todas formas es necesario documentar el
estado futuro, los artefactos creados pueden convertirse en artefactos actuales a nivel de la
empresa despus que se ha creado el programa.
Los programas pueden variar en cuanto a su alcance, desde modificar un aspecto de la
empresa, a transformar todo el negocio de la misma. Por ello, es fcil exceder el alcance de
un programa nico para generar el conjunto completo de artefactos actuales para la
empresa. En cambio, cada programa puede generar los artefactos para las porciones que
modifica. Como muchos programas afectan varias reas de la empresa, las brechas se
eliminan. Este enfoque evita tener que esperar un conjunto completo de artefactos actuales
antes de iniciar cualquier programa de cambio. Este enfoque puede avanzar hasta que las
restantes brechas en los artefactos actuales de la empresa sean relativamente pequeas y
pueden resolverse mediante tareas separadas para cerrar directamente las brechas. Para
obtener una representacin completa y coherente de la empresa, todos los programas
empresariales deben usar convenciones estndares para representar tanto los artefactos
actuales, como los futuros (o por lo menos convertir sus artefactos de/a la convencin
estndar), y efectivamente deben comenzar a construir en base a los artefactos creados por
los programas anteriores. De lo contrario, ser muy difcil lograr la correlatividad entre los
artefactos creados por diferentes programas y lograr una representacin nica coherente de
la empresa. Adems, los artefactos actuales se deben conservar como un repositorio nico
homogneo. No es importante cmo se construye el repositorio, es decir si es un archivo
nico o una consolidacin de bases de datos. Lo importante es que se conserve y se puede
acceder a l como una representacin consolidada coherente.
Si (o una vez que) los artefactos actuales de la empresa estn disponibles, el programa
deber comenzar con estos artefactos y capturar los cambios que se necesitan implementar
al programa. Esto incluye deltas de los requisitos, actualizaciones a la arquitectura y
modificaciones en las pruebas acordes a los cambios de requisitos. Los deltas de los
requisitos capturan los cambios deseados en el comportamiento esperado. Estos cambios
deseados, an cuando se informan inicialmente de manera informal o se perfeccionan ms
adelante, impulsan los deltas de la arquitectura. Tanto los deltas de requisitos, como los
deltas de la arquitectura pueden impulsar cambios en el conjunto de pruebas.

Cuando se ejecuta el programa (es decir, sus proyectos son implantados), se pueden realizar
las pruebas para verificar que los requisitos hayan sido cumplidos y para detectar cualquier
defecto en la implantacin, los requisitos, o las pruebas propiamente dichas. Normalmente
cualquier defecto detectado se resolver en el mbito del programa. Sin embargo, algunos
defectos no pueden resolverse en el mbito del programa, y por lo tanto se convierten en
defectos adicionales a nivel de la empresa.
Al finalizar el programa, la empresa est en el estado futuro definido por el programa.
Como este es el nuevo estado actual para la empresa, es necesario actualizar los artefactos
actuales a nivel de la empresa. Esto es sencillo porque el programa ya ha producido todos
los cambios necesarios para los artefactos. La Figura 4 que muestra una ilustracin del flujo
de artefactos. (Obsrvese que, como es posible que varios programas se estn ejecutando
simultneamente, en este momento la empresa puede implantar cambios adicionales fuera
del alcance del programa. Estos cambios adicionales se fusionarn en el estado actual de la
empresa al finalizar dichos programas.)

Figura 4: Flujo de artefactos entre programa y nivel de la empresa

Volver arriba

Los proyectos implementan el programa

Los programas definen un conjunto de cambios que crean o modifican alguna capacidad de
extremo a extremo. Para lograr la capacidad nueva, normalmente es necesario crear
sistemas nuevos o modificar varios sistemas existentes (quizs mediante la adquisicin de

una aplicacin nueva o cambiando algn proceso). Es usual definir y ejecutar varios
proyectos, uno por cada sistema afectado, para lograr todos los objetivos del programa.
Cada proyecto tiene un alcance especfico que debe cumplir. Ese alcance est directamente
relacionado con los cambios requeridos en la arquitectura para implantar la nueva
capacidad. Es decir el programa define qu nueva funcionalidad se requiere de los sistemas
afectados para implantar la capacidad, y cada proyecto implanta la nueva funcionalidad
para su/s sistema/s. Aunque es posible que un proyecto implante cambios que soporten ms
de un programa, esto es mucho menos frecuente y por lo tanto no nos referiremos a ello en
este documento.
Es ms frecuenta que los requisitos a nivel del programa se implanten a travs de varios
sistemas. En estos casos, se crea un diseo a nivel del programa para mostrar cmo
colaboran los sistemas. Este diseo asigna responsabilidades a cada uno de los sistemas
involucrados. Las responsabilidades se ajustan a los roles que desempean en las
colaboraciones. Este diseo satisface los deltas de los requisitos a nivel del programa. El
resultado es un conjunto de requisitos que derivan de cada uno de los sistemas. No
obstante, hay veces en las que un requisito a nivel del programa se implanta totalmente en
un nico sistema. En estos casos, el requisito a nivel del programa se asigna directamente a
un nico sistema. Ver la ilustracin de la Figura 5 que muestra estas relaciones.

Figura 5: Flujo de requisitos del programa al proyecto

Pero, aqu nuevamente, al ejecutar el proyecto no necesitamos comenzar de cero excepto

que el proyecto est creando un sistema nuevo. Si el alcance del proyecto consiste en
modificar un sistema existente, entonces el sistema tiene un estado actual. Tiene requisitos
que cumplir, una arquitectura, pruebas que han sido realizadas y probablemente algunos
defectos abiertos. Segn lo descripto anteriormente para los artefactos actuales de la
empresa, si estos artefactos no estn disponibles, se pueden crear en base a una cantidad de
proyectos. Como ocurre con los artefactos de la empresa, los artefactos de sistemas
necesitan mantenerse en un repositorio y en un formato homogneo para potenciarlos
eficientemente.
Los artefactos de sistemas actuales, as como los artefactos de la empresa actuales, incluyen
requisitos, arquitectura, pruebas y defectos existentes. Por lo tanto si un sistema tiene
artefactos actuales existentes entonces en lugar de comenzar con una lista en blanco, el
proyecto deber crear sus artefactos futuros como cambios de los artefactos actuales. As
como el programa brinda actualizaciones de los artefactos de la empresa, el proyecto
tambin ofrece actualizaciones de los artefactos de sistemas. Obsrvese la Figura 6 para
consultar las relaciones existentes entre artefactos de sistemas actuales y artefactos de
proyectos.

Figura 6: Flujo de artefactos entre el nivel del proyecto y el nivel del sistema
Volver arriba

Unir todas las piezas

Lo descripto anteriormente brinda un flujo de extremo a extremo para la evolucin de la

empresa y de los sistemas, incluyendo sus artefactos actuales, a travs de la ejecucin de
programas y proyectos. Hay que admitir que esta es una visin simplificada, que asume
slo un paso entre la empresa y sus sistemas. Por supuesto existe la posibilidad de que se
produzcan pasos adicionales con los niveles intervinientes y sus artefactos. Sin embargo, se
utiliza el mismo enfoque, el cual se puede aplicar homogneamente a cada nivel de
descomposicin existente, con las decisiones apropiadas en cuanto a qu mecanismo
(programa, subprograma, proyecto, subproyecto, etc.) actualizan estos niveles
intervinientes. La Figura 7 muestra el flujo completo, de extremo a extremo, para esta
visin simplificada.

Figura 7: Flujo de extremo a extremo de la empresa a los sistemas

Volver arriba

Conclusin
Algunas organizaciones ya han desarrollado prcticas para administrar sus artefactos
actuales para los niveles de empresa y sistemas y estn cosechando los beneficios de
potenciar estos artefactos. Otras recin estn comenzando y avizoran beneficios futuros. Sin

embargo, el objetivo y el enfoque son iguales en todos los casos. Para administrar
eficientemente la evolucin de la empresa, es necesario comprender sus requisitos y
funcionalidad actuales y cmo logra esa funcionalidad (su arquitectura). Adems es
necesario comprender si su desempeo actual es el correcto en trminos de pruebas y
defectos existentes.
No es eficiente recrear estos artefactos en cada programa. En cambio las organizaciones
desean reutilizar el conocimiento que poseen actualmente y desarrollar los artefactos como
los desarrollos de la empresa. Por ello, la organizacin siempre tiene una visin precisa del
estado actual, es capaz de planificar eficientemente la evolucin de la empresa y reduce el
esfuerzo total realizado, potenciando los artefactos en cada programa. An cuando sea poco
prctico capturar un set completo de artefactos actuales para toda la empresa, las
organizaciones obtienen beneficios al capturar los artefactos para una parte de la empresa,
cuanto mayor sea esta parte, mayor ser el beneficio.
Sin una visin precisa de la situacin actual, cada programa debe: a) crear una
representacin del estado actual desde cero, examinando la empresa antes de avanzar con
los trabajos del programa; b) intentar construir una representacin del estado actual
aplicando sucesivamente modificaciones implantadas por programas anteriores; o c)
desistir del intento de representar el estado actual e intentar modificar una arquitectura
desconocida, con la esperanza de que las modificaciones no produzcan consecuencias no
deseadas. Hemos visto a las organizaciones intentar estas tres opciones, slo para aprender
dolorosamente que se necesita contar con una visin precisa del estado actual de la empresa
para su correcto funcionamiento.
Es igualmente cierto que las organizaciones se benefician ampliamente con la reutilizacin
de artefactos a nivel de los sistemas. Una empresa tiene muchos sistemas y por lo tanto los
beneficios de la reutilizacin se multiplican por la cantidad de sistemas. La complejidad de
muchos sistemas ha superado ampliamente la capacidad de cualquier individuo para
mantenerlo completamente en su mente. Los artefactos que capturan los requisitos, la
arquitectura, las pruebas y los defectos de un sistema constituyen una necesidad para la
comunicacin. Los beneficios de potenciar estos artefactos con cada proyecto nuevo
incluyen: mayor homogeneidad, menos errores y menor esfuerzo general.
Hemos ilustrado cmo la arquitectura de la empresa brinda la base para su evolucin
mediante los programas. Los programas individuales y la organizacin toda se benefician al
especificar el programa en trminos de cambios del estado actual de la empresa. Estos
cambios impulsan y restringen el trabajo realizado en los proyectos. Los proyectos
desarrollan sistemas a partir de su estado actual, pero lo hacen slo para cumplir con los
requisitos asignados y derivados que provienen del programa. Para completar el ciclo, los
proyectos y los programas deben aplicar sus cambios al sistema y a los artefactos de la
empresa actuales, as podrn ser precisos cuando se produzcan modificaciones futuras.
IBMofrece una serie de productos y mtodos para asistir al Arquitecto Empresarial y al
Ingeniero de Sistemas a travs del ciclo de vida. Si usted desea conocer ms acerca de estos
productos especficos, este vnculo es un bueno comienzo. En cuanto a los mtodos, la
Figura 8 ilustra algunos de los mtodos que se aplican a lo largo del ciclo de vida.

Model
Driven Service-Oriented
Component
Systems
Modeling
and Business
Development
Architecture *1
Modeling *1

IBM Global
Services
Method *1

Visin
Estrategia
Adquisiciones
Requisitos
Arquitectura
Empresarial
Arquitectura
de
Servicios
Simulacin
Arquitecturas
Tcnicas
Diseos
Implantacin
Pruebas
Implementaciones
*1 Slo para IBM Global Business Services
Figura 8: Mtodos que soportan Arquitectos Empresariales e Ingenieros de Sistemas a
lo largo del ciclo de vida
La visin simplificada presentada en este artculo brinda una base de comprensin comn
para toda la organizacin. Mediante la ilustracin clara de las relaciones que hemos
descripto, los ingenieros de sistemas podrn comprender mejor cmo sus esfuerzos se ven
limitados por o colaboran con la arquitectura general de la empresa. Adems, hemos
ilustrado la relacin directa entre la capacidad de negocios de la empresa y la funcionalidad
implementada en los proyectos.