Arquitectura empresarial para

Ingenieros de Sistemas
extraido de The Rational Edge: Aprenda con dos expertos reconocidos sobre los
puntos en comn clave que comparten la arquitectura empresarial y la arquitectura de
sistemas, y cmo la arquitectura empresarial influencia y a la vez restringe el
desarrollo de sistemas. This content is part of the The Rational Edge.
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

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

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

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, aun 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

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

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

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. Aun 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.

Fuente:
https://www.ibm.com/developerworks/ssa/rational/library/edge/09/jun09/enterprisear
chitecture/
0