FRAMEWORKS DE ARQUITECTURA EMPRESARIAL

Zachman. Este framework de arquitectura empresarial fue creado por John A.

Zachman en 1984. Tambin se public en 1987 por IBM Systems Journal.
Cuenta con bastante popularidad, tiene sus aos ya de experiencia y uno de
los ms utilizados en la actualidad. El Framework de Zachman normalmente
es representado como un acotado 6 x 6 "matriz" con los interrogantes de
Comunicacin como las columnas y las Transformaciones como Filas.

Las clasificaciones del framework son representadas a travs de las celdas de

la matriz, es decir, la interseccin entre las preguntas y transformaciones. Las
transformaciones pueden ser perspectivas o modelos, stas se presentan
mediante combinaciones perspectiva/modelo. Las columnas son denominadas
nombres de clasificacin y comprenden los siguientes interrogantes de
comunicacin.

Qu?

Cmo?

Dnde?

Quin?

Cundo?

Por qu?
A continuacin se explica en que consiste cada uno de ellos.

QU? - INVENTORY SETS.

Describe las entidades involucradas en cada punto de vista de la empresa.

Los ejemplos incluyen los objetos de negocio, datos del sistema, las tablas
relacionales, las definiciones de campo . En efecto las partes interesadas de la
empresa como se vern relacionadas con la futura AE respecto a la data,
tambin entendido como los datos.

CMO? - PROCESS FLOWS.

Muestra las funciones dentro de cada perspectiva. Incluyen procesos de

negocio, la funcin de la aplicacin de software, la funcin del hardware del
equipo, y lazo de control del lenguaje . Enfocado as en la funcin de los flujos
de proceso que llevan a cabo.

DNDE? - DISTRIBUTION NETWORKS.

Muestra las localizaciones y las interconexiones dentro de la empresa. Esto

incluye lugares geogrficos empresariales importantes, secciones separadas
dentro de una red logstica, la asignacin de los nodos del sistema, o incluso
las direcciones de memoria dentro del sistema . En s, la distribucin de las
redes dentro de la organizacin.

QUIN? - RESPONSIBILITY ASSIGNMENTS.

Representa las relaciones de las personas dentro de la empresa. El diseo de

la organizacin empresarial tiene que ver con la asignacin de trabajo y la
estructura de autoridad y responsabilidad. La dimensin vertical representa la
delegacin de autoridad, y la horizontal representa la asignacin de la
responsabilidad . Asignando las responsabilidades a personas con roles
especficos.

CUNDO? - TIMING CYCLES.

Representa el tiempo, o el caso de las relaciones que establecen los criterios

de rendimiento y los niveles cuantitativos de los recursos de la empresa. Esto
es til para disear el programa maestro, la arquitectura de procesamiento,
arquitectura de control, y dispositivos de sincronizacin . Los ciclos de tiempo
son tiles a la hora de llevar un control sobre el desarrollo de la AE.

POR QU? - MOTIVATION INTENTIONS.

Describe las motivaciones de la empresa. Esto pone de manifiesto los

objetivos de la empresa y los objetivos, plan de negocios, la arquitectura del
conocimiento, y el diseo de los conocimientos . Las intenciones de motivacin
deben ser claras a la hora mostrar los cambios que traera la implementacin
de la AE. Las filas estn representadas por las transformaciones que pueden
ser perspectivas y modelos, stas se presentan mediante combinaciones
perspectiva/modelo. El Framework presenta un sistema de clasificacin para
registrar diferentes puntos de vista en funcin de sus roles. Las perspectivas y
modelos son:

Perspectiva Ejecutiva/contexto de alcance.

Perspectiva de gestin de Negocio/conceptos de negocio.

Perspectiva de la Arquitectura/lgica del sistema.

Perspectiva de Ingeniero/tecnologa fsica.

Perspectiva Tcnica/componentes de la herramienta.

Perspectiva Empresarial/instancias de operacin.

Cada una de las filas representa una vista en particular, una fila superior en la
mayora no est directamente relacionada con una fila inferior. Cada fila debe
tener detalle sobre la solucin en su nivel, para pasar a la siguiente fila la
informacin necesaria asumiendo las limitantes que tenga. Pero, si una fila
inferior tiene limitantes quizs no afecte a una fila superior. Las filas se definen
a nivel general de la siguiente manera:

Perspectiva Ejecutiva/contexto de alcance.

Tpicamente esta perspectiva es asumida por miembros de la junta y lderes

ejecutivos, quienes definen el contexto del negocio junto con el alcance y
lmites de la empresa. Esta perspectiva es un nivel de planificacin. Los
planificadores de contexto del negocio describen qu, cmo, dnde, quin,
cundo y cmo se debe hacer. Los contextos de alcance describen un alcance
de los modelos, arquitecturas, y las descripciones de la organizacin.

Perspectiva de gestin de Negocio/conceptos de negocio.

Tpicamente esta perspectiva es asumida por el director o administrador de la

unidad de negocios de la organizacin, es l, quien puede definir los conceptos
de negocio donde se describen modelos, arquitecturas, requisitos de alto nivel
para la empresa y descripciones que son utilizadas por los propietarios de los
procesos de negocio.

Perspectiva de la Arquitectura/lgica del sistema.

En esta perspectiva trata de confundirse un poco con TI, pues, es la

perspectiva del diseador quien debe crear el modelo de la lgica del sistema
que se describe por medio de modelos, arquitecturas, y descripciones que son
utilizados por los diseadores, ingenieros y arquitectos que estn en busca de
un compromiso entre lo que es deseable y lo que es tcnicamente posible.

Perspectiva de Ingeniero/tecnologa fsica.

La perspectiva del ingeniero se basa en crear un modelo de la tecnologa fsica

mediante modelos, arquitecturas y descripciones que se utilizan para disear y
crear un proyecto real. En s, traer modelos cerca de la realidad fsica. El
enfoque principal son las limitaciones y la realidad a construir.

Perspectiva Tcnica/componentes de la herramienta.

La perspectiva tcnica tiene que ver con la implementacin, configuracin de

herramientas, la aplicacin de herramientas y la conversin de los modelos
fsicos en realidad. Los componentes de la herramienta describen elementos
particulares o partes de elementos que se incluyen en el producto final (por
ejemplo, componentes de software, documentacin, y as sucesivamente).

Perspectiva Empresarial/instancias de operacin.

En esta ltima perspectiva se observa la empresa en funcionamiento con

todas las implementaciones de las perspectivas anteriores. Esta es la
perspectiva del usuario final y cubre la ejecucin real en s muestra el objetivo
del modelo. Usted no tiene que definir modelos en esta perspectiva.

SOFWARE A UTILIZAR: Architec, Metis

LENGUAJES DE MODELADO: ITM,BPM,UML

TOGAF. Este framework de arquitectura empresarial fue desarrollado por The
Open Group, su nombre TOGAF proviene de las siglas (The Open Group
Architecture Framework). Su primer desarrollo se dio en 1995 basado en
TAFIM (Technical Architecture Framework for Information Management) un
modelo de referencia para arquitectura empresarial desarrollado por el
Departamento de Defensa de los Estados Unidos. TOGAF se puede ver en 4
grandes grupos:

En primera instancia TOGAF se enfoca en torno a la arquitectura empresarial,

comprendiendo sus 4 arquitecturas: arquitectura de negocio, arquitectura de
datos, arquitectura de aplicacin y arquitectura de tecnologa.

ARCHITECTURE DEVELOPMENT METHOD (ADM). TOGAF propone

Architecture Development Method (ADM) con las siguientes fases Mtodo de
Desarrollo de Arquitecturas (ADM) propuesto por el Open Group

METODO ADM

Las actividades en el mtodo de desarrollo de arquitecturas son de forma

iterativa y todas basadas en los requisitos establecidos, llegando a cumplir los
objetivos planteados en la transformacin de la empresa. Este mtodo
proporciona las siguientes fases:

Fase Preliminar

Fase A Visin de Arquitectura

Fase B Arquitectura de Negocios

 Fase C Arquitectura de Sistemas de Informacin 48

Fase D Arquitectura de Tecnologa

Fase E Oportunidades y Soluciones

Fase F Planificacin de Migracin

Fase G Gobernanza de la Implementacin

Fase H Gestin de Cambios de Arquitectura

Fase Preliminar

En esta etapa se define el mbito de la organizacin afectado por la iniciativa

de EA, as como el equipo de EA y los principios de la arquitectura aplicables.
Por ltimo, deben implementarse las herramientas necesarias para el
desarrollo de la arquitectura.

Fase A Visin de Arquitectura Se deben identificar las partes interesadas,

sus inquietudes y requerimientos de negocio. En esta fase, es el momento en
el que tambin se deben confirmar los principios de arquitectura y desarrollar el
documento de visin de arquitectura para poder proporcionar una visin
general de los cambios que se llevarn a cabo en la organizacin como
resultado de la iniciativa de EA.

Fase B Arquitectura de Negocios | Fase C Arquitectura de Sistemas

de Informacin | Fase D Arquitectura de Tecnologa En estas tres fases,
se desarrolla la lnea base de arquitectura (AS-IS Architecture) y la arquitectura
final (es decir, la arquitectura objetivo de la iniciativa de EA, TO-BE
Architecture) para cada dominio de arquitectura (negocio, datos, aplicaciones y
tecnologa). Tras realizar las arquitecturas AS-IS y TO-BE, se debe realizar el
gap analysis entre ambos para producir la hoja de ruta de arquitectura
(Roadmap Architecture) para llegar a la arquitectura objetivo. El entregable
principal de esta etapa es el documento de definicin de arquitectura.

Este documento contiene los artefactos arquitectnicos bsicos creados

durante el proyecto y toda la informacin importante relacionada. El documento
de definicin de arquitectura abarca todos los dominios de la arquitectura
(negocios, datos, aplicaciones y tecnologa) y tambin examina todos los
estados relevantes de la arquitectura (lnea base AS-IS, transicin y destino
TO-BE).

Fase E Oportunidades y Soluciones En esta fase, se define la

planificacin inicial para la puesta en marcha de la arquitectura objetivo, se
identifican y agrupan los principales paquetes de trabajo necesarios, as como
las posibles arquitecturas de transicin (es decir, arquitecturas intermedias
hacia la arquitectura objetivo). Adems, debe definirse la estrategia de alto
nivel para la implementacin y la migracin a la arquitectura TOBE.

Fase F Planificacin de Migracin En esta fase, los proyectos de

migracin identificados en la etapa anterior son priorizados. Para ello, se debe
realizar la evaluacin coste/beneficio, anlisis de riesgo y la asignacin del
valor para el negocio que se obtiene con ellos. Adems, la hoja de ruta de
arquitectura debe ser confirmada, el documento de definicin de arquitectura
debe ser actualizado y el plan de implementacin y migracin debe ser
finalizado.

Fase G Gobernanza de la Implementacin En esta fase, se confirma y

supervisa el alcance y las prioridades de los proyectos de implementacin.
Tambin, se realizan las revisiones de cumplimiento de EA, as como las
revisiones de post-implementacin para validar cualquier proyecto respecto a la
arquitectura definida.

Fase H Gestin de Cambios de Arquitectura En esta fase, se revisa que

la arquitectura resultante alcanza el valor para el negocio que se haba
establecido como objetivo.

SOFWARE A UTILIZAR: Archi

LENGUAJES DE MODELADO: ARCHIMATE

DoDAF. Este framework est especialmente indicado para grandes sistemas

con integracin e interoperabilidad.

El DoD (Department of Defense) en principio apoyado en sus necesidades y

requerimientos public el framework de Arquitectura (C4ISR AF), ahora
conocido como Department of Defense Architecture Framework (DoDAF).
C4ISR AF proviene de las siglas (Command, Control, Communications,
Computers, Intelligence, Surveillance and Reconnaissance) (Comando,
Control, Comunicaciones, Computacin, Inteligencia, Vigilancia y
Reconocimiento) Basados en la experiencia de este framework, sali al
mercado el DoDAF (DoD Architecture Framework). Este framework est
especialmente indicado para grandes sistemas con integracin e
interoperabilidad, y es aparentemente nico en su empleo de los "puntos de
vista operacionales". Estos puntos de vista ofrecen informacin general y
detalles especficos dirigidos a los interesados dentro de su dominio y en la
interaccin con otros mbitos en los que el sistema funcione. La meta de
DoDAF es lograr que las descripciones arquitecturales desarrolladas por
diferentes comandos, servicios y agencias sean compatibles y que se
interrelacionen.
A continuacin una breve resea de cada uno de ellos, basado en la fuente
U.S. Department of Defense.

El todo punto de vista (All Viewpoint) describe los aspectos generales de la

arquitectura de contexto que se relacionan con todos los puntos de vista.

El punto de vista de capacidad (Capability Viewpoint) articula los requisitos de

capacidad, el tiempo de entrega, y la capacidad de despliegue.

El punto de vista de datos e informacin (Data and Information Viewpoint)

articula las relaciones de datos y estructuras de alineacin en el contenido de la
arquitectura, los requisitos operativos, procesos de ingeniera de sistemas y
servicios.

El punto de vista operativo (Operational Viewpoint) incluye los escenarios

operacionales, actividades y requisitos que soportan las capacidades.

El punto de vista del proyecto (Project Viewpoint) describe las relaciones

entre las necesidades operacionales, de capacidad y los diversos proyectos en
ejecucin. El punto de vista del proyecto tambin detalla las dependencias
entre capacidad, requisitos operativos, procesos de ingeniera de sistemas,
diseo de sistemas y servicios.

El punto de vista de servicios (Services Viewpoint) es el diseo de soluciones

que articulan los artistas intrpretes o ejecutantes, Actividades, Servicios, y sus
intercambios, que apoyan las funciones operativas y de capacidad.

El punto de vista de normas (Standards Viewpoint) articula procesos

operativos, negocios, y las polticas de la industria tcnica, normas, directrices,
restricciones y previsiones que se aplican a la capacidad y los requisitos
operativos, procesos de ingeniera de sistemas y servicios.

El punto de vista de sistema (Systems Viewpoint) es el diseo de soluciones

que articulan los sistemas, su composicin, la interconectividad y el contexto
que apoyan las funciones operativas y de capacidad.

Para terminar lo referente a DoDAF, es de aclarar que las anteriores vistas

corresponden a la ltima versin 2.02 expuesta por el departamento de
defensa de los estados unidos.
 SOFWARE A UTILIZAR: HOPEX

LENGUAJES DE MODELADO: IDEF0

CIMOSA Es un marco que proporciona conceptos y modelos que son

necesarios para el modelado de los sistemas empresariales integrados (ver
Figura 2.8). En este sentido puede ser util para sentar las bases de lo que
debe ser el modelado del conocimiento empresarial que debe ser integrado con
el resto de sistemas de la empresa.

La fuerte relacin de CIMOSA con organizaciones internacionales y europeas

ha sido establecida para simular la estandarizacin de los procesos para la
integracin empresarial. CIMOSA propone el modelamiento de organizaciones
a travs de cuatro perspectivas o vistas:

1. Vista de Funciones

2. Vista de Informacin

3. Vista de Recursos

4. Vista organizacional
PRINCIPIOS DE LA ARQUITECTURA CIMOSA

SOFWARE A UTILIZAR: GraiTools 1.0

LENGUAJES DE MODELADO: CIMOSA

COMPARATIVO MARCOS DE ARQUITECTURA EMPRESARIAL

Como se ha mostrado a lo largo del trabajo hasta este punto. Los frameworks
de arquitectura facilitan estndares, herramientas y procesos como mejores
prcticas para la implementacin de AE en las organizaciones.

Los frameworks estudiados Zachman, TOGAF y DoDAF llevan consigo el

objetivo de alinear los objetivos estratgicos de la organizacin. Cada uno de
ellos tiene diferentes enfoques llevando as fortalezas y debilidades para su
aplicacin. En efecto, siendo complicado saber rpidamente cual se acomoda a
las necesidades.

En esta seccin encontrar el comparativo sobre los frameworks tratados

anteriormente. El primero es una evaluacin cualitativa basada en diez
criterios. El segundo una evaluacin cuantitativa basada en los mismos diez
criterios y finalmente una matriz identificando las ventajas y desventajas de
cada uno de los frameworks para el diseo de AE en un colegio privado en
Bogot.
 La numeracin utilizada para evaluar cada uno de los criterios est
representada

Evaluacin Cualitativa de los Frameworks Segn Criterios. El estudio

previo de los framework permite mostrar una evaluacin cualitativa ver tabla
2. En la primera columna se encuentran los criterios de evaluacin,
posteriormente una observacin del criterio. En la ltima columna se encuentra
la evidencia frente a lo dicho en cada uno de ellos.

EVALUACION CUALITATIVA DE FRAMEWORK

N Criterio Observacin Evidencia

1 Acceso a la Zachman proporciona informacin en Zachman
Informacin su web, pero no a fondo http://www.zachman.com/
del TOGAF es fcil encontrar informacin The Open Group.
Framework tanto en la fuente, como otros sitios. http://www.opengroup.org/t
ogaf/
DoDAF permite apreciar la informacin DoDAF
en su web. http://dodcio.defense.gov/T
odayinCIO/DoDArchitectur
eFramework.aspx
2 Metodologia Zachman proporciona la matriz de 6x6 Zachman
pero, no dispone de una metodologa http://www.zachman.com/a
clara bout-the-zachmanframework
TOGAF proporciona el ADM The Open Group. TOGAF
Version 8 Enterprise Edition
Mtodo de Desarrollo de
Arquitectura.
DoDAF se basa en los puntos de vista Viewpoints
 operacionales y modelos para el http://dodcio.defense.gov/T
desarrollo de la AE. odayinCIO/DoDArchitectur
eFramework/dodaf20_view
points.aspx
3 Costos Zachman brinda una copia de licencia Zachman
para interactuar con el estndar del http://test.zachmaninternati
framework en la que usted se onal.com/index.php/homearti
compromete a proteger los derechos cle/17#maincol
de autor, darle atribucin sobre el uso
y no utilizar el material con fines
comerciales. TOGAF brinda 3 tipos de
licencia: corporativa gratuito
exclusivamente para fines internos.
Acadmica exclusivamente para fines
acadmicos (docencia y / o
investigacin). Comercial anual est
disponible para las organizaciones que
desean explotar comercialmente
TOGAF. DoDAF requiere licencia para
su uso.
TOGAF brinda 3 tipos de licencia: TOGAF
corporativa gratuito exclusivamente http://www.opengroup.org/
para fines internos. Acadmica architecture/togaf91/downl
exclusivamente para fines acadmicos oads.htm
(docencia y / o investigacin).
Comercial anual est disponible para
las organizaciones que desean
explotar comercialmente TOGAF.
DoDAF requiere licencia para su uso. DoDAF http://www-
01.ibm.com/support/knowle
dgecenter/SS6RBX_11.4.3
/com.ibm.sa_base.legal.do
c/topics/rsysarch_overview
_base.html?lang=es
http://dodcio.defense.gov/T
odayinCIO/DoDArchitecture
N Criterio Observacin Evidencia
4 Aplicabilidad Zachman se puede acomodar a The Open Group. TOGAF
a muchos tipos de organizaciones. Version 8 Enterprise Edition
organizacion TOGAF conocido internacionalmente Mtodo de Desarrollo de
es como uno de los ms abiertos. Pues, Arquitectura.
se puede acomodar rpidamente.
DoDAF su aplicabilidad es enfocada
a sistemas militares.
5 Beneficios Zachman al igual que TOGAF han Experiencia de Nestac S.A
percibidos dado xito en muchas http://aepyme.blogspot.co
organizaciones. m/2009/07/arquitecturaempre
DoDAF en las entidades militares en sarial-comomodelo.html Tigo
estados unidos han mejorado sus y Copa Airlines
actividades gracias a la https://www.youtube.com/w
 implementacin de su framework. atch?v=EqMtvFOYOXw

6 Gobernabilid Zachman no tiene una fila dentro de Web TOGAF sobre

ad su matriz que hable sobre los gobernabilidad
procesos y estructuras para la http://pubs.opengroup.org/
gobernabilidad. architecture/togaf9-
doc/arch/pt7.html
TOGAF cuenta con Archituecture The Open Group. TOGAF
Capability Framework. Que al mismo Version 8 Enterprise Edition
tiempo referencia normas ISO de Chapter 22 Architecture
gobierno. Governance.
DoDAF tambin presenta una DoDAF
gobernabilidad en su framework. http://www.dtic.mil/ndia/201
0systemengr/ThursdayTrac
k3_10996Golombek.pdf
7 Continuidad Zachman no presenta en su matriz The Open Group. Enterprise
como mantener a futuro la AE. Continuum.
TOGAF Maneja el continuum http://pubs.opengroup.org/
empresarial. architecture/togaf9-
DoDAF no implementa como tal una doc/arch/chap39.html.
continuidad pero, sus vistas The Open Group. TOGAF
operacionales se enfocan en los Version 8 Enterprise Edition
detalles. Chapter 18 Introduction to the
Enterprise Continuum
8 Comprensi Zachman su matriz de 6x6 es un The Open Group. TOGAF
n del poco compleja en su entendimiento. Version 8 Enterprise Edition
framework TOGAF es ms una metodologa. Mas a cerca de TOGAF.
DoDAF orientado ms a sistemas http://www.togaf.info/togaf9 /
militares.

9 Prestigio Zachman muy reconocido e Acerca de Zachman

interesante pues es uno de los http://www.zachman.com/
impulsadores de la AE. Desde su
publicacin en IBM 1987.
TOGAF Goza de buen prestigio por Acerca de DoDAF
ms de 20 aos en el mercado http://dodcio.defense.gov/T
mundial, se enfoca en los procesos odayinCIO/DoDArchitectur
de negocio de la organizacin. The eFramework.aspx
Open Group (www.opengroup.org),
 un consorcio conformado en los aos
90 por ms de 350 empresas,
entidades pblicas y acadmicas,
entre las que se destacan las firmas
ms relevantes en tecnologa
empresarial, como IBM, HP, Oracle,
Philips, SAP, Microsoft y Dell, es el
creador de TOGAF, y con diversas
iniciativas, herramientas y eventos
impulsa su adopcin en el mundo.
DoDAF en el departamento de Acerca de TOGAF
defensa de los estados unidos http://www.opengroup.org/t
totalmente implementado. ogaf/

IDENTIFICACIN DE VENTAJAS Y DESVENTAJAS DE LOS

FRAMEWORKS ESTUDIADOS

Framework Ventajas Desventajas

Zachman Es relativamente Zachman dice que su
sencillo, pues una framework no es una
persona de la empresa metodologa, sino
lo puede aplicar sin ser una estructura. The
especialista. Zachman
No est relacionado Framework IS
con una herramienta en NOT a
especial, permitiendo methodology42 .
ser implementado en Es limitante al
cualquier enfoque. momento de ampliar la
Su matriz al tener 36 AE. Pues no tiene
combinaciones permite definido un futuro sobre
llegar a detalles ms la AE.
profundos. No proporciona un
Puede ser paso a paso para la
implementado para el creacin de la
desarrollo de un arquitectura.
sistema, sin enfocarse a Es un framework que
AE. no especifica los
Las partes modelos a desarrollar en
interesadas tiene su cada celda.
perspectiva de acuerdo Criticado por el
a los enfoques. nmero de celdas que
Las preguntas posee, considerado una
resuelven la perspectiva limitante en algunos
de manera detallada. casos.
La fcil comprensin No es equilibrado, la
de la matriz permite que matriz muestra la lgica
adaptarse a otros de los artefactos para la
 frameworks. AE nicamente.
Se especifican los La informacin pblica
roles dependiendo la sobre cada una de las
perspectiva que se est celdas es poca.
trabajando
TOGAF The Open Gorup Al tener su modelo
menciona que su ADM, no asegura una
framework es un clasificacin de los
mtodo, es artefactos. No tiene
desarrollado por especificacin de roles
variedad de personajes en las fases. El uso es
expertos en el tema. con fines no
Es sencillo en su comerciales, para una
vocabulario generando organizacin debe ser
un lenguaje comn. con licencia.
Contiene estndares
recomendados.
Proporciona
informacin sobre otras
herramientas para
complementar fases.
Presenta un
continuum empresarial,
para el futuro de la AE.
Relaciona la divisin
de la AE en las 4
arquitecturas
generando mayor
interaccin entre ellas.
En Colombia el
gobierno lo toma como
marco de referencia
para las entidades
pblicas
DoDAF Aparentemente Este framework
nico en su empleo de est especialmente
los "puntos de vista indicado para grandes
operacionales". sistemas con integracin
Los puntos de vista e interoperabilidad.
ofrecen informacin Esta claramente
general y detalles enfocado a sistemas
especficos orientados a militares.
los interesados dentro En Per todava no se
del dominio. conoce de su aplicacin
Lograr resolver un a nivel general.
problema especfico a Generalmente los
travs de los puntos de expertos en el
vista asociados. framework son
Integra 8 vistas en su trabajadores del
 ltima versin, departamento de
permitiendo abordan defensa.
temas como las
arquitecturas expuestas
por TOGAF.

RECOMENDACIONES

TOGAF es el framework que tiene mayor usabilidad actualmente.

Se consideran dos criterios importantes con la mxima puntuacin en

la eleccin de TOGAF como lo son Continuidad y Metodologa,
permitiendo de esta manera que sea ms fcil disear la AE.

TOGAF incluye beneficios de mejora en la transformacin de los

dominios de negocio, aplicaciones, datos y tecnologa.

Es til resultar que otro de los factores que apuntan a favor de TOGAF son las
ventajas identificadas en la matriz de ventajas y desventajas ver tabla 4. Por
lo anterior, se decide realizar el diseo de la AE, para el caso de estudio con el
framework TOGAF, enfocndose principalmente en el Mtodo de Desarrollo de
Arquitecturas (ADM) siendo un mtodo genrico para el desarrollo de la
arquitectura, puede modificarse o ampliarse para adecuarse a las necesidades
de la organizacin. Para iniciar, el diseo de AE primero se reconocer la
historia, estructura organizacional, servicios y situacin actual (AS IS) de la AE
del colegio. Posteriormente identificar el estado deseable (TO BE) para cada
dominio de arquitectura (negocio, datos, aplicaciones y tecnologa) y as
disear la AE.