ARQUITECTURA

EMPRESARIAL
Los diferentes frameworks de AE establecen una descripcin de la
arquitectura, la cual representan a travs de diferentes 'perspectivas' que
corresponden a las vistas o componentes principales que sirven como
instrumentos para el soporte de las operaciones del negocio.

INVESTIGACIN SOBRE
LOS FRAMEWORKS:
FEA, ZACHMAN,
TOGAF.

Contenido
INTRODUCCION ................................................................................................................................... 0
FEAF THE FEDERAL ENTERPRISE ARCHITECTURE FRAMEWORK (FEA) ................................................ 1
DESCRIPCIN ............................................................................................................................... 2
Modelo de Referencia del Negocio (BRM por sus siglas en ingls) ............................................ 3
Modelo de Referencia de Desempeo (PRM) ............................................................................. 3
Modelo de Referencia de Datos (DRM por sus siglas en ingls) ................................................. 4
Modelo de Referencia de Aplicaciones-Capacidades (ARM por sus siglas en ingls) ................. 5
Modelo de Referencia Tcnico (TRM por sus siglas en ingls) ................................................... 6
TOGAF ................................................................................................................................................. 7
Ciclo ADM .................................................................................................................................... 7
Fase A. Visin arquitectnica ...................................................................................................... 8
Fase B. Arquitectura de negocio ................................................................................................. 9
Fase C. Arquitectura de los sistemas de informacin ................................................................. 9
Fase D. Arquitectura tecnolgica ................................................................................................ 9
Fase E. Oportunidades y soluciones ............................................................................................ 9
Fase F. Plan de migracin ............................................................................................................ 9
Fase G. Implementacin de la gobernabilidad.......................................................................... 10
Fase H. Administracin del cambio de la arquitectura ............................................................. 10
Niveles de detalle ...................................................................................................................... 10
ZACHMAN.......................................................................................................................................... 20
LAS PERSPECTIVAS..................................................................................................................... 21
LAS DIMENSIONES ..................................................................................................................... 21
LA NEUTRALIDAD DEL MARCO DE REFERENCIA ........................................................................ 22
DESCRIPCIN DEL MTODO ...................................................................................................... 23
LOS PASOS DEL MTODO .......................................................................................................... 23
BIBLIOGRAFIA .................................................................................................................................... 28

INTRODUCCION
Las empresas requieren de instrumentos que les permitan una mayor agilidad
empresarial, la cual es posible si se facilita la implantacin de nuevos modelos de negocio
de forma rpida y la obtencin de una mejora en la eficiencia empresarial derivada de
unos procesos mejor orquestados, va una integracin ms natural, confiable y oportuna,
y que, en el mbito operativo de TI, estn representados principalmente en reduccin
de costos, facilidad de la escalabilidad, flexibilidad y oportunidad, y mejor administracin
de la seguridad, entre otros.
El desarrollo de la AE se debe entender como la descripcin integral y estructurada de
los diferentes elementos que conforman la empresa, que es realizada por equipos
interdisciplinarios que conocen muy bien la empresa, sus procesos, las lneas de negocio
y la forma en que la empresa evoluciona, que se acogen a las reglas y principios
corporativos, que aplican las tcnicas y metodologas establecidas, que se arriesgan a
proponer, a innovar y a disfrutar del proceso de construccin de diferentes procesos y
proyectos que apoyan el desarrollo del negocio, y que tienen la capacidad de percibir,
pensar y proyectar la empresa con una visin global e integral, sin perder de vista el
contexto en que sta se desenvuelve. El proceso de construccin de la AE no debe ser
visto solamente como el ejercicio de desarrollar o crear la arquitectura; la importancia
real radica en el hecho de que sta realmente sea til para quien la utiliza, que se
mantenga actualizada y que genere valor al negocio al ser aplicada en la ejecucin de
los proyectos.
El concepto de AE debe ser entendido entonces como una disciplina que provee
conceptos, modelos e instrumentos a las organizaciones para afrontar los retos que
representa la articulacin de las reas estratgicas y los procesos de negocios con las
reas de TI, con lo cual es posible generar mayor valor, mejorar el desempeo, la
comunicacin y la integracin en la empresas, que finalmente llevarn a la creacin de
ventaja competitiva mediante el apoyo efectivo para el cumplimiento de las estrategias
y objetivos establecidos en el negocio.

FEAF THE FEDERAL ENTERPRISE ARCHITECTURE FRAMEWORK (FEA)

La oficina de presupuestos del gobierno federal americano, denominada OMB, desarroll
un modelo denominado FEA Federal Enterprise Architecture, es probable que el nombre en
castellano no sea muy feliz, por lo que uno mejor sera AEG, es decir Arquitectura
Empresarial Gubernamental, cuyo propsito fue simplificar y unificar los procesos entre las
diferentes agencias pblicas. El resultado fue un enfoque metodolgico de diseo centrado
en el ciudadano, que maximiza las inversiones en TI y logra mejores resultados.
El Federal CIO Council adopt principios que gobiernan y representan los criterios con los
cuales se pondera toda la inversin y las decisiones arquitectnicas empresariales para las
agencias federales de los Estados Unidos, este framework entrega un modelo que permite
a los gobiernos desarrollar las transformaciones en forma ordenada y consistente.
FEA (Federal Enterpise Architecture) es una coleccin de modelos de referencias
correlacionadas diseadas para facilitar el anlisis y la identificacin de inversiones
duplicadas, diferencias y oportunidades para la colaboracin dentro y a travs de las
agencias federales, como se grfica en el siguiente diagrama:

Es necesario implementar FEAF para:

Organizar la informacin federal a mayor escala a al que se tiene.

Promover que la informacin sea compartida entre organizaciones federales
Ayudar a las organizaciones federales a desarrollar sus arquitecturas.

Ayudar a las organizaciones federales a un rpido desarrollo en sus inversiones en las

IT.
Servir a las necesidades de los clientes de una manera mejor, rpida y a un costo
efectivo.

Los enfoques presentes en FEAF son los siguientes.

Enfoque Convencional: Requiere una gran inversin de tiempo y dinero al inicio, un

framework debe estar desarrollado para mostrar cmo ser la preparacin para
implementar la arquitectura, adems se debe describir la situacin actual. Finalmente
mostrar un blanco de al cual estar enfocado la arquitectura. Despus de realizadas
estas actividades, la implementacin de la arquitectura cambia a travs de los cambios
de diseo, desarrollo y adquisicin de sistemas.
Enfoque de Segmento: Promueve el desarrollo incremental de la arquitectura por
segmentos dentro de la estructura organizacional. este enfoque se focaliza en las reas
grandes de negocio.
Enfoque Status Quo: Representa el negocio como un usual resultado del fallo de
compartir informacin y hacer frente al rpido cambio del ambiente. Este enfoque
puede resultar en una reprogramacin de los negocio, decreciente actividad, y perder

oportunidades.
Hoy en da muchas iniciativas y esfuerzos entre agencias estn en la va de implementar
arquitecturas en las agencias. Y las arquitecturas empresariales federales no deberan ser
impedimento para las implementaciones de la arquitectura de cada agencia.
DESCRIPCIN
La meta de FEAF (Federal Enterprise Architecture Framework) es mejorar la
interoperabilidad entre las agencias de gobierno de E.U. (Estados Unidos) mediante una
arquitectura empresarial para todo el gobierno federal. Este marco es de aplicabilidad
obligatoria
y
cubre
todas
las
organizaciones
del
gobierno.
FEAF contiene 5 modelos de referencia los cuales definen como es el el comportamiento de
la arquitectura. Estos son:

Modelo de Referencia del Negocio (BRM por sus siglas en ingls)

Es el modelo que provee de una plataforma para facilitar una perspectiva funcional (en
vez de una organizacional) de las lneas de negocio del gobierno federal, incluyendo sus
operaciones internas y servicios para ciudadanos, independientemente de las agencias y
oficinas que las realizan. Esto promueve la colaboracin entre agencias y oficinas y sirve
como fundacin base para la Arquitectura Empresarial Federal y la estrategia eGov.

Modelo de Referencia de Desempeo (PRM)

Es una plataforma para medir el desempeo a travs de todo el Gobierno Federal de EEUU,
que le permite a las agencias gestionar el negocio del gobierno a nivel estratgico,
entregando formas de utilizar la EA para medir el xito de las inversiones en TI y su impacto
sobre los resultados estratgicos. El PRM cumple estas metas estableciendo un lenguaje
comn, a travs del cual las EAs de las agencias describen sus resultados y mtricas
utilizados para alcanzar los objetivos del programa y del negocio. La estructura del PRM est
diseada para expresar claramente las relaciones causa efecto entre entradas y salidas.

Esta Lnea de Visibilidadse implementa a travs del uso de una estructura jerrquica: rea
de Medicin, Categora de Medicin, Grupo de Medicin e indicador.

Modelo de Referencia de Datos (DRM por sus siglas en ingls)

El DRM ha sido diseado con la intencin de promover la identificacin, uso e intercambio
apropiado de los datos y la informacin a travs del gobierno federal por medio de la
estandarizacin de los datos en contexto, intercambio y descripcin. Uno de los problemas
ms frecnuentes que encontramos en el estado es la falta de estndares de
interoperabilidad e intercambio de informacin.

Modelo de Referencia de Aplicaciones-Capacidades (ARM por sus siglas en ingls)

Es una plataforma enfocada al negocio, que clasifica los componentes de servicio de
acuerdo a cmo soportan al negocio y a los objetivos de desempeo.
Sirve para identificar y clasificar componentes de servicio horizontales y verticales que
soportan agencias federales y sus inversiones en TI y activos. El modelo ayuda en
recomendar caractersticas de servicio que puedan soportar el re uso de los componentes
de negocio y servicios a travs del gobierno federal.

Modelo de Referencia Tcnico (TRM por sus siglas en ingls)

El TRM es un marco que categoriza los estndares y tecnologas para soportar y habilitar la
entrega de los Componentes de Servicios y capacidades. Adems, unifica los modelos
tcnicos existentes por agencia y la propuesta del Gobierno Electrnico, entregando una
fundacin para avanzar en la re utilizacin y estandarizacin de la tecnologa y
Componentes de Servicio desde una perspectiva global del gobierno.

TOGAF
The Open Group Architecture Framework (TOGAF) es un mtodo paso a paso y probado
para desarrollar y mantener una Arquitectura Empresarial. Como vimos anteriormente
cubre los cuatro dominios principales de una arquitectura: negocio, sistemas de
informacin (aplicaciones), datos e infraestructura tecnolgica. Adems se enfoca en la
necesidad de que la arquitectura debe apoyar los objetivos y requerimientos del negocio
en forma flexible a travs del tiempo, independiente de fabricantes de tecnologas.
Es importante resaltar que The Open Group es un consorcio neutro a vendedores y
tecnologa cuya visin es el flujo de la informacin sin fronteras. El consorcio permitir el
acceso a informacin integrada dentro y entre las empresas, basado en estndares abiertos
y una interoperabilidad global.
TOGAF est compuesto por tres partes fundamentales:
1. El Mtodo de Desarrollo Arquitectnico (ADM) que veremos ms adelante
2. El Enterprise Continuum (Continuo empresarial), es decir, un repositorio virtual de
todos los activos arquitectnicos (modelos, patrones, descripciones, etc.) que existen
tanto dentro de la organizacin como en la industria de TI
3. La Base de Recursos, la cual es un conjunto de recursos como guas, plantillas,
informacin de fondo, etc. para ayudar al arquitecto en el uso del ADM
En cuanto al ADM, este se aplica para desarrollar la arquitectura de negocio y las tcnicas
con el fin de alcanzar las metas de la organizacin. Por el momento diremos que es un
proceso de 9 fases que lleva a la organizacin de la mano en el establecimiento de una
arquitectura empresarial. Este podra ser adaptado a las necesidades de la organizacin.
Al ser un framework de referencia TOGAF nos da un mapa de carretera para desarrollar el
tema. A continuacin se describir cmo.

Ciclo ADM
El ciclo ADM est diseado [Chase 2006] como un proceso iterativo que nos lleva a travs
de ocho fases de desarrollo, empezando con la Visin Arquitectnica y terminando con la
Implementacin del Control y la Administracin del Cambio a la Arquitectura. La idea es
construir el sistema en fases, completando un ciclo y embarcndose en el proceso de nuevo
para mejorar lo que se construy en la ltima ronda.
Cada fase contribuye a un conjunto de requerimientos, y se desarrolla desde ellos.

Antes de empezar es necesario contestar preguntas bsicas como cunto durar el

proyecto, cunto gastar en el proyecto, a qu nivel de detalle quiero llegar, cules
son las metas de negocio. Incluso antes de que el trabajo arquitectnico realmente inicie
es necesario determinar los principios que gobernarn el resto del trabajo, as como la
metodologa y el marco por utilizar. Por otro lado, en el Anexo A se detalla la
documentacin, recibida como insumo y producida, por cada fase.

Fase A. Visin arquitectnica

En esta fase se determina lo que se har en esta iteracin de desarrollo. Este proceso incluye
determinar el alcance del proyecto y los involucrados, as como asegurar que el proyecto
recibe la aprobacin requerida y el apoyo necesario. En esta fase se documenta la lnea base
actual de la arquitectura as como la arquitectura objetivo, ambas en forma muy general.

Fase B. Arquitectura de negocio

En esta fase se examinan en profundidad los aspectos del proyecto. En esta fase es donde
se hace un modelado extensivo de las arquitecturas actual y deseada usando herramientas
de modelado de procesos y modelos de casos de uso. Se ejecuta un anlisis de la brecha
para determinar lo que es necesario hacer para llevarnos del estado actual (de lnea base)
del sistema a la arquitectura objetivo. TOGAF provee informacin sobre las varias
arquitecturas de la industria y las arquitecturas de sistemas comunes que pueden ser tiles
en esta fase.
Fase C. Arquitectura de los sistemas de informacin
Justo como la fase B trabaja sobre la arquitectura de negocio (definida en la fase A), la fase
C trabaja sobre la Arquitectura Tcnica que se crea en la fase A. En la fase C se analizan las
arquitecturas de datos y aplicaciones. Se documentan los flujos actual y deseado de la
informacin y las aplicaciones que las facilitan, partiendo el sistema en bloques de
construccin que podran o no existir. TOGAF orienta hacia varios modelos y frameworks
existentes pero no es indispensable utilizarlos.
Fase D. Arquitectura tecnolgica
En la fase D se desarrolla la arquitectura tecnolgica que implementa las arquitecturas de
negocio y de informacin que se crean en las fases B y C. Primero se crea una lnea base
para la arquitectura tcnica existente usando el formato de TOGAF. Esto implica partir la
funcionalidad en bloques de construccin arquitectnicos reutilizables y describir las piezas
en trminos de la arquitectura fundamental. Esto le da a todos los que trabajan en el
proyecto, tcnicos o administrativos, experiencia en este ambiente. Luego se profundiza
creando el modelo objetivo de bloques de construccin, especificando lo que cada uno de
esos bloques debe hacer y as sucesivamente. Tambin se realiza un anlisis de la diferencia
para asegurarse que se estn cubriendo todos los aspectos.
Fase E. Oportunidades y soluciones
En fases previas se identifica tanto la lnea base como la objetivo de la arquitectura,
partindolas en bloques de construccin. En la fase E se miran todos esos bloques para
determinar qu se puede reutilizar, qu se debe reemplazar y qu se debe proveer, ya sea
comprndolo o construyndolo. En esta fase tambin se considera si los sistemas existentes
deberan ser reemplazados todos a la vez o no y da opciones para que los nuevos sistemas
puedan coexistir con los viejos. Acorde con TOGAF la estrategia ms exitosa para la fase
de Oportunidades y Soluciones es concentrarse en proyectos que entregarn ganancias en
plazos cortos para que as creen un mpetu para proceder con proyectos de ms larga
duracin. Esta fase puede tambin descubrir oportunidades de aplicaciones adicionales en
cuyo caso podramos encontrarnos iterando entre esta fase y otras anteriores.
Fase F. Plan de migracin
En este punto deberamos tener una muy buena idea de donde estamos y lo que vamos a
alcanzar. En la fase F determinamos cmo llegaremos all. La fase E provee todas las piezas

de la arquitectura objetivo (al menos en el papel) pero rara vez se implementar el sistema
completo de una vez (y si se hizo el resultado podra ser un caos). En esta fase se determina
el orden en el cual se implementan nuevos sistemas, es decir, la cartera de proyectos.

Fase G. Implementacin de la gobernabilidad

Finalmente ya casi empezamos a construir. El proceso de desarrollo actual est fuera de
TOGAF pero no est realmente separado. En esta fase se ponen en lugar los procesos que
asegurarn que todo el desarrollo, sea este parte de la implementacin de una arquitectura
o un proyecto en marcha, est conforme con la arquitectura objetivo. Este paso implica la
creacin de un contrato arquitectnico y requiere de la aprobacin de aquellos trabajando
en el desarrollo. Al final de esta fase su arquitectura objetivo debiera estar instalada.

Fase H. Administracin del cambio de la arquitectura

Una vez completada la arquitectura empresarial es rara vez un sistema esttico. En vez de
eso la necesidad (o percepcin de necesidad) para el cambio es inevitable y es la razn de
existir de la fase H. Se entra en la fase H luego de completar la fase de Implementacin del
Gobierno y por lo tanto la completitud de la arquitectura de la organizacin. En esta fase se
monitorean las solicitudes de cambio y se determinan si se proceder y cmo. Algunos
cambios, tales como la simplificacin de un proceso, pueden ser manejados por una buena
poltica de administracin del cambio y no necesitar moverse de esta fase. Otros tipos de
cambio, como una nueva iniciativa de estndares o una nueva tecnologa, requiere solo de
una retrabajo arquitectnico parcial, tal vez iniciando desde la fase D, Arquitectura
Tecnolgica. Otros cambios, tales como esos que involucran los procesos de negocio
subyacentes, requieren regresar a la fase A, donde la arquitectura vigente se convierte en
la nueva lnea base. En este caso el desarrollo procede justo como se hizo la primera vez
hasta que se arriba a este punto.
Niveles de detalle
Cada una de las fases anteriores se compone de una serie de pasos, cuyos detalles hemos omitido
en esta seccin. El detalle de las fases y sus pasos se describe en el Anexo A.
Anexo A Documentos y pasos generados por TOGAF Lista de documentos y pasos generados por
TOGAF en cada una de sus fases
Fase A Visin arquitectnica

Artefactos de Entrada
1. Solicitud de Trabajo Arquitectnico
2. Estrategia, metas y conductores (driversI) del negocio

3. Principios arquitectnicos, incluyendo los principios de negocio cuando existan de

antemano
4. Continuo empresarial (Enterprise Continuum), documentacin arquitectnica existente
(descripcin del marco arquitectnico, descripciones existentes de la lnea base, etc.)
Pasos
1. Establecer el proyecto
2. Identificar las metas del negocio y los conductores del negocio
3. Revisar los principios arquitectnicos incluyendo los principios de negocio
4. Definir el alcance
5. Definir las restricciones
6. Identificar involucrados y sus preocupaciones, requerimientos de negocio y la visin
arquitectnica
7. Desarrollar la Declaracin del Trabajo Arquitectnico y confirmarla
Artefactos de Salida
1. Declaracin del Trabajo Arquitectnico aprobada incluyendo
a. Alcance y restricciones
b. Plan para el trabajo arquitectnico
2. Declaraciones refinadas de las metas del negocio y los conductores estratgicos
3. Principios arquitectnicos incluyendo los de negocio
4. Visin arquitectnica (escenarios del negocio/visin arquitectnica) incluyendo
a. Arquitectura de Negocio actual, versin 0.1
b. Arquitectura Tecnolgica actual, versin 0.1
c. Arquitectura de Datos actual, versin 0.1
d. Arquitectura de las Aplicaciones actual, versin 0.1 e. Arquitectura del Negocio
objetivo, versin 0.1
e. Arquitectura Tecnolgica objetivo, versin 0.1
f. Arquitectura de Datos objetivo, versin 0.1
g. Arquitectura de las Aplicaciones objetivo, versin 0.1

Fase B Arquitectura de negocio

Artefactos de Entrada
1. Solicitud para Trabajo Arquitectnico
2. Declaracin del Trabajo Arquitectnico aprobada
3. Declaracin refinada de las metas del negocio y conductores estratgicos
4. Principios arquitectnicos, incluyendo los de negocio

5. Contino empresarial
6. Visin arquitectnica
7. Visin arquitectnica (escenarios del negocio/visin arquitectnica) incluyendo
a. Arquitectura de Negocio actual, versin 0.1
b. Arquitectura Tecnolgica actual, versin 0.1
c. Arquitectura de Datos actual, versin 0.1
d. Arquitectura de las Aplicaciones actual, versin 0.1
e. Arquitectura del Negocio objetivo, versin 0.1
f. Arquitectura Tecnolgica objetivo, versin 0.1
g. Arquitectura de Datos objetivo, versin 0.1
h. Arquitectura de las Aplicaciones objetivo, versin 0.1
Pasos
1. Desarrollar la descripcin de la lnea base de la arquitectura de negocio
2. Identificar modelos de referencia, puntos de vista y herramientas
3. Crear el(los) modelo(s) arquitectnico(s)
4. Seleccionar los bloques de construccin de la arquitectura de negocio
5. Conducir puntos de revisin formales del modelo arquitectnico y los bloques de
construccin con los involucrados
6. Revisar los criterios no funcionales (cualitativos) como desempeo, costo, volmenes
7. Completar la arquitectura de negocio
8. Desarrollar un anlisis de brechas y crear reporte
Artefactos de Salida
1. Declaracin de Trabajo Arquitectnico actualizada, si es necesario
2. Principios y metas de negocio as como los conductores estratgicos validados
3. Arquitectura de Negocio objetivo, versin 1.0, incluyendo
a. Estructura organizacional identificando ubicaciones del negocio y relacionndolas
con unidades organizacionales
b. Metas y objetivos del negocio para la empresa y cada unidad organizacional
c. Funciones del negocio un paso detallado y recursivo incluyendo una
descomposicin sucesiva de las reas funcionales ms grandes en sub-funciones
d. Servicios del negocio los servicios que la empresa y cada unidad empresarial
proveen a sus clientes, tanto interna como externamente
e. Procesos de negocio incluyendo mtricas y entregables
f. Roles del negocio incluyendo el desarrollo y modificacin de los requerimientos de
habilidades
g. Modelo de datos de negocio
h. Correlacin entre la organizacin y las funciones relacionando funciones del
negocio en unidades funcionales en la forma de un reporte tipo matriz

4. Lnea base de la arquitectura de negocio, versin 1.0 detallada, si es necesario

5. Vistas atienden las preocupaciones claves de los involucrados
6. Resultado del anlisis de brechas
7. Requerimientos tcnicos identificando, categorizando y priorizando las implicaciones
del trabajo para los dominios arquitectnicos restantes, por ejemplo, una matriz de
dependencia/prioridad (por ejemplo, para guiar la compensacin entre velocidad del
procesamiento de una transaccin y seguridad). Listar los modelos especficos que se
espera producir (por ejemplo, expresado como las primitivas del marco de Zachman)
8. Reporte de la arquitectura de negocio
9. Requerimientos del negocio actualizados
Fase C Arquitectura de Sistemas de Informacin

Artefactos de Entrada
1. Principios de la aplicacin, si existen
2. Principios de datos, si existen
3. Solicitud de Trabajo Arquitectnico
4. Declaracin del Trabajo Arquitectnico
5. Visin arquitectnica (escenarios del negocio/visin arquitectnica)
6. Continuo empresarial (una introduccin)
7. Lnea base de la arquitectura de negocio, versin 1.0 detallada, si es necesario
8. Arquitectura de Negocio objetivo, versin 1.0 detallada
9. Lnea base de la arquitectura de datos, versin 0.1
10. Arquitectura de Datos objetivo, versin 0.1
11. Lnea base de la arquitectura de aplicaciones, versin 0.1
12. Arquitectura de Aplicaciones objetivo, versin 0.1
13. Requerimientos tcnicos relevantes que aplicarn a las Fase C
14. Resultados del anlisis de brecha (de la arquitectura de negocio)
15. Bloques de construccin reutilizables (desde el continuo de la arquitectura, si estn
disponibles)
Pasos
1. Desarrollar la descripcin de la lnea base de la arquitectura de aplicaciones
2. Revisar y validar principios, modelos de referencia, puntos de vista y herramientas
3. Crear el(los) modelo(s) arquitectnico(s)
4. Identificar sistemas de aplicacin candidatos
5. Conducir puntos de revisin formales del modelo arquitectnico y los bloques de
construccin con los involucrados
6. Revisar los criterios cualitativos (como desempeo, costo, volmenes)
7. Completar la arquitectura de aplicaciones
8. Desarrollar un anlisis de brechas y crear reporte

Artefactos de Salida
1. Declaracin del Trabajo Arquitectnico actualizada, si es necesario
2. Lnea base de la arquitectura de aplicaciones, versin 1.0, si es necesario
3. Principios de aplicacin validados, o nuevos principios de aplicacin
4. Arquitectura de Aplicaciones objetivo, versin 1.0 5. Puntos de vista que atienden las
principales preocupaciones de los involucrados
6. Vistas de la arquitectura de aplicaciones correspondientes a los puntos de vista que
atienden las preocupaciones claves de los involucrados
7. Resultados del anlisis de brecha
8. Reporte de la arquitectura de aplicaciones resumiendo qu fue hecho y los hallazgos
principales
9. Anlisis de impacto 10. Requerimientos del negocio actualizados, si es necesario.
Fase C Arquitectura de Datos

Artefactos de Entrada
1. Principios de datos, si existen
2. Solicitud de Trabajo Arquitectnico
3. Declaracin de Trabajo Arquitectnico
4. Visin arquitectnica (escenarios del negocio/visin arquitectnica)
5. Requerimientos tcnicos relevantes que aplicarn a esta fase
6. Resultado del anlisis de brechas (de la Arquitectura de Negocio)
7. Lnea Base de la Arquitectura de Negocio, versin 1.0 detallada, si es necesario
8. Arquitectura de Negocio objetivo, versin 1.0, detallada
9. Lnea Base de la Arquitectura de Datos, versin 0.1, si est disponible
10. Arquitectura de Datos objetivo, versin 0.1, si est disponible
11. Bloques de construccin reutilizables (desde el continuo de la arquitectura, si estn
disponibles)
Pasos
1. Desarrollar la descripcin de la lnea base de la arquitectura de datos
2. Revisar y validar principios, modelos de referencia, puntos de vista y herramientas
3. Crear el(los) modelo(s) arquitectnico(s)
4. Seleccionar los bloques de construccin de la arquitectura de datos
5. Conducir puntos de revisin formales del modelo arquitectnico y los bloques de
construccin con los involucrados

6. Revisar los criterios cualitativos (como desempeo, costo, volmenes)

7. Completar la arquitectura de datos
8. Realizar y verificar el anlisis de impacto
9. Desarrollar un anlisis de brechas y crear reporte
Artefactos de Salida
1. Declaracin del Trabajo Arquitectnico actualizada, si es necesario
2. Lnea base de la arquitectura de datos, versin 1.0
3. Principios de datos validados, o nuevos principios de datos
4. Arquitectura de Datos objetivo, versin 1.0
5. Puntos de vista que atienden las principales preocupaciones de los involucrados
6. Vistas correspondientes a esos puntos de vista seleccionados
7. Resultados del anlisis de brechas
8. Requerimientos tcnicos relevantes que aplicarn a esta evolucin del ciclo de
desarrollo arquitectnico
9. Reporte de la Arquitectura de Datos resumiendo lo que se hizo y los hallazgos
principales
10. Anlisis de impacto
11. Requerimientos de negocio actualizados, si es necesario
Fase C Arquitectura de Aplicaciones

Artefactos de Entrada
1. Principios de aplicaciones, si existen
2. Solicitud de Trabajo Arquitectnico
3. Declaracin de Trabajo Arquitectnico
4. Visin arquitectnica (escenarios del negocio/visin arquitectnica)
5. Requerimientos tcnicos relevantes que aplicarn a esta fase
6. Resultado del anlisis de brechas (de la Arquitectura de Negocio)
7. Lnea Base de la Arquitectura de Negocio, versin 1.0 detallada, si es necesario
8. Arquitectura de Negocio objetivo, versin 1.0, detallada
9. Bloques de construccin reutilizables, del Continuo empresarial, si estn disponibles
10. Lnea Base de la Arquitectura de Aplicaciones, versin 0.1, si es apropiada y est
disponible
11. Arquitectura de Aplicaciones objetivo, versin 0.1, si est disponible
Pasos
1. Desarrollar la descripcin de la lnea base de la arquitectura de aplicaciones
2. Revisar y validar principios, modelos de referencia, puntos de vista y herramientas
3. Crear el(los) modelo(s) arquitectnico(s)
4. Identificar sistemas de aplicacin candidatos
5. Conducir puntos de revisin formales del modelo arquitectnico y los bloques de
construccin con los involucrados

6. Revisar los criterios cualitativos (como seguridad, disponibilidad, desempeo, costo,

volmenes)
7. Completar la arquitectura de aplicaciones
8. Desarrollar un anlisis de brechas y crear reporte
Artefactos de Salida
1. Declaracin del Trabajo Arquitectnico actualizada, si es necesario
2. Lnea base de la arquitectura de aplicaciones, versin 1.0
3. Principios de aplicaciones validados, o nuevos principios de aplicaciones (si se generan
aqu)
4. Arquitectura de Aplicaciones objetivo, versin 1.0
5. Puntos de vista que atienden las principales preocupaciones de los involucrados
6. Vistas correspondientes a esos puntos de vista seleccionados
7. Resultados del anlisis de brechas
8. Reporte de la Arquitectura de Aplicaciones resumiendo lo que se hizo y los hallazgos
principales
9. Anlisis de impacto
10. Requerimientos de negocio actualizados, si es necesario
Fase D Arquitectura Tecnolgica

Artefactos de Entrada
1. Principios Tecnolgicos, si existen
2. Solicitud de Trabajo Arquitectnico
3. Declaracin de Trabajo Arquitectnico
4. Visin arquitectnica (escenarios del negocio/visin arquitectnica)
5. Lnea base de la arquitectura de negocio, versin 0.1 (de la Fase A)
6. Arquitectura Tecnolgica objetivo, versin 0.1 (de la Fase A)
7. Requerimientos tcnicos relevantes de fases anteriores
8. Resultados del anlisis de brechas (de la Arquitectura de Datos)
9. Resultados del anlisis de brechas (de la Arquitectura de Aplicaciones)
10. Lnea base de la arquitectura de negocio, versin 1.0 detallada, si es necesario
11. Lnea base de la arquitectura de datos, versin 1.0 detallada, si es necesario
12. Lnea base de la arquitectura de aplicaciones, versin 1.0 detallada, si es necesario
13. Arquitectura de Negocio objetivo, versin 1.0 detallada
14. Bloques de construccin reutilizables (desde el continuo de la arquitectura, si est
disponible)
15. Arquitectura de Datos objetivo, versin 1.0
16. Arquitectura de Aplicaciones, versin 1.0
Pasos

1. Desarrollar la descripcin de la lnea base de la Arquitectura Tecnolgica

2. Desarrollar la Arquitectura Tecnolgica objetivo
Artefactos de Salida
1. Declaracin del Trabajo Arquitectnico actualizada, si es necesario
2. Lnea base de la arquitectura tecnolgica, versin 1.0, si es necesario
3. Principios tecnolgicos validados o nuevos principios tecnolgicos (si se generaron aqu)
4. Reporte de la Arquitectura Tecnolgica, resumiendo qu fue hecho y los hallazgos
principales
5. Arquitectura Tecnolgica objetivo, versin 1.0
6. Reporte de brechas de la Arquitectura Tecnolgica
7. Puntos de vista que atienden las principales preocupaciones de los involucrados
8. Vistas correspondientes a esos puntos de vista seleccionados
Fase E Oportunidades y soluciones

Artefactos de Entrada
1. Solicitud de Trabajo Arquitectnico
2. Declaracin del Trabajo Arquitectnico
3. Arquitectura de Negocio objetivo, versin 1.0
4. Arquitectura Tecnolgica objetivo, versin 1.0
5. Arquitectura de Datos objetivo, versin 1.0
6. Arquitectura de Aplicaciones objetivo, versin 1.0
7. Bloques de construccin reutilizables (desde el continuo de la arquitectura, si est
disponible)
8. Informacin del producto
Pasos
1. Identificar conductores claves de negocio que restringen la secuencia de
implementacin
2. Realizar una lluvia de ideas acerca de los requerimientos tcnicos desde la perspectiva
funcional
3. Realizar una lluvia de ideas sobre la coexistencia e interoperabilidad de los
requerimientos
4. Ejecutar una valoracin de la arquitectura y un anlisis de brechas
5. Identificar los paquetes de trabajo y proyectos principales

Artefactos de Salida
1. Estrategia de implementacin y migracin
2. Plan de implementacin de alto nivel
3. Anlisis de impacto lista de proyectos
Fase F Planeacin de la migracin

Artefactos de Entrada
1. Solicitud de Trabajo Arquitectnico
2. Declaracin del Trabajo Arquitectnico
3. Arquitectura de Negocio objetivo, versin 1.0
4. Arquitectura Tecnolgica objetivo, versin 1.0
5. Arquitectura de Datos objetivo, versin 1.0
6. Arquitectura de Aplicaciones objetivo, versin 1.0
7. Anlisis de impacto lista de proyectos
Pasos
1. Priorizar proyectos
2. Estimar los requerimientos de recursos y su disponibilidad
3. Ejecutar una avaluacin de costo/beneficio de los diferentes planes de migracin
4. Desarrollar un anlisis de riesgos
5. Generar el mapa de carretera de la implementacin (en el tiempo)
6. Documentar el Plan de Implementacin
Artefactos de Salida
1. Anlisis de impacto Planes de implementacin y migracin detallados
Fase G Implementacin de la gobernabilidad

Artefactos de Entrada
1. Solicitud de Trabajo Arquitectnico
2. Declaracin del Trabajo Arquitectnico
3. Bloques de construccin reutilizables
4. Anlisis de impacto Planes de implementacin y migracin detallados
Pasos
1. Formular la recomendacin de los proyectos
2. Documentar el Contrato de Arquitectura

3. Revisar la gobernabilidad de la implementacin en ejecucin y su conformidad con la

arquitectura
Artefactos de Salida
1. Anlisis de impacto recomendaciones de implementacin
2. Contrato de Arquitectura
3. Sistema implementado conforme a la arquitectura
Fase H Administracin del cambio de la arquitectura

Artefactos de Entrada
1. Solicitud de cambio arquitectnico cambios tecnolgicos
2. Solicitud de cambio arquitectnico cambios de negocio
Pasos
1. Actualizaciones de la arquitectura
2. Cambios al marco arquitectnico y a los principios
3. Nueva solicitud de cambio arquitectnico, para mover a otro ciclo

ZACHMAN
El Marco de Referencia de Zachman (Zachman, 1987) es una herramienta de pensamiento
que permite organizar, clasificar y analizar los diferentes descripciones arquitecturales o
artefactos de una empresa (modelos de estrategia, organigramas, modelos de procesos,
modelos de flujos de trabajo, modelos de datos, reglas de negocio, diagramas de
aplicaciones, diagramas de redes, especificaciones de programas, etc).
Aunque es descrito como un marco de referencia, Zachman es en realidad una taxonoma
arquitectnica, es decir, un esquema para organizar y categorizar artefactos arquitectnicos
(documentos de diseo, especificaciones y modelos) que toma en cuenta tanto a quin est
dirigido el artefacto como a cul asunto particular est siendo orientado. Esto lo hace
perfecto para documentar una Arquitectura de Sistemas de Informacin. Est basado en un
marco de prcticas tradicionales de arquitectura e ingeniera que result en un enfoque en
el cual los ejes verticales proveen mltiples perspectivas de la arquitectura general y en una
clasificacin en el eje horizontal de los varios artefactos en la arquitectura.
El propsito del marco de Zachman es proveer la estructura bsica que soporta la
organizacin, el acceso, la integracin, la interpretacin, el desarrollo, la administracin y
el cambio de un conjunto de representaciones (artefactos) arquitectnicas de los sistemas
de informacin de la empresa. No tiene una metodologa ni un modelo de referencia, por
lo que su implementacin es difcil.

Como puede observarse en la figura, el marco de referencia es una matriz de 5 renglones

(el sexto rengln no lo contamos por ser la empresa en operacin) por 6 columnas, donde
cada tipo de artefacto es caracterizado por una celdilla, la que a su vez es resultado del
cruce de un rengln y de una columna. Cada rengln representa una perspectiva o vista de
cierto rol participante en la empresa (planeador, dueo, diseador, constructor,
programador y usuario), la cual es matizada por seis dimensiones expresadas en forma de
interrogantes (Qu?, Cmo?, Dnde?, Quin?, Cundo? y Por qu?).

LAS PERSPECTIVAS
El Planeador se ocupa del contexto de la empresa, de su entorno competitivo, de las
fuerzas internas y externas que influyen en su competitividad, del posicionamiento de
sus productos y servicios, que lo obligan a especificar sus alcances a largo plazo; esta
perspectiva cubre los componentes del nivel estratgico.
El Dueo se interesa en la operacin del negocio, para lo cual requiere del modelado de
la empresa mediante modelos de procesos, de flujos de trabajo, de logstica
empresarial, de modelos semnticos y de planes de negocio que le permitan controlar
la operacin de la empresa; esta perspectiva se centra en el proceso de negocio, por lo
que constituye en buena medida el nivel de procesos.

El Diseador tiene que ver con la especificacin de los planos conceptuales de los
sistemas de informacin que se requieren para soportar la operacin de los procesos.
El Constructor se encarga del ensamblado y fabricacin de los diversos componentes de
los sistemas de informacin de acuerdo con las restricciones de la tecnologa utilizada.
El Programador trabaja en la fabricacin de los componentes de acuerdo con las
especificaciones del constructor.
Las perspectivas del diseador, constructor y programador se ubican claramente en el nivel
de sistemas de informacin.
LAS DIMENSIONES
El Dato responde a la interrogante Qu?, para la perspectiva del planeador se refiere
a la lista de cosas importantes para el negocio como clientes, proveedores, productos,
servicios, contratos, facturas, etc.; conforme se va descendiendo a las perspectivas
inferiores se van teniendo diferentes descripciones relacionadas con la visin particular
de cada perspectiva: el dueo ve las cosas como entidades representadas en un modelo

conceptual que caracteriza el negocio, pero al diseador le interesa un modelo lgico

que pueda conducir a una base de datos para su almacenamiento correspondiente, lo
que la visin del constructor transforma en un modelo fsico como una tabla de base de
datos, que para el programador ser una entidad de almacenamiento como un archivo
o un registro.
La Funcin se ocupa de la pregunta Cmo?, cubriendo desde la lista de procesos
esenciales del negocio (perspectiva del planeador), su modelado correspondiente
(dueo), hasta la especificacin de los programas (programador) asociados a la
funcionalidad de negocio.

La Ubicacin representa el Dnde?, reflejando desde la lista de las localidades donde

se ubica el negocio (perspectiva del planeador), su modelado logstico (dueo), hasta la
configuracin de las direcciones de red (programador).
La Persona tiene que ver con el Quin?, considerando la lista de unidades
organizacionales importantes para el negocio (planeador), su modelo de flujo de trabajo
(dueo), hasta la especificacin de las restricciones de seguridad (programadores y
usuarios).

El Tiempo captura el Cundo?, incluyendo desde la lista de eventos importantes para

el negocio (planeador), su modelo de planeacin operacional (dueo), hasta la
especificacin de temporizadores (programador).
La Motivacin explica la interrogante Por qu?, abarcando desde la lista de objetivos y
metas (planeador), su plan de negocio para operar la empresa (dueo), hasta la
especificacin de las reglas de negocio correspondientes (programador).

LA NEUTRALIDAD DEL MARCO DE REFERENCIA

El Marco de Referencia de Zachman es una herramienta imprescindible para verificar la
totalidad de artefactos requeridos para una solucin determinada. Por ejemplo, supngase
que se est modelando un proceso de negocio (rengln Dueo, columna Funcin) y se desea
saber qu aspectos considerar. El Marco de Referencia sugiere incluir todas las dimensiones
para el rengln del Dueo, es decir, un modelo semntico de las entidades que manipulan
las actividades del proceso, un modelo logstico para indicar las localidades donde opera el
proceso, la incorporacin de las personas que realizan el trabajo, la identificacin de los

eventos de negocio que inciden o son causados por el proceso, y la incorporacin de las
iniciativas estratgicas que se relacionan con el proceso.

Por otro lado, el Marco de Referencia no prescribe mtodos y tcnicas para el desarrollo de
los artefactos, ni mucho menos recomienda o sugiere herramientas, estndares o
tecnologas particulares. Esto es, el Marco de Referencia de Zachman es neutral ante
cualquier iniciativa de desarrollo de artefactos. Este hecho ha propiciado que un buen
nmero de proveedores de herramientas, acadmicos (Pereira, C. and Sousa, P., 2004) y
organismos independientes como la Comunidad de Reglas de Negocio, propongan modelos
y mtodos basados en el Marco de Referencia. Este mismo razonamiento hicieron los
autores de este trabajo al desarrollar un mtodo para obtener el artefacto de la celdilla
formada por el cruce del primer rengln (Planeador) y la columna de Funcin: la
Arquitectura de Procesos.

DESCRIPCIN DEL MTODO

En la literatura existen diferentes trabajos que han tomado el Marco de Referencia de
Zachman como sustento de diversas iniciativas. Por ejemplo, en (Martin, R. and Robertson,
E., 1999) se propone un modelo de formalizacin del Marco de Referencia; algunos
consultores plantean mtodos de desarrollo de software basados en procesos de negocio
aunque no los publican en la literatura; y en (Pereira, C. and Sousa, P., 2004) se delinea un
mtodo que sugiere ciertos artefactos en las tres primeras perspectivas (Planeador, Dueo
y del Diseador) y define una secuencia de llenado de las celdillas correspondientes. El
mtodo propuesto en este artculo tiene un propsito diferente: apoyar al Planeador en la
especificacin sistemtica de la Arquitectura de Procesos de cualquier empresa.
Entendindose por empresa a toda la organizacin o a cierta parte especfica de ella, como
una divisin, departamento o sucursal. Adems, el mtodo ha sido utilizado para enseanza
(Maldonado, 2003) y en el rediseo de procesos y desarrollo de sistemas de informacin
integrados (Velsquez, 2004).

LOS PASOS DEL MTODO

El mtodo se compone de cuatro pasos:
1. Captura del Organigrama
2. Modelado de la Vista Horizontal
3. Modelado de la Configuracin de Valor

4. Modelado de la Arquitectura de Procesos

Ver figura

PASO 1: CAPTURA DEL ORGANIGRAMA

Este paso sirve de introduccin a la empresa, se entrevista a su Director General, se

entienden su forma de organizarse y su cultura corporativa, se identifican las personas clave
en la operacin. El Organigrama de una empresa muestra la forma en sta se organiza para
realizar el trabajo requerido en los niveles operacional, tctico y estratgico (Rummler, G.
and Brache, A., 1995). En la mayora de las empresas se prefieren los agrupamientos
funcionales a los que suele drseles el nombre de divisiones, departamentos o reas en
los que se concentran personas que tienen por cometido realizar una funcin de negocio
determinada, por ejemplo finanzas, compras, ventas, logstica, etc. Para garantizar
consistencia en los flujos de mando y de informacin, tanto los agrupamientos funcionales
como las personas que los componen, mantienen vnculos verticales de reporte, dando
lugar a estructuras jerrquicas. En realidad el organigrama proporciona una vista vertical de
la empresa. Su artefacto se ubica claramente en la dimensin Persona (Quin?)
PASO 2: MODELADO DE LA VISTA HORIZONTAL

En este paso se logra un entendimiento detallado de la operacin de la empresa. El

Diagrama de la Vista Horizontal proporciona informacin que no es posible extraer del
Organigrama. Fundamentalmente da respuesta a tres preguntas cruciales: Qu hace la
empresa? Cmo lo hace? Para quin lo hace? (Rummler et al., 1995). Las interrogantes
qu y para quin tienen que ver con la misin y con la estrategia, pues se relacionan
directamente con los propsitos de la empresa: qu productos y/o servicios es conveniente
ofrecer al mercado y quines son los clientes a los que hay que dirigirlos. Una vez
establecidos el qu y el para quin, el cmo se refiere a la manera precisa en que se llevarn
a cabo las actividades en la empresa para elaborar los productos y/o servicios y entregarlos

a los clientes previstos, identificando y definiendo los flujos de trabajo entre las diversas
unidades organizacionales. El diagrama resultante se denomina de la vista horizontal pues
centra su atencin en los clientes, a diferencia del organigrama que privilegia la relacin con
el jefe. El artefacto se ubica entre las dimensiones de Datos (productos, servicios, clientes
proveedores) y Funciones (flujos de trabajo).

Para hacer el modelado se procede de la siguiente manera:

i.
ii.

iii.

iv.

Se coloca el bloque de los clientes del lado derecho, el de los proveedores del lado
izquierdo y el de la empresa en el centro;
Se identifican claramente los productos/servicios que provee la empresa (el Qu
hace), los clientes especficos a los que les surten (el Para Quin lo hace) y los
proveedores particulares de los que reciben insumos;
Se traslada el organigrama de la empresa en cuestin al bloque central, se
acomodan las diversas unidades organizacionales respetando la estructura
jerrquica;
Se identifica, dibuja, nombra y numera la secuencia de flujos de trabajo que
intervienen en la operacin de la empresa (el Cmo lo hace).

PASO 3: MODELADO DE LA CONFIGURACIN DE VALOR

En este paso se entiende la manera en que la empresa crea el valor para los clientes. La
Configuracin de Valor describe la lgica que sigue el conjunto de actividades primarias que
crean valor para los clientes. En (Porter, 1980) se presenta la Cadena de Valor como la lgica
de creacin de valor vlida para cualquier tipo de empresa. Sin embargo, en (Stabell, C. and
Fjeldstad, O., 1998) se demuestra que la cadena de valor se ajusta perfectamente para
empresas manufactureras y comerciales pero es incapaz de modelar la creacin de valor de

empresas de servicios. Es por ello que se proponen dos nuevas configuraciones de valor: el
Taller de Valor y la Red de Valor.

Esto significa que cualquier empresa, sin importar su giro, podr ser modelada por una
Cadena, Taller o Red de Valor. Si esta aseveracin es cierta, en consecuencia nuestro
mtodo podr ser aplicado a cualquier empresa. Por otro lado, las configuraciones de valor
se componen de dos tipos de actividades o funciones de negocio: las Actividades Primarias
y las Actividades Secundarias. Las actividades primarias son las actividades relevantes de la
empresa, pues es donde se crea el valor para los clientes y constituyen la razn de ser de la
empresa y de la ventaja competitiva; ocupan la parte inferior del diagrama de configuracin
de valor.
Por el contrario, las actividades secundarias son actividades de soporte para las primarias,
son importantes y tiles pero no son relevantes para la empresa; ocupan la parte superior
del mismo diagrama. Las actividades primarias especficas dependen de la configuracin de
valor de que se trate y tienen que ver con la lgica de creacin de valor, mientras que las
actividades secundarias son las mismas sin importar la configuracin de valor. Tanto las
actividades primarias como las secundarias se componen a su vez de un conjunto de
Actividades de Negocio, que son las que realmente detallan la manera particular en que se
realiza el trabajo en la funcin de negocio.
En la cadena de valor el valor se crea al transformar las entradas (materia prima para
manufactureras y mercancas para comerciales) en productos (terminados para
manufactureras y entregados para comerciales). Es por ello que las actividades primarias

son: Logstica de Entrada, Operaciones, Logstica de Salida, Marketing y Ventas, Servicio. En

contraste, en el taller de valor el valor se crea al resolver problemas particulares de clientes;
es til para modelar empresas de servicios profesionales (consultoras, desarrollo de
software, hospitales, educacin, etc.) y sus actividades primarias reflejan el ciclo de solucin
de problemas: Definicin del Problema, Especificacin de la Solucin, Alternativas de
Implementacin, Ejecucin de la Solucin, Monitoreo de la Solucin. Por otro lado, en la
red de valor el valor se crea al facilitar los intercambios entre los clientes; permite modelar
empresas mediadoras (telefnicas, bancos, logstica, etc.) y sus actividades primarias se
dedican a poblar y operar la red: Promocin de la red y Administracin de Contratos,
Suministro de los Servicios e Infraestructura de Operacin.
Para hacer el modelado se procede de la siguiente manera:
i.
ii.

Se elige la configuracin de valor apropiada

Para cada una de las actividades primarias se anota la secuencia lgica de
actividades de negocio que las soportan; es importante validar meticulosamente
este procedimiento con algn directivo clave.

PASO 4: MODELADO DE LA ARQUITECTURA DE PROCESOS

En este paso se identifican, modelan y definen los procesos esenciales de la empresa, los
cuales se encuentran dentro de las actividades primarias de la configuracin de valor
elegida. Para identificar los procesos esenciales se procede de la siguiente manera:
i.
ii.
iii.

iv.
v.

Las actividades primarias se recorren de izquierda a derecha.

centrando la atencin en las actividades de negocio, se identifica la primera
actividad de negocio como el punto inicial de un proceso.
Al continuar el recorrido hacia la derecha las actividades de negocio se van
cotejando para discernir si pertenecen a una misma agrupacin lgica y, al mismo
tiempo, tambin se determina si alguna corresponde al punto final de un proceso
(en buena medida por sentido comn de una secuencia lgica que inicia en un punto
y termina en otro)
Se le asocia un nombre al proceso identificado
Se contina con el recorrido hasta terminar con todas las actividades de negocio
consideradas.

Es importante validar meticulosamente este procedimiento con algn Directivo clave de la

empresa.

BIBLIOGRAFIA
1. F. Goethals et al., Managements and enterprise architecture click: The FADE framework, Information
Systems Frontiers, vol. 8, no. 2, pp. 67-79, 2006.
[ Links ]
2. F. S. De Boer et al., Change Impact Analysis of Enterprise Architectures, en Proceedings of the 2005 IEEE
International Conference on Information Reuse and Integration (IRI2005), Las Vegas, USA, 2005, pp. 1517.
[ Links ]
3. H. Jonkers et al., Enterprise architecture: Management tool and blueprint for the
organization, Information Systems Frontiers vol. 8, no. 2, pp. 63-66, 2006.
[ Links ]
4. S. H. Kaisler et al., Enterprise Architecting: Critical Problems, en Proceedings of the 38th Hawaii
International Conference on System Sciences (HICSS'05), Hawaii, USA, 2005.
[ Links ]
5. M. Lankhorst, Enterprise Architecture at Work Modeling, Communication, and Analysis, Berlin: Berlin
Heidelberg, SpringerVerlag, 2005, 352 p.
[ Links ]
6. J. M. Morganwalp, y A. P. Sage, Enterprise Architecture Measures of Effectiveness, International Journal
of Technology, Policy and Management, vol. 4, no. 1, pp. 81-94, 2004.
[ Links ]
7. R. Sessions. A Comparison of the Top Four Enterprise Architecture Methodologies, 20 de febrero,
2008;www.objectwatch.com.
[ Links ]
8. J. Zachman, A framework for Information Systems Architecture, the IBM Systems Journal vol. 26, no. 3,
pp. 454-470, 1987.
[ Links ]
9. U. S. D. o. Defense, Technical Architecture framework for Information Management (TAFIM), D. o.
Defense, ed., 1994.
[ Links ]
10. U. N. CONGRESS, Clinger-Cohen Act of 1996, 1996.

[ Links ]

11. R. Whittle, y C. Myrick, Enterprise Business Architecture: The Formal Link between Strategy and
Results,Boca Ratn, USA: CRC Press LLC, 2004, 256 p.
[ Links ]
12. J. Schekkerman, Enterprise Architecture Good Practices Guide: How to Manage the Enterprise
Architecture Practice: Trafford Publishing, 2006, 386 p.
[ Links ]
13. J. Schekkerman, How to Survive in the Jungle of Enterprise Architecture frameworks: Creating or
Choosing an Enterprise Architecture framework p. 266: Quality trade paperback, 2006, p.
[ Links ]
14. B. Scott, An Introduction To Enterprise Architecture, Bloomington: Authorhouse, 2005, p.

[ Links ]

15. R. Wurman, y P. Bradford, Information Architects, Zurich, Switzerland: Graphis Press, 1996,
p.
[ Links ]
16. J. Mc Govern et al., A Practical Guide to Enterprise Architecture, en, Bloomington: Prentice Hall,
2003.
[ Links ]