P 1 Togaf91 Es

The Open Group Architecture Framework
TOGOF 9.1
FASE I Introducci�n
P�gina 1 de 670

TOGOF 9.1
1. Introducci�n
TOGAF es un marco - un m�todo detallado y un conjunto de herramientas de apoyo -
para el desarrollo de una empresa de arquitectura. Puede ser utilizado libremente
por cualquier organizaci�n que desee desarrollar una empresa de arquitectura para
su uso dentro de esa organizaci�n TOGAF es desarrollado y mantenido por miembros
de The Open Group, trabajando dentro del Foro de Arquitectura. El desarrollo
original de TOGAF Versi�n 1 en 1995 se bas� en el Marco de Arquitectura T�cnica
para la Gesti�n de la Informaci�n (TAFIM), desarrollado por el Departamento de
Defensa de EE.UU. ( DoD ). El Departamento de Defensa dio el permiso expl�cito Open
Group y el est�mulo para crear TOGAF apoy�ndose en la TAFIM, que a su vez fue el
resultado de muchos a�os de esfuerzo de desarrollo y muchos millones de d�lares de
inversi�n Gobierno de los EE.UU.. A partir de esta s�lida base, los miembros de El
Foro Open Group Architecture han desarrollado versiones sucesivas de TOGAF y
publicado cada uno en el sitio web p�blico Open Group. Si usted es nuevo en el
campo de la arquitectura de la empresa y / o TOGAF, se recomienda leer el Resumen
Ejecutivo (consulte 1.2 Resumen Ejecutivo ), donde encontrar� respuestas a
preguntas tales como: �Qu� es una empresa? �Por qu� necesito una empresa de
arquitectura? �Por qu� necesito TOGAF como marco para la arquitectura de la
empresa?
1.1 Estructura del documento TOGAF

La estructura de la documentaci�n TOGAF refleja la estructura y el contenido de una
capacidad de Arquitectura dentro de una empresa, como se muestra en la Figura 1-1 .
P�gina 2 de 670

TOGOF 9.1
Figura 1-1: Estructura del documento TOGAF

Hay siete partes en el documento de TOGAF: PARTE I (Introducci�n) Esta parte
proporciona una introducci�n de alto nivel a los conceptos clave de la arquitectura
de la empresa y, en particular, el enfoque TOGAF.Contiene las definiciones de los
t�rminos utilizados en TOGAF y notas de la versi�n que detallan los cambios entre
esta versi�n y la versi�n anterior de TOGAF. PARTE II (Arquitectura M�todo de
Desarrollo) Esta parte es el n�cleo de TOGAF. En �l se describe la Arquitectura
M�todo de Desarrollo de TOGAF (ADM) - un enfoque paso a paso para el desarrollo de
una empresa de arquitectura. PARTE III (Directrices de ADM y T�cnicas) Esta parte
contiene una colecci�n de gu�as y t�cnicas disponibles para su uso en la aplicaci�n
de TOGAF y el TOGAF ADM. PARTE IV (Marco de Arquitectura de contenido) Esta
parte describe el marco de contenido TOGAF, incluyendo un metamodelo estructurado
para artefactos arquitect�nicos, el uso de bloques de la arquitectura de
construcci�n reutilizables, y una visi�n general de los entregables arquitectura
t�pica.
P�gina 3 de 670
TOGOF 9.1
PARTE V (Enterprise Continuum y Herramientas) Esta parte trata sobre las
taxonom�as y las herramientas apropiadas para clasificar y almacenar los resultados
de la actividad de la arquitectura dentro de una empresa. PARTE VI (Modelos de
referencia de TOGAF) Esta parte ofrece una selecci�n de los modelos de referencia
de arquitectura, que incluye la Fundaci�n Arquitectura TOGAF y el Integrado de
Informaci�n de Referencia Infraestructura Modelo (III-RM). PARTE VII (Capability
Framework Architecture) Esta parte se analiza la organizaci�n, procesos,
habilidades, roles y responsabilidades necesarias para establecer y operar una
funci�n de la arquitectura dentro de una empresa. La intenci�n de dividir la
especificaci�n TOGAF en estas partes independientes es permitir que diferentes
�reas de especializaci�n que se considerar�n en detalle y potencialmente abordados
de manera aislada. Aunque todas las partes funcionan juntos como un todo, tambi�n
es factible seleccionar determinadas partes para su aprobaci�n y se excluyan otros.
Por ejemplo, una organizaci�n podr�a adoptar el proceso de ADM, sino optar por no
utilizar cualquiera de los materiales relacionados con la Arquitectura de
Capacidad. Como un marco abierto, se recomienda este uso, en especial en las
siguientes situaciones: Se espera que las organizaciones que son nuevas para
TOGAF y desean adoptar progresivamente conceptos TOGAF para centrarse en
determinadas partes de la especificaci�n para su aprobaci�n inicial, con otras
�reas presentadas para su consideraci�n posterior. Las organizaciones que ya han
implementado marcos de arquitectura pueden optar por combinar estos marcos con los
aspectos de la especificaci�n TOGAF.
1.2 Resumen Ejecutivo

En esta secci�n se ofrece un panorama general ejecutivo de la arquitectura
empresarial, los conceptos b�sicos de lo que es (no s�lo otro nombre para la
Arquitectura de TI), y por qu� es necesario. Proporciona un resumen de los
beneficios del establecimiento de una empresa y la adopci�n de la arquitectura
TOGAF para lograrlo.
�Qu� es una empresa?
TOGAF define la "empresa" tal como cualquier conjunto de organizaciones que tiene
un conjunto de objetivos comunes. Por ejemplo, una empresa podr�a ser una agencia
del gobierno, toda una corporaci�n, una divisi�n de una corporaci�n, un solo
departamento, o una cadena de organizaciones geogr�ficamente distantes unidos entre
s� por la propiedad com�n. El t�rmino "empresa" en el contexto de la "arquitectura
de la empresa" puede ser utilizado para designar tanto toda la empresa - que abarca
la totalidad de sus servicios de informaci�n y tecnolog�a, los procesos y la
infraestructura - y un dominio espec�fico dentro de la empresa. En ambos casos, la
arquitectura cruza m�ltiples sistemas, y m�ltiples grupos funcionales dentro de la
empresa. La confusi�n surge a menudo de la naturaleza evolutiva del t�rmino
"empresa". Una empresa extendida incluye hoy en d�a con frecuencia socios,
proveedores y clientes. Si el objetivo es la integraci�n de una empresa extendida,
entonces la empresa cuenta con los socios, proveedores y clientes, as� como las
unidades de negocio internas.
P�gina 4 de 670

TOGOF 9.1
El concepto de modelo de funcionamiento empresarial es �til para determinar la
naturaleza y alcance de la arquitectura de la empresa dentro de una organizaci�n.
Las grandes corporaciones y agencias gubernamentales pueden comprender varias
empresas, y pueden desarrollar y mantener una serie de arquitecturas empresariales
independientes para abordar cada uno. Sin embargo, a menudo hay mucho en com�n
acerca de los sistemas de informaci�n en cada empresa, y por lo general hay un gran
potencial para el aumento en el uso de un marco de arquitectura com�n. Por ejemplo,
un marco com�n puede proporcionar la base para el desarrollo de un repositorio de
Arquitectura para la integraci�n y la reutilizaci�n de modelos, dise�os y datos de
referencia.
�Por qu� necesito una empresa de arquitectura?
El prop�sito de la arquitectura de la empresa es la optimizaci�n de toda la empresa

el legado menudo fragmentado de los procesos (tanto manuales como automatizadas) en
un entorno integrado que es sensible a los cambios y de apoyo de la aplicaci�n de
la estrategia de negocios. CEOs de hoy saben que la gesti�n y explotaci�n de la
informaci�n eficaz a trav�s de TI es un factor clave para el �xito del negocio, y
un medio indispensable para el logro de ventajas competitivas. Una empresa
direcciones arquitectura esta necesidad, proporcionando un marco estrat�gico para
la evoluci�n del sistema de TI en respuesta a las necesidades en constante cambio
del entorno empresarial. Por otra parte, una buena arquitectura de la empresa le
permite lograr el equilibrio adecuado entre la eficiencia de TI y la innovaci�n
empresarial. Permite a las unidades de negocios individuales para innovar de forma
segura en su b�squeda de la ventaja competitiva. Al mismo tiempo, se asegura que
las necesidades de la organizaci�n de una estrategia de TI integrada se cumplen, lo
que permite la sinergia m�s cercano posible a trav�s de la empresa extendida. Las
ventajas que se derivan de una buena arquitectura de la empresa aportar� beneficios
importantes de negocios, que son claramente visibles en la utilidad o p�rdida neta
de una empresa u organizaci�n: Una operaci�n de negocio m�s eficiente: o o o o o
o Menores costos de operaci�n de negocios Organizaci�n m�s �gil Capacidades
empresariales compartidos a trav�s de la organizaci�n Costos de gesti�n del cambio
Inferior Fuerza de trabajo m�s flexible Mejora de la productividad de las empresas
Una operaci�n de TI m�s eficiente: o o o o Bajo desarrollo de software, soporte y

mantenimiento de los costos El aumento de la portabilidad de las aplicaciones
Interoperabilidad mejorada y m�s f�cil sistema y red de gesti�n Mejora de la
capacidad para abordar cuestiones cr�ticas a nivel de empresa como la seguridad
P�gina 5 de 670

TOGOF 9.1
o M�s f�cil actualizaci�n y el intercambio de los componentes del sistema Mejor
retorno de la inversi�n existente, menor riesgo para la inversi�n futura: o o o o
Reducci�n de la complejidad en el negocio y TI M�ximo rendimiento de la inversi�n
en la infraestructura de TI de negocios existentes y La flexibilidad de hacer,
comprar o subcontratar las soluciones de negocio y de TI Reducci�n del riesgo
general en las nuevas inversiones y su coste de propiedad
M�s r�pido, m�s sencillo y m�s barato de adquisiciones: o o o o Las decisiones de

compra son m�s simples, ya que la informaci�n que rige la contrataci�n est�
f�cilmente disponible en un plan coherente El proceso de contrataci�n es m�s
r�pido - maximizar la velocidad de adquisici�n y flexibilidad sin sacrificar la
coherencia arquitect�nica La capacidad de suministro de los sistemas abiertos
heterog�neos de m�ltiples proveedores La capacidad de asegurar las capacidades m�s
econ�micos
Espec�ficamente, �qu� me incitar�a a desarrollar una empresa de arquitectura?
Por lo general, la preparaci�n para las necesidades de transformaci�n de negocios o

de cambios en la infraestructura radicales inicia una revisi�n o desarrollo de
arquitectura empresarial. A menudo las personas clave a identificar �reas de cambio
necesarios para que los nuevos objetivos de negocio que debe cumplir. Estas
personas se conocen com�nmente como las "partes interesadas" en el cambio. El papel
del arquitecto es hacer frente a sus preocupaciones a trav�s de: La
identificaci�n y el perfeccionamiento de los requisitos que los interesados tienen
Desarrollo de vistas de la arquitectura que muestran c�mo las preocupaciones y
necesidades van a ser tratados Mostrando las compensaciones que se van a realizar
en la conciliaci�n de los intereses potencialmente conflictivos de las distintas
partes interesadas
Sin la arquitectura de la empresa, es muy poco probable que todas las inquietudes y
requerimientos ser�n consideradas y se reunieron.
�Qu� es un marco de la arquitectura?
Un marco de arquitectura es una estructura fundamental, o conjunto de estructuras,

que pueden ser utilizados para el desarrollo de una amplia gama de diferentes
arquitecturas. Debe describir un m�todo para el dise�o de un estado objetivo de la
empresa en t�rminos de un conjunto de bloques de construcci�n, y para mostrar c�mo
los bloques de construcci�n encajan. Debe contener un conjunto de herramientas y
proporcionar un vocabulario com�n. Tambi�n debe incluir una lista de est�ndares
recomendados y los productos compatibles que se pueden utilizar para implementar
los bloques de construcci�n.
P�gina 6 de 670

TOGOF 9.1
�Por qu� necesito TOGAF como marco para la arquitectura de la empresa?
TOGAF se ha desarrollado gracias a la colaboraci�n de m�s de 300 empresas miembros

del Foro de Arquitectura de algunas de las principales empresas y organizaciones
del mundo. Utilizando los resultados TOGAF en arquitectura empresarial que sea
coherente, refleja las necesidades de las partes interesadas, emplea las mejores
pr�cticas, y le da la debida atenci�n tanto a las necesidades actuales y las
necesidades futuras percibidas de la empresa. Desarrollar y mantener una empresa
de arquitectura es un proceso t�cnicamente complejo que implica a muchos
interesados y los procesos de decisi�n en la organizaci�n.TOGAF juega un papel
importante en la normalizaci�n y de-riesgo el proceso de desarrollo de la
arquitectura. TOGAF proporciona un marco de mejores pr�cticas para agregar valor, y
permite a la organizaci�n para construir soluciones viables y econ�micas que
permitan atender a sus problemas de negocio y necesidades.
�Qui�n se beneficiar�a del uso de TOGAF?
Toda empresa de organizaci�n o planificaci�n para llevar a cabo el desarrollo e

implementaci�n de una empresa de arquitectura para el soporte de la transformaci�n
del negocio se beneficiar�n del uso de TOGAF. Las organizaciones que buscan sin
fronteras Flujo de informaci�n pueden usar TOGAF para definir y poner en pr�ctica
las estructuras y procesos para permitir el acceso a la informaci�n integrada
dentro de y entre las empresas. Las organizaciones que dise�an e implementan
arquitecturas empresariales utilizando TOGAF tienen la garant�a de un dise�o y una
especificaci�n de adquisiciones que pueden facilitar una puesta en pr�ctica de
sistemas abiertos, permitiendo as� que los beneficios de los sistemas abiertos con
un menor riesgo.
P�gina 7 de 670

TOGOF 9.1
2. Conceptos B�sicos
A los efectos de TOGAF 9, los conceptos b�sicos proporcionados en este cap�tulo se
aplican.
2.1 �Qu� es TOGAF?

TOGAF es un marco de arquitectura. TOGAF proporciona los m�todos y herramientas
para ayudar en la aceptaci�n, la producci�n, el uso y el mantenimiento de una
empresa de arquitectura. Se basa en un modelo de proceso iterativo con el apoyo de
las mejores pr�cticas y un conjunto reutilizable de activos arquitectura existente.
2.2 �Qu� es la arquitectura en el contexto de TOGAF?

ISO / IEC 42010:2007 define "arquitectura" como: "La organizaci�n fundamental de un
sistema, encarnada en sus componentes, sus relaciones entre s� y con el medio
ambiente, y los principios que rigen su dise�o y evoluci�n." TOGAF abarca pero no
se adhiere estrictamente a la norma ISO / IEC 42010:2007 terminolog�a. En TOGAF,
"arquitectura" tiene dos significados, dependiendo del contexto:
1. Una descripci�n formal de un sistema, o un plan detallado del sistema a nivel de

componente para orientar su aplicaci�n 2. La estructura de los componentes, sus
interrelaciones, y los principios y directrices que rigen su dise�o y evoluci�n en
el tiempo
TOGAF considera la empresa como un sistema y se esfuerza por lograr un equilibrio
entre la promoci�n de los conceptos y la terminolog�a de la norma ISO / IEC
42010:2007 - garantizar que el uso de los t�rminos definidos por la norma ISO / IEC
42010:2007 es compatible con la norma - y retener otra frecuencia aceptado la
terminolog�a que es familiar para la mayor�a de los lectores TOGAF. Para m�s
informaci�n sobre la terminolog�a, consulte 3. Definiciones y Parte IV , 35.
Architectural Artifacts .
2.3 �Qu� tipo de arquitectura TOGAF �El trato con?

Hay cuatro campos de arquitectura que son com�nmente aceptadas como subconjuntos de
un conjunto de arquitectura empresarial, todo lo cual TOGAF est� dise�ado para
soportar: La arquitectura de negocio define la estrategia empresarial, el
gobierno, la organizaci�n y los procesos clave del negocio. La Arquitectura de
Datos describe la estructura de los activos de datos l�gicos y f�sicos de una
organizaci�n y los recursos de gesti�n de datos.
P�gina 8 de 670

TOGOF 9.1
La Arquitectura de la aplicaci�n proporciona un modelo para las aplicaciones
individuales que se desplegar�n, sus interacciones y su relaci�n con los procesos
de negocio de la organizaci�n. La Tecnolog�a de la Arquitectura describe las
capacidades de software y hardware l�gicos que se requieren para apoyar el
despliegue de servicios de negocio, datos y aplicaciones. Esto incluye la
infraestructura de TI, middleware, redes, comunicaciones, procesamiento, normas,
etc
2.4 Arquitectura M�todo de Desarrollo

La Arquitectura M�todo de Desarrollo de TOGAF (ADM) proporciona un probado y
proceso repetible para el desarrollo de arquitecturas. La ADM incluye el
establecimiento de un marco de arquitectura, desarrollo de contenidos arquitectura,
la transici�n, y que rige la realizaci�n de arquitecturas. Todas estas actividades
se llevan a cabo dentro de un ciclo iterativo de definici�n de la arquitectura y la
realizaci�n continua que permite a las organizaciones a transformar sus empresas de
una manera controlada en respuesta a los objetivos de negocio y oportunidades.
Fases dentro de la ADM son los siguientes: La fase preliminar describe las
actividades de preparaci�n e iniciaci�n necesarios para crear una capacidad de
Arquitectura incluyendo personalizaci�n de TOGAF y definici�n de Arquitectura
Principios. Fase A: Arquitectura Visi�n describe la fase inicial de un ciclo de
desarrollo de la arquitectura. Incluye informaci�n sobre c�mo definir el alcance de
la iniciativa de desarrollo de la arquitectura, la identificaci�n de las partes
interesadas, la creaci�n de la arquitectura de la Visi�n, y obtener la aprobaci�n
para proceder con el desarrollo de la arquitectura. Fase B: Arquitectura de
Negocios describe el desarrollo de una arquitectura de negocios para apoyar el
acuerdo Architecture Vision. Fase C: Sistemas de Informaci�n Arquitecturas
describe el desarrollo de Sistemas de Informaci�n Arquitecturas para apoyar el
acuerdo Architecture Vision. Fase D: Architecture Tecnolog�a describe el
desarrollo de la arquitectura de la tecnolog�a para apoyar el acuerdo Architecture
Vision. Fase E: Oportunidades y Soluciones lleva a cabo la planificaci�n de la
implementaci�n inicial y la identificaci�n de los veh�culos de reparto para la
arquitectura se define en las fases anteriores. Fase C: planeamiento de migraci�n
aborda c�mo pasar de la l�nea de base a las arquitecturas objetivo al finalizar una
implementaci�n detallada y Plan de Migraci�n. Fase G: Gobernanza Aplicaci�n
proporciona una supervisi�n de arquitectura de la aplicaci�n. Fase H: Arquitectura
de Gesti�n del Cambio , establece los procedimientos para la gesti�n del cambio a
la nueva arquitectura.
P�gina 9 de 670

TOGOF 9.1
Gesti�n de Requisitos examina el proceso de gesti�n de requisitos de arquitectura
en todo el ADM.
2.5 Entregables, Artefactos y bloques de construcci�n

Arquitectos ejecutores del ADM producir�n una serie de resultados, como resultado
de sus esfuerzos, como los flujos de procesos, requisitos arquitect�nicos, planes
de proyectos, evaluaciones de cumplimiento de proyectos, etc El marco de contenido
TOGAF Arquitectura (ver la Parte IV , 33. Introducci�n ) proporciona una modelo
estructural para el contenido de arquitectura que permite a los principales
productos de trabajo para definir consistentemente, estructurados y presentados. La
Arquitectura del marco de contenido usa las siguientes tres categor�as para
describir el tipo de producto de trabajo de arquitectura dentro del contexto de
uso: Un entregable es un producto de trabajo que se especifica y, a su vez
revisado formalmente, de acuerdo, y firmado por las partes interesadas
contractualmente.Entregables representan la salida de los proyectos y los
resultados que se tenga en forma de documentaci�n ser�n t�picamente archivadas en
la finalizaci�n de un proyecto, o la transici�n hacia un repositorio arquitectura
como un modelo de referencia, est�ndar o instant�nea de la arquitectura del paisaje
en un punto en el tiempo. Un artefacto es un producto del trabajo arquitect�nico
que describe un aspecto de la arquitectura. Los artefactos se clasifican
generalmente como cat�logos (listas de cosas), matrices (que muestran las
relaciones entre las cosas), y diagramas (im�genes de las cosas). Los ejemplos
incluyen un cat�logo de necesidades, matriz de interacci�n de negocios, y un
diagrama de casos de uso. Un entregable arquitect�nica puede contener muchos
objetos y artefactos formar�n el contenido de la Arquitectura Repository. Un
bloque de construcci�n representa un (potencialmente reutilizable), componente de
negocio, TI, o la capacidad de la arquitectura que se puede combinar con otros
bloques de construcci�n para ofrecer arquitecturas y soluciones. Bloques de
construcci�n se pueden definir en varios niveles de detalle, dependiendo de la
etapa de desarrollo de la arquitectura se ha alcanzado. Por ejemplo, en una etapa
temprana, un bloque de construcci�n puede consistir simplemente en un nombre o una
breve descripci�n. M�s tarde, un bloque de construcci�n se puede descomponer en
varios bloques de edificios de apoyo y puede ir acompa�ada de una especificaci�n
completa. Bloques de construcci�n pueden relacionarse con "arquitecturas" o
"soluciones". o Arquitectura Bloques de Construcci�n (Abs) suelen describir la
capacidad requerida y dar forma a la especificaci�n de soluciones de Bloques de
Construcci�n (SBB). Por ejemplo, una capacidad de servicio al cliente puede ser
necesaria dentro de una empresa, con el apoyo de muchos SBB, como los procesos,
datos y software de aplicaci�n. Soluci�n Building Blocks (SBB) representan los
componentes que se utilizar�n para implementar la capacidad requerida. Por ejemplo,
una red es un bloque de construcci�n que se puede describir a trav�s de artefactos
complementarios y luego objeto de un uso para darse cuenta de las soluciones para
la empresa.
P�gina 10 de 670

TOGOF 9.1
Las relaciones entre los entregables, artefactos y bloques de construcci�n se
muestran en la Figura 2-1 .
Figura 21: Las relaciones entre los entregables, Artefactos y bloques de

construcci�n
Por ejemplo, una definici�n de documento La arquitectura es un entregable que
documenta una descripci�n de la arquitectura. Este documento contendr� una serie de
artefactos complementarios que son puntos de vista de los componentes b�sicos de
inter�s para la arquitectura. Por ejemplo, un diagrama de flujo del proceso (un
artefacto) puede ser creado para describir el proceso de gesti�n de llamadas de
destino (un bloque de construcci�n). Este artefacto puede tambi�n describir otros
bloques de construcci�n, tales como los actores involucrados en el proceso (por
ejemplo, un representante de servicios al cliente). Un ejemplo de las relaciones
entre los entregables, artefactos y bloques de construcci�n se ilustra en la Figura
2-2 .
Figura 22: Ejemplo Arquitectura de definici�n de documento P�gina 11 de 670

TOGOF 9.1
Continuum 2.6 Empresa

TOGAF incluye el concepto de Enterprise Continuum, que establece el contexto m�s
amplio de un arquitecto y explica c�mo las soluciones gen�ricas pueden ser
apalancados y especializada con el fin de apoyar las necesidades de una
organizaci�n en particular. The Enterprise Continuum es una vista del Repositorio
de Arquitectura que proporciona m�todos para clasificar la arquitectura y los
artefactos de la soluci�n a medida que evolucionan a partir de gen�ricos
Arquitecturas Fundaci�n a las arquitecturas Organizaci�n Espec�ficos. The
Enterprise Continuum comprende dos conceptos complementarios: la arquitectura y el
Continuum Continuum Solutions. Una visi�n general de la estructura y el contexto
para la empresa Continuum se muestra en la Figura 2-3 .
Figura 23: Empresa Continuum
2.7 Arquitectura Repositorio

Apoyo a la Empresa Continuum es el concepto de un Repositorio de Arquitectura que
se puede utilizar para almacenar las diferentes clases de la producci�n
arquitect�nica en diferentes niveles de abstracci�n, creado por el ADM. De esta
manera, TOGAF facilita la comprensi�n y la cooperaci�n entre las partes interesadas
y los profesionales en los diferentes niveles. Por medio del Continuum Empresa y
Arquitectura de repositorio, se anima a los arquitectos para aprovechar todos los
recursos y bienes arquitect�nicos relevantes en el desarrollo de una arquitectura
de organizaci�n espec�fica. En este contexto, el TOGAF ADM puede ser considerada
como la descripci�n de un ciclo de vida proceso que opera en m�ltiples niveles
dentro de la organizaci�n, que operan dentro de un marco global de gobernanza y la
producci�n de resultados alineados que residen en un repositorio de
P�gina 12 de 670

TOGOF 9.1
Arquitectura. The Enterprise Continuum proporciona un contexto �til para la
comprensi�n de los modelos arquitect�nicos: muestra bloques de construcci�n y sus
relaciones entre s�, y las limitaciones y requisitos en el ciclo de desarrollo de
la arquitectura. La estructura de la arquitectura TOGAF repositorio se muestra en
la Figura 2-4 .
Figura 24: TOGAF Arquitectura Estructura del repositorio
Los componentes principales dentro de un repositorio de Arquitectura son los

siguientes: La Arquitectura Metamodel describe la aplicaci�n organizativo
adaptado de un marco de arquitectura, incluyendo un metamodelo para el contenido de
la arquitectura. La Capacidad de Arquitectura define los par�metros, estructuras
y procesos que ayuden a la gobernabilidad de la arquitectura de repositorio. La
arquitectura del paisaje es la representaci�n arquitect�nica de activos desplegados
dentro de la empresa de explotaci�n en un punto determinado en el tiempo.El paisaje
es probable que exista en m�ltiples niveles de abstracci�n para adaptarse a
diferentes objetivos de la arquitectura.
P�gina 13 de 670

TOGOF 9.1
La Base de informaci�n de Normas (SIB) captura las normas que deben cumplir las
nuevas arquitecturas, que pueden incluir normas de la industria, los productos y
servicios seleccionados de proveedores o servicios compartidos ya desplegados
dentro de la organizaci�n. La Biblioteca de Referencia proporciona directrices,
plantillas, patrones y otras formas de material de referencia que se puede
aprovechar el fin de acelerar la creaci�n de nuevas arquitecturas para la empresa.
El Gobierno Log proporciona un registro de la actividad de gobierno en toda la
empresa.
2.8 Establecer y mantener una capacidad de Arquitectura Empresarial

Con el fin de llevar a cabo la actividad arquitect�nica con eficacia dentro de una
empresa, es necesario poner en marcha una capacidad de negocio apropiado para la
arquitectura, a trav�s de las estructuras de organizaci�n, funciones,
responsabilidades, habilidades y procesos. Una visi�n general de la capacidad TOGAF
Arquitectura se muestra en la Figura 2-5 .
Figura 25: Introducci�n a la arquitectura TOGAF Capability
2.9 Establecimiento de la Capacidad de Arquitectura como una
Entidad Operacional
Salvo capacidades de arquitectura creados para apoyar exclusivamente los programas
de prestaci�n de cambio, se reconoce cada vez m�s que una pr�ctica exitosa de la
arquitectura empresarial debe sentarse sobre una base operativa firme. En efecto,
una pr�ctica de la
P�gina 14 de 670

TOGOF 9.1
arquitectura empresarial debe funcionar como cualquier otra unidad operativa dentro
de un negocio; es decir, se debe tratar como un negocio. Con este fin, y por encima
de los procesos b�sicos definidos en el ADM, una pr�ctica de la arquitectura
empresarial debe establecer capacidades en las siguientes �reas: Gesti�n
Financiera Gesti�n del rendimiento (v�ase 3.52 Performance Management ) Gesti�n
de Servicios Gesti�n de Riesgos (v�ase Gesti�n de Riesgos A.75 ) Gesti�n de
Recursos Comunicaciones y Gesti�n de los interesados (v�ase 3.29 Comunicaciones y
Gesti�n de los grupos de inter�s ) Gesti�n de la Calidad Gesti�n de Proveedores
(v�ase Gesti�n de Proveedores A.82 ) Gesti�n de la Configuraci�n (ver Gesti�n de
la Configuraci�n A.15 ) Gesti�n Ambiental
Central a la idea de operar una arquitectura en curso es la ejecuci�n del bien

definido y un gobierno eficaz, por lo que toda la actividad de gran importancia
arquitect�nica es controlado y alineado en un marco �nico. Como el gobierno se ha
convertido en un requisito cada vez m�s visible de la gesti�n organizacional, la
inclusi�n de la gobernabilidad dentro de TOGAF alinea el marco de las mejores
pr�cticas de negocio actual y tambi�n asegura un nivel de visibilidad, orientaci�n
y control que apoyar� todos los requisitos y obligaciones de las partes interesadas
de la arquitectura. Los beneficios de la gobernabilidad arquitectura incluyen:
El aumento de la transparencia de la rendici�n de cuentas, y la delegaci�n inform�
de la autoridad La gesti�n del riesgo controlado Protecci�n de la base de activos
existente a trav�s de la maximizaci�n de la reutilizaci�n de los componentes
arquitect�nicos existentes Mecanismos de control proactivo, monitoreo y gesti�n
Proceso, concepto, y el componente de reutilizaci�n a trav�s de todas las unidades
de negocio de la organizaci�n La creaci�n de valor a trav�s del monitoreo,
medici�n, evaluaci�n y retroalimentaci�n
P�gina 15 de 670

TOGOF 9.1
Mayor visibilidad apoyo a los procesos internos y los requisitos de las partes
externas; en particular, el aumento de la visibilidad de la toma de decisiones en
los niveles inferiores es supervisado a un nivel adecuado dentro de la empresa de
las decisiones que pueden tener importantes consecuencias estrat�gicas para la
organizaci�n Gran valor para el accionista; en particular, la arquitectura
empresarial representa cada vez m�s la propiedad intelectual del n�cleo de la
empresa - los estudios han demostrado una correlaci�n entre el aumento de valor
para los accionistas y las empresas bien gobernadas Se integra con los procesos y
las metodolog�as existentes y complementa la funcionalidad mediante la adici�n de
capacidades de control
Mayores detalles sobre el establecimiento de una capacidad de arquitectura

empresarial se da en la parte VII , 45. Introducci�n .
2.10 El uso de TOGAF con otros marcos

Dos de los elementos clave de cualquier marco de arquitectura de la empresa son:
Una definici�n de los entregables que la actividad architecting deber�a producir
Una descripci�n del m�todo por el cual esto se debe hacer
Con algunas excepciones, la mayor�a de los marcos de arquitectura empresarial se

centran en el primero de ellos - el conjunto espec�fico de prestaciones - y son
relativamente en silencio acerca de los m�todos que se utilizar�n para generarlos
(intencionalmente as�, en algunos casos). Debido TOGAF es un marco gen�rico y
destinados a ser utilizados en una amplia variedad de entornos, proporciona un
marco de contenidos flexible y extensible que sustenta un conjunto de entregables
arquitectura gen�ricos. Como resultado, TOGAF se puede utilizar ya sea en su propio
derecho, con las prestaciones gen�ricas que en �l se describen; o bien estas
prestaciones podr�n ser sustituidos o ampliados por un conjunto m�s espec�fico,
definido en cualquier otro marco que el arquitecto considera pertinente. En todos
los casos, se espera que el arquitecto se adaptar� y se basar� en el marco TOGAF
con el fin de definir un m�todo a medida que se integra en los procesos y
estructuras de organizaci�n de la empresa. Esta arquitectura adaptaci�n puede
incluir la adopci�n de elementos de otros marcos de arquitectura, o la integraci�n
de m�todos TOGAF con otros marcos est�ndar, tales como ITIL, CMMI, COBIT, PRINCE2,
PMBOK, y MSP. Directrices para la adaptaci�n de la TOGAF ADM de tal manera se
proporcionan en la Parte II , 5.3 Adaptaci�n de la ADM . Como un marco gen�rico y
un m�todo para la arquitectura empresarial, TOGAF proporciona la capacidad y el
entorno de colaboraci�n para la integraci�n con otros marcos.Las organizaciones son
capaces de utilizar plenamente los dominios verticales de negocios, �reas
tecnol�gicas horizontales (como la seguridad o la capacidad de gesti�n), o �reas de
aplicaci�n (por ejemplo, eCommerce) para producir un marco de arquitectura
empresarial competitivo que maximiza sus oportunidades de negocio.
P�gina 16 de 670

TOGOF 9.1
3. Definiciones
A los efectos de TOGAF 9, los siguientes t�rminos y definiciones. A. Glosario de
Definiciones complementarias debe ser referido para las definiciones suplementarios
no definidos en el presente cap�tulo. Collegiate Dictionary de Merriam-Webster debe
ser referido para los t�rminos no definidos en esta secci�n o A. Glosario de
definiciones complementarias .
3.1 Abstracci�n
La t�cnica de proporcionar descripciones resumidas o generalizadas de contenido
detallado y complejo. La abstracci�n, como en "nivel de abstracci�n", tambi�n puede
significar que proporciona un enfoque de an�lisis que tiene que ver con un nivel
consistente y com�n de detalle o la abstracci�n. Abstracci�n en este sentido se
utiliza normalmente en la arquitectura para permitir un nivel consistente de la
definici�n y la comprensi�n que deben alcanzarse en cada �rea de la arquitectura
con el fin de apoyar la comunicaci�n eficaz y la toma de decisiones. Es
especialmente �til cuando se trata de arquitecturas grandes y complejas ya que
permite a cuestiones relevantes para ser identificados antes de que se intent� m�s
detalle.
3.2 Actor
Una persona, organizaci�n o sistema que tiene un papel que inicia o interact�a con
las actividades; por ejemplo, un representante de ventas que viaja a visitar a los
clientes.Actores puede ser interno o externo a la organizaci�n. En la industria
automotriz, un fabricante de equipo original se considera un actor por un
concesionario de autom�viles que interact�a con sus actividades de la cadena de
suministro.
3.3 Aplicaci�n
Un sistema inform�tico desplegado y operativo que soporte las funciones y servicios
a las empresas; por ejemplo, una n�mina. Las aplicaciones utilizan los datos y son
apoyados por m�ltiples componentes de la tecnolog�a, pero son distintos de los
componentes tecnol�gicos que apoyan la solicitud.
3.4 Arquitectura de la aplicaci�n

Una descripci�n de la estructura y la interacci�n de las aplicaciones como grupos
de capacidades que proporcionan las funciones de negocio clave y gestionar los
activos de datos. Nota: Arquitectura de la aplicaci�n se describe en la Parte II ,
11. Fase C: Arquitecturas de Sistemas de Informaci�n - Arquitectura de aplicaciones
.
3.5 Application Platform

P�gina 17 de 670

TOGOF 9.1
La colecci�n de componentes de tecnolog�a de hardware y software que proporcionan
los servicios utilizados para apoyar las aplicaciones.
3.6 Plataforma de Aplicaciones (API)

La interfaz o conjunto de funciones, entre el software de aplicaci�n y / o de la
plataforma de aplicaciones.
3.7 Estilo arquitect�nico

La combinaci�n de caracter�sticas distintivas en que se realiza o se expresa la
arquitectura.
3.8 Arquitectura
1. Una descripci�n formal de un sistema, o un plan detallado del sistema a nivel de
componente, para orientar su aplicaci�n (fuente: ISO / IEC 42010:2007). 2. La
estructura de los componentes, sus interrelaciones, y los principios y directrices
que rigen su dise�o y evoluci�n en el tiempo.
3.9 Arquitectura Bloque de construcci�n (ABB)

Un componente del modelo de arquitectura que describe un solo aspecto del modelo
general. Ver tambi�n 3.21 M�dulo .
3.10 Arquitectura Continuum

Una parte de la Empresa de Continuum. Un repositorio de elementos arquitect�nicos
con creciente detalle y especializaci�n. Este Continuum comienza con las
definiciones fundamentales como modelos de referencia, estrategias b�sicas y los
bloques de construcci�n b�sicos. A partir de ah� se extiende a las arquitecturas de
la industria y todo el camino a la arquitectura espec�fica de una organizaci�n. Ver
tambi�n 3.35 Empresa Continuum .
3.11 Arquitectura M�todo de Desarrollo (ADM)

El n�cleo de TOGAF. Un enfoque paso a paso para desarrollar y utilizar una empresa
de arquitectura. Nota: El ADM se describe en la Parte II: Arquitectura M�todo de
Desarrollo (ADM) .
P�gina 18 de 670

TOGOF 9.1
3.12 Arquitectura de dominio

. El �rea arquitect�nica est� considerando Hay cuatro �mbitos de arquitectura
dentro de TOGAF: de negocio, de datos, de aplicaciones y tecnolog�a.
3.13 Marco de Arquitectura

Una estructura conceptual utilizado para desarrollar, implementar y mantener una
arquitectura .
3.14 Arquitectura de Gobierno

La pr�ctica y la orientaci�n en la que las arquitecturas empresariales y otras
arquitecturas son gestionados y controlados a nivel de toda la empresa. Tiene que
ver con los procesos de cambio de gobierno (de dise�o) y la operaci�n de sistemas
de productos (gobernanza operativa). Ver tambi�n 3.39 Gobernabilidad .
3.15 Arquitectura del Paisaje

La representaci�n arquitect�nica de los activos en uso, o previsto, por la empresa
en determinados puntos en el tiempo.
3.16 Principios Arquitectura

Una declaraci�n de intenciones cualitativo que debe ser satisfecha por la
arquitectura. Tiene al menos un sustento racional y una medida de importancia.
Nota: Un conjunto de muestra de Arquitectura Principios se define en la Parte
III , 23. Arquitectura Principios .
3,17 Architecture Vision

Una descripci�n sucinta de la Arquitectura objetivo que describe su valor para el
negocio y los cambios en la empresa, que ser� el resultado de su implementaci�n
exitosa. Sirve
como una visi�n pol�tica y un l�mite para el desarrollo detallado de la

arquitectura.
P�gina 19 de 670

TOGOF 9.1
Nota: Fase A (Architecture Vision) se describe en la Parte II , 7. Fase A:
Architecture Vision .
3.18 Artefacto
Un producto del trabajo arquitect�nico que describe un aspecto de la arquitectura.
Ver tambi�n 3.21 M�dulo .
3.19 L�nea de Base

Una especificaci�n que ha sido revisado formalmente y acordado, que a partir de
entonces, sirve como la base para un mayor desarrollo o el cambio y que s�lo se
puede cambiar a trav�s de los procedimientos de control de cambios formales o de un
tipo de procedimiento como la gesti�n de la configuraci�n.
3.20 Flujo de Informaci�n sin fronteras

1. Una marca registrada de The Open Group. 2. Una representaci�n abreviada de
"acceso a la informaci�n integrada para apoyar mejoras
en los procesos de negocio", que representan un estado deseado de la
infraestructura de una empresa espec�fica a las necesidades de negocio de la
organizaci�n.
Una infraestructura que ofrece sin fronteras Flujo de Informaci�n cuenta con
componentes est�ndares abiertos que ofrecen servicios en la empresa extendida que
de un cliente: Nota: La necesidad de flujo de informaci�n sin fronteras se
describe en la Parte VI , 44. Integrado de Informaci�n de Referencia
Infraestructura Modelo . Combine m�ltiples fuentes de informaci�n Segura entregar
la informaci�n cuando y donde sea necesario, en el contexto adecuado para las
personas o sistemas que utilicen dicha informaci�n.
3.21 M�dulo
Representa un (potencialmente reutilizable), componente de negocio, TI, o la
capacidad de la arquitectura que se puede combinar con otros bloques de
construcci�n para ofrecer arquitecturas y soluciones.
P�gina 20 de 670

TOGOF 9.1
Bloques de construcci�n se pueden definir en varios niveles de detalle, dependiendo
de la etapa de desarrollo de la arquitectura se ha alcanzado. Por ejemplo, en una
etapa temprana, un bloque de construcci�n puede consistir simplemente en un nombre
o una breve descripci�n. M�s tarde, un bloque de construcci�n se puede descomponer
en varios bloques de edificios de apoyo y puede ir acompa�ada de una especificaci�n
completa. Bloques de construcci�n pueden relacionarse con "arquitecturas" o
"soluciones". Ver tambi�n 3.18 Artefacto . Nota: Bloques de construcci�n se
describen en la Parte IV , 37. Building Blocks .
3.22 Arquitectura de Negocios

Una descripci�n de la estructura y la interacci�n entre la estrategia de negocio,
necesita organizaci�n, funciones, procesos de negocio y la informaci�n. Nota:
Arquitectura de Negocios se describe en la Parte II , 8. Fase B: Configuraci�n de
asunto .
3.23 Funci�n de Empresas

Proporciona capacidades de negocio estrechamente alineadas a una organizaci�n, pero
no necesariamente gobernadas de forma expl�cita por la organizaci�n.
3.24 Gobierno de Empresas

Preocupado por asegurar que los procesos de negocio y las pol�ticas (y su
operaci�n) entregar los resultados del negocio y se adhieran a la regulaci�n
empresarial relevante.
3.25 Servicios de Negocio

Soporta capacidades de negocio a trav�s de una interfaz definida expl�citamente y
se rige expl�citamente por una organizaci�n.
3.26 Capacidad
Una habilidad que una organizaci�n, persona o sistema posee. Las capacidades se
expresan normalmente en t�rminos generales y de alto nivel y por lo general
requieren una combinaci�n de organizaci�n, personas, procesos y tecnolog�a para
alcanzar. Por ejemplo, marketing, contacto con el cliente o telemarketing.
3.27 Capacidad de Arquitectura

Una descripci�n muy detallada de la propuesta de arquitectura para darse cuenta de
una soluci�n particular o una soluci�n de aspecto.
P�gina 21 de 670

TOGOF 9.1
Incremento de 3,28 Capacidad

Una porci�n discreta de una arquitectura de capacidad que ofrece un valor
espec�fico. Cuando todos los incrementos se han completado, la capacidad ha sido
realizada.
3.29 Comunicaciones y Gesti�n de las partes interesadas

La gesti�n de las necesidades de las partes interesadas de la pr�ctica de la
arquitectura empresarial. Tambi�n gestiona la ejecuci�n de la comunicaci�n entre la
pr�ctica y los grupos de inter�s y la pr�ctica y los consumidores de sus servicios.
Nota: Arquitectura gesti�n de los interesados se describe en el 24. Gesti�n de las
partes interesadas .
3.30 Las preocupaciones

Los intereses dominantes que son de crucial importancia para las partes interesadas
en un sistema, y determinan la aceptabilidad del sistema. Las preocupaciones pueden
referirse a cualquier aspecto de funcionamiento, el desarrollo o el funcionamiento
del sistema, incluyendo consideraciones tales como el rendimiento, la fiabilidad,
la seguridad, la distribuci�n, y capacidad de evoluci�n. Ver tambi�n 3.68
Stakeholder .
3.31 Restricci�n
Un factor externo que impide que una organizaci�n de la b�squeda de enfoques
particulares para cumplir sus objetivos. Por ejemplo, los datos del cliente no est�
armonizada dentro de la organizaci�n, regional o nacional, lo que limita la
capacidad de la organizaci�n para ofrecer un servicio al cliente eficaz.
3.32 Arquitectura de Datos

Una descripci�n de la estructura y la interacci�n de los principales tipos de la
empresa y las fuentes de datos, los activos de datos l�gicos, los activos f�sicos
de datos y recursos de gesti�n de datos. Nota: Arquitectura de datos se describe
en la Parte II , 10. Fase C: Arquitecturas de Sistemas de Informaci�n -
Arquitectura de Datos .
3.33 Disponible
Un producto de la obra arquitect�nica que se especifica y, a su vez revisado
formalmente, de acuerdo, y firmado por las partes interesadas contractualmente.
Entregables representa la salida de los proyectos y los resultados que se tenga en
forma de documentaci�n normalmente se
P�gina 22 de 670

TOGOF 9.1
archiva en la finalizaci�n de un proyecto, o de transici�n a un repositorio de
arquitectura como un modelo de referencia, est�ndar o instant�nea de la
arquitectura del paisaje en un punto en el tiempo.
3.34 Empresa
El nivel m�s alto (por lo general) de la descripci�n de una organizaci�n y por lo
general cubre todas las misiones y funciones. Una empresa a menudo abarcar varias
organizaciones.
Continuum 3.35 Empresa
Un mecanismo �til para la clasificaci�n de la arquitectura y la soluci�n
artefactos, tanto internos como externos a la arquitectura de repositorio, a medida
que evolucionan a partir de gen�ricos Arquitecturas Fundaci�n a las arquitecturas
Organizaci�n espec�ficas de categorizaci�n. Ver tambi�n 3.10 Arquitectura Continuum
y 3.67 Soluciones Continuum .
3.36 Fundaci�n Arquitectura

Bloques gen�ricos de construcci�n, sus interrelaciones con otros bloques de
construcci�n, junto con los principios y directrices que proporcionan una base
sobre la que las arquitecturas m�s espec�ficas se pueden construir.
3.37 Marco
Una estructura para el contenido o proceso que se puede utilizar como una
herramienta para estructurar el pensamiento, asegurando la consistencia e
integridad.
3.38 Gap
Una declaraci�n de la diferencia entre los dos estados. Utilizado en el contexto
del an�lisis de las lagunas, donde se identifica la diferencia entre la l�nea de
base y Arquitectura Target. Nota: El an�lisis de brechas se describe en la Parte
III , 27. An�lisis Gap .
3.39 Gobierno
La disciplina de controlar, gestionar y dirigir un negocio (o IS / paisaje IT) para
entregar los resultados de negocio requiere. Ver tambi�n 3.14 Arquitectura
Gobernabilidad , Gobernanza 3.24 Negocios y A.60 Gobierno Operacional en A.
Glosario de definiciones complementarias .
P�gina 23 de 670

TOGOF 9.1
3.40 Informaci�n
Cualquier comunicaci�n o representaci�n de hechos, datos u opiniones, en cualquier
medio o forma, incluyendo textual, num�rico, gr�fico, cartogr�fico, la narrativa, o
formas audiovisuales.
3,41 Tecnolog�a de la Informaci�n (IT)

1. La gesti�n del ciclo de vida de la informaci�n y la tecnolog�a relacionada
utilizado por una organizaci�n. 2. Un t�rmino general que incluye todas o algunas
de las materias relacionadas con la
industria de la computaci�n, tales como la Continuidad del Negocio, Negocio
Interfaz IT, Business Process Modeling y Gesti�n, Comunicaci�n, Cumplimiento y
Legislaci�n, Inform�tica, Gesti�n de Contenidos, Hardware, Gesti�n de la
Informaci�n, Internet , Offshoring, Redes, Programaci�n y Software, Asuntos
Profesionales, Gesti�n de Proyectos, Seguridad, Est�ndares, almacenamiento, voz y
comunicaciones de datos. Varios pa�ses e industrias emplean otros t�rminos paraguas
para describir esta misma colecci�n. encargada de aprovisionamiento de algunos o
todos los dominios descritos en (2) anteriormente.
3. Un t�rmino com�nmente asignada a un departamento dentro de una organizaci�n
4. Los nombres alternativos com�nmente adoptadas incluyen Servicios de Informaci�n,

Gesti�n de la Informaci�n, et al.
3.42 Interoperabilidad
1. La capacidad de compartir informaci�n y servicios. 2. La capacidad de dos o m�s
sistemas o componentes para intercambiar y utilizar la informaci�n. 3. La
capacidad de los sistemas para ofrecer y recibir servicios de otros sistemas y para
utilizar los servicios de manera intercambiada para que puedan funcionar juntos de
manera efectiva.
3.43 L�gico
Una definici�n independiente de la implementaci�n de la arquitectura, a menudo
agrupar entidades f�sicas relacionadas en funci�n de su finalidad y estructura. Por
ejemplo, los productos de m�ltiples proveedores de software de infraestructura
pueden ser agrupados de forma l�gica como plataformas de servidor de aplicaciones
Java.
P�gina 24 de 670

TOGOF 9.1
3.44 Metadatos
Los datos acerca de los datos, de cualquier tipo en cualquier medios de
comunicaci�n, que describe las caracter�sticas de una entidad.
3.45 Metamodel
Un modelo que describe c�mo y con qu� la arquitectura se describir� de una manera
estructurada.
3.46 M�todo
Un enfoque repetible definida para hacer frente a un tipo particular de problema.
Ver tambi�n 3.47 Metodolog�a .
3.47 Metodolog�a
A definido, serie repetible de medidas para abordar un determinado tipo de
problema, que por lo general se centra en un proceso definido, pero tambi�n puede
incluir la definici�n de los contenidos. Ver tambi�n M�todo 3,46 .
3.48 Modelo
Una representaci�n de un tema de inter�s. Un modelo proporciona una escala m�s
peque�a y simplificada, y / o representaci�n abstracta de la materia. Un modelo se
construye como un "medio para un fin". En el contexto de la arquitectura de la
empresa, el tema es un todo o parte de la empresa y el final es la capacidad de
construir "vistas" que aborden las preocupaciones de los grupos de inter�s
particulares; es decir, sus "puntos de vista" en relaci�n con el tema en cuesti�n.
Ver tambi�n 3.68 Stakeholder , 3.75 Vista , y 3.76 Viewpoint .
3.49 Modelado
Una t�cnica a trav�s de la construcci�n de modelos que permite a un sujeto para ser
representados en una forma que permite el razonamiento, perspicacia y claridad en
cuanto a la esencia de la materia.
3.50 Objetivo
Un hito de tiempo limitado para que una organizaci�n utiliza para demostrar el
progreso hacia una meta; por ejemplo, "Aumentar la utilizaci�n de la capacidad en
un 30% a finales de 2009 para apoyar el aumento previsto en el mercado de la cuota
".
P�gina 25 de 670

TOGOF 9.1
3.51 Patrones
Una t�cnica para poner bloques de construcci�n en su contexto; ., por ejemplo, para
describir una soluci�n reutilizable a un problema de construcci�n bloques son lo
que usted utiliza: patrones pueden decir c�mo usarlos, cu�ndo, por qu�, y qu�
ventajas y desventajas que tiene que hacer con ello. Ver tambi�n 3.21 M�dulo .
3.52 Gesti�n del Rendimiento

El seguimiento, control y reporte de la ejecuci�n pr�ctica de la arquitectura
empresarial. relacionados tambi�n con la mejora continua.
3.53 F�sica
Una descripci�n de una entidad del mundo real. Elementos f�sicos en una empresa de
arquitectura todav�a puede abstraerse considerablemente de Arquitectura de la
soluci�n, dise�o, o puntos de vista de implementaci�n.
3.54 Plataforma
Una combinaci�n de productos de infraestructura de tecnolog�a y componentes que
establece que los requisitos para albergar software de aplicaci�n.
3.55 Plataforma de Servicios

Una capacidad t�cnica que se requiere para proporcionar la infraestructura que
permite que apoya la entrega de aplicaciones.
3.56 Principio 3.57 Modelo de Referencia (RM)

Un modelo de referencia es un marco abstracto para comprender las relaciones
significativas entre las entidades de [un] medio ambiente y para el desarrollo de
los est�ndares o especificaciones que apoyan ese ambiente consistentes. Un modelo
de referencia se basa en un peque�o n�mero de conceptos unificadores y puede ser
utilizado como base para la educaci�n y las normas que explican a un no
especialista. Un modelo de referencia no est� directamente ligada a las normas,
tecnolog�as u otros detalles de implementaci�n concretos, pero s� busca
proporcionar sem�ntica com�n que se pueden utilizar de forma inequ�voca a trav�s y
entre diferentes implementaciones.
P�gina 26 de 670

TOGOF 9.1
3.58 Repositorio
Un sistema que gestiona todos los datos de una empresa, incluidos los modelos de
proceso de datos y la informaci�n de la empresa y otra. Por lo tanto, los datos de
un repositorio es mucho m�s extensa que la de un diccionario de datos, que por lo
general s�lo define los datos que componen una base de datos .
3.59 Requisito
Una declaraci�n de la necesidad que debe ser satisfecha por una arquitectura o
paquete de trabajo en particular.
3.60 Hoja de Ruta

Un plan abstracto para el cambio de negocios o tecnolog�a, por lo general operan a
trav�s de m�ltiples disciplinas largo de varios a�os. Normalmente se utiliza en las
frases Technology Roadmap, Arquitectura Roadmap, etc
3.61 Papel
1. La funci�n habitual o esperado de un actor, o la parte que alguien o algo juega
en una acci�n o evento en particular. Un actor puede tener una serie de funciones.
2. La parte de un individuo desempe�a en una organizaci�n y la contribuci�n que
hacen a trav�s de la aplicaci�n de sus habilidades, conocimientos, experiencia y
habilidades.
3.62 Segmento de Arquitectura

Una descripci�n detallada y formal de las �reas dentro de una empresa, que se
utiliza a nivel de programa o de una cartera de organizar y alinear la actividad de
cambio.
3.63 Servicio de Orientaci�n

Una manera de pensar en t�rminos de servicios y el desarrollo basado en el servicio
y los resultados de los servicios.
Arquitectura Orientada a Servicios 3.64 (SOA)

. Un estilo arquitect�nico que apoya la orientaci�n al servicio Tiene las
siguientes caracter�sticas distintivas:
P�gina 27 de 670

TOGOF 9.1
Se basa en el dise�o de los servicios - que reflejan las actividades
empresariales del mundo real - que comprenden la empresa (o entre empresas) los
procesos de negocio. Representaci�n del Servicio utiliza descripciones
empresariales para proporcionar el contexto (es decir, los procesos de negocio,
meta, regla, pol�tica, interfaz de servicio, y el componente de servicio) e
implementa servicios utilizando la orquestaci�n de servicios. Coloca los
requisitos �nicos de la infraestructura -, se recomienda que las implementaciones
utilizan est�ndares abiertos para darse cuenta de la interoperabilidad y la
transparencia de ubicaci�n. Las implementaciones son favorables al medio
espec�fico - se ven limitados o habilitadas por el contexto y deben ser descritas
dentro de ese contexto. Se requiere un gobierno fuerte de la representaci�n de
servicios y la ejecuci�n. Se requiere de una "prueba de fuego", lo que determina
un "buen servicio".
3.65 Arquitectura de la soluci�n

Una descripci�n de un discreto y se centr� operaci�n o actividad mercantil y c�mo
SI / TI soporta esa operaci�n. Una soluci�n de arquitectura t�picamente se aplica a
un solo proyecto o proyecto de liberaci�n, la asistencia en la traducci�n de los
requisitos en una soluci�n visi�n, negocio de alto nivel y / o especificaciones de
los sistemas de TI, y una cartera de competencias de ejecuci�n.
3.66 Soluci�n M�dulo (SBB)

Una soluci�n candidata que se ajusta a la especificaci�n de una Arquitectura Bloque
de construcci�n (ABB).
3.67 Soluciones Continuum

Una parte del Continuum Enterprise. Un repositorio de soluciones reutilizables para
los futuros esfuerzos de aplicaci�n. Contiene implementaciones de las definiciones
correspondientes en la Arquitectura Continuum.
3.68 Stakeholder
Un individuo, equipo u organizaci�n (o clases de los mismos) con intereses en, o
preocupaciones en relaci�n con el resultado de la arquitectura. Diferentes actores
con diferentes roles tienen diferentes preocupaciones.
3.69 Normas de Informaci�n de Base (SIB)
Una base de datos de normas que se pueden utilizar para definir los servicios
particulares y otros componentes de una arquitectura de organizaci�n espec�fica.
P�gina 28 de 670

TOGOF 9.1
3.70 Arquitectura Estrat�gica

Un resumen descripci�n formal de la empresa, proporcionando un marco de
organizaci�n de la actividad operativa y el cambio, y un nivel ejecutivo, visi�n a
largo plazo para el ajuste de la direcci�n.
3.71 Arquitectura Target

La descripci�n de un estado futuro de la arquitectura est� siendo desarrollado para
una organizaci�n. puede haber varios estados futuros desarrollados como hoja de
ruta para mostrar la evoluci�n de la arquitectura a un estado objetivo.
3.72 Taxonom�a de Arquitectura Vistas

El conjunto organizado de todas las opiniones pertinentes para una arquitectura.
3.73 Tecnolog�a de Arquitectura

Una descripci�n de la estructura y la interacci�n de los servicios de la
plataforma, y los componentes l�gicos y f�sicos de la tecnolog�a. Nota: Tecnolog�a
de la Arquitectura se describe en la Parte II , 12. Fase D: Architecture Tecnolog�a
.
3.74 Transici�n Arquitectura

Una descripci�n formal de un estado de la arquitectura en un punto de vista
arquitect�nico significativa en el tiempo. Uno o m�s arquitecturas de transici�n
puede ser usado para describir la progresi�n en el tiempo desde la l�nea base hasta
la arquitectura destino.
3.75 Ver
La representaci�n de un conjunto relacionado de preocupaciones. Un punto de vista
es lo que se ve desde un punto de vista. Una vista de la arquitectura puede ser
representado por un modelo de demostrar a las partes interesadas de sus �reas de
inter�s en la arquitectura. Un punto de vista no tiene por qu� ser visual o gr�fica
en la naturaleza.
3.76 Punto de vista

Una definici�n de la perspectiva desde la cual se tiene una vista. Es una
especificaci�n de los convenios para la construcci�n y el uso de un punto de vista
(a menudo por medio de un esquema o plantilla adecuada). Un punto de vista es lo
que se ve; un punto de vista es donde se busca desde - el punto de vista o
perspectiva que determina lo que ves.
3.77 Paquete de Trabajo

P�gina 29 de 670

TOGOF 9.1
Un conjunto de acciones identificadas para alcanzar uno o m�s objetivos para el
negocio. Un paquete de trabajo puede ser una parte de un proyecto, un proyecto
completo, o un programa.
P�gina 30 de 670

TOGOF 9.1
4. Notas de la versi�n
A los efectos de TOGAF 9, las notas de la versi�n se proporcionan en este cap�tulo
se aplican.
4.1 �Qu� hay de nuevo en TOGAF 9?

En esta secci�n se ofrece un panorama general de las principales caracter�sticas
nuevas en TOGAF 9.
Estructura Modular
Uno de los focos de TOGAF 9 desarrollo ha sido asegurar que el contenido de la

especificaci�n se ha estructurado de forma modular. La estructura modular de siete
partes de TOGAF permite que los conceptos en cada parte para ser desarrolladas con
impactos limitados en otras partes. El contenido que estaba contenida dentro de la
base de recursos TOGAF 8.1.1 est� catalogado y trasladado a las partes que tienen
un prop�sito definido (por oposici�n a los "recursos" gen�ricas). La estructura
modular de TOGAF se pretende contribuir a una mayor facilidad de uso, ya que cada
parte tiene un prop�sito definido y puede leerse de manera aislada como un stand-
alone conjunto de directrices. Se espera que la estructura modular para apoyar la
adopci�n gradual de la especificaci�n TOGAF. Finalmente, la estructura modular
soporta gesti�n de versiones m�s sofisticadas de la especificaci�n TOGAF. En el
futuro, las partes individuales pueden evolucionar a diferentes velocidades y la
estructura actual especificaci�n tiene por objeto permitir cambios en un �rea que
se llevan a cabo con un impacto limitado en toda la especificaci�n.
Marco de Contenido
Una importante adici�n de nuevos contenidos a la especificaci�n TOGAF es el marco

de contenido. El marco de contenido TOGAF proporciona un modelo detallado de los
productos de trabajo de arquitectura, incluyendo entregables, artefactos dentro de
los entregables, y los bloques de construcci�n arquitect�nicos que representan los
artefactos. La intenci�n de incluir un marco de contenidos dentro de TOGAF es
impulsar una mayor coherencia en las salidas que se crean cuando se sigue un m�todo
de desarrollo de la arquitectura (ADM). La ventaja de incluir un marco de contenido
se aplica a un n�mero de niveles. En primer lugar, dentro de una sola iniciativa de
desarrollo de la arquitectura del marco de contenido proporciona una lista completa
de los productos de arquitectura que podr�a crearse y en consecuencia reducir el
riesgo de brechas dentro de la arquitectura final conjunto entregable. La segunda
ventaja importante de la inclusi�n de un marco de contenido se aplica cuando se
trata de integrar los productos de trabajo de arquitectura en una empresa. El marco
de contenido est� destinado a ser adaptado y adoptado por una empresa con el fin de
ordenar conceptos est�ndares arquitect�nicos, t�rminos y entregables. Si todas las
iniciativas de arquitectura utilizan los mismos modelos de contenido, sus salidas
se pueden combinar con mayor facilidad que en situaciones en que cada arquitecto
utiliza un enfoque completamente diferente. Por �ltimo, un beneficio importante de
la inclusi�n de un marco contenido dentro de TOGAF es que proporciona (por primera
vez) un est�ndar abierto detallada de c�mo se deben describir
P�gina 31 de 670

TOGOF 9.1
arquitecturas. La existencia de esta norma permite a los proveedores de
herramientas, proveedores de productos y proveedores de servicios para que adopten
formas consistentes de trabajo, que a su vez se traducir� en una mayor coherencia
entre las herramientas de arquitectura, una mejor interoperabilidad de
herramientas, arquitecturas de referencia m�s coherentes y mejor comparabilidad
entre las arquitecturas de referencia relacionados .
Orientaci�n extendido en adopci�n TOGAF dentro de una empresa
Dentro de las organizaciones m�s grandes, la pr�ctica de la arquitectura de la

empresa requiere de una serie de personas y equipos que trabajan juntos en muchas
arquitecturas . Aunque cada arquitectura abordar� un problema espec�fico, en un
ideal arquitecturas situaci�n se puede considerar como un grupo con el fin de
desarrollar una visi�n integrada global de c�mo la empresa est� cambiando. Esta
versi�n de TOGAF cuenta con un amplio conjunto de conceptos y directrices para
apoyar el establecimiento de una jerarqu�a integrada de las arquitecturas est�n
siendo desarrollados por los equipos que operan dentro de un modelo de gobernanza
arquitect�nico general. En particular, se presentan los siguientes conceptos:
Particionamiento : Con el fin de desarrollar arquitecturas que tienen niveles
manejables de coste y la complejidad, es necesario particionar la empresa en las
arquitecturas espec�ficas. TOGAF discute el concepto de la separaci�n y ofrece una
variedad de t�cnicas y consideraciones de c�mo particionar las diversas
arquitecturas dentro de una empresa. Arquitectura Repositorio : TOGAF proporciona
un modelo de informaci�n l�gica para un repositorio Arquitectura, que puede ser
utilizado como un almac�n integrado para todas las salidas creados por la ejecuci�n
de la ADM. Marco Capacidad : Esta versi�n de TOGAF ofrece una definici�n m�s
estructurado a la organizaci�n, competencias, funciones y responsabilidades que se
requieren para operar una capacidad efectiva de arquitectura empresarial. Los
nuevos materiales TOGAF tambi�n proporcionan orientaci�n sobre un proceso que se
puede seguir para identificar y establecer una capacidad Arquitectura apropiado.
Consideraci�n expl�cita de estilos arquitect�nicos, incluyendo SOA y Arquitectura

de Seguridad
La nueva parte III: Directrices y T�cnicas ADM re�ne un conjunto de materiales que
muestran con m�s detalle c�mo el ADM se puede aplicar a las situaciones espec�ficas
de apoyo. Las nuevas pautas discuten: Los diversos usos de iteraci�n que son
posibles dentro de la ADM y cuando cada t�cnica se deben aplicar Los v�nculos
entre el TOGAF ADM y Arquitectura Orientada a Servicios (SOA) Las consideraciones
espec�ficas que se requieren para hacer frente a la arquitectura de seguridad
dentro de la ADM
P�gina 32 de 670

TOGOF 9.1
Los diversos tipos de desarrollo de la arquitectura necesarios dentro de una
empresa y c�mo se relacionan entre s�
Detalle adicional ADM
Esta versi�n de la especificaci�n TOGAF incluye informaci�n m�s detallada apoyo a

la ejecuci�n de la ADM. �reas particulares de mejora son: La fase preliminar, que
cuenta con una gu�a extendida en el establecimiento de un marco de arquitectura de
la empresa y la planificaci�n para el desarrollo de la arquitectura. La Fase
Preliminar extendido tambi�n ofrece consejos para la definici�n de un modelo de
gobernanza para la realizaci�n arquitectura beneficio y tambi�n analiza la
vinculaci�n entre TOGAF y otros marcos de gesti�n. Las Oportunidades y fase
Soluciones y planeamiento de migraci�n de fase, que cuentan con un m�todo m�s
detallado y s�lido para la definici�n y planificaci�n de transformaci�n de la
empresa, con base en los principios de la planificaci�n basada en la capacidad.
4.1.1 Los cambios aplicados en esta edici�n

Esta edici�n de TOGAF 9 incluye un conjunto de actualizaciones de mantenimiento en
base a los comentarios recibidos en la publicaci�n de 2009. . Un documento
detallado por separado de los cambios est� disponible como TOGAF 9 Rectificaci�n
T�cnica N � 1 (Documento U112) se incluye a continuaci�n una lista resumida de los
cambios: Se han eliminado las definiciones de los t�rminos en que el uso por
TOGAF no es distintivo de la definici�n de diccionario com�n. El uso de los
t�rminos "aplicaci�n" contra "el sistema" se han revisado y hecho consistente. Las
descripciones de la Fase E y F se han modificado para que coincida con el nivel de
detalle en otras fases. Los usos de la terminolog�a para la transici�n
Arquitectura / Roadmap Estrategia / Implementaci�n han aclarado y hecho
consistente. Los conceptos de niveles / iteraciones / particiones han aclarado y
hecho consistente. Esto incluye una reorganizaci�n de material en la parte III ,
19. La aplicaci�n de la iteraci�n de la ADM y 20. La aplicaci�n de la ADM a trav�s
de la arquitectura del paisaje , y la Parte V , 40. Arquitectura de
particionamiento . Los "Objetivos" secciones de las fases se han revisado a fin de
centrarse en los objetivos reales en lugar de las t�cnicas o una lista de pasos.
Los artefactos posibles (puntos de vista) para cada fase se muestran ahora en la
descripci�n de esa fase, no s�lo en la Parte IV , 35. Architectural Artifacts .
Los t�rminos "artefacto" en comparaci�n con "punto de vista" se han aclarado y
hecho consistente. Esto incluye una reestructuraci�n de la Parte IV ,
35.Architectural Artifacts . El cap�tulo SOA ( Parte III , 22. Uso de TOGAF para
definir y Gobierno SOAs ) ha sido actualizado para describir la �ltima salida de
grupo de trabajo de SOA.
P�gina 33 de 670

TOGOF 9.1
Texto introductorio adicional sobre los estilos arquitect�nicos se ha
a�adido en la Parte III , 18. Introducci�n . Peque�os cambios se han hecho para el
cap�tulo de la arquitectura de seguridad ( Parte III , 21. Arquitectura de
Seguridad y el ADM ) para mantener la coherencia con el ADM. Se han realizado
correcciones a metamodelo diagramas. Las correcciones se han aplicado a los
aspectos del metamodelo. En el ejemplo de bloques de construcci�n se ha eliminado.
La categorizaci�n de modelo de documento se ha eliminado. Duplicar texto en varios
lugares ha sido reemplazado con una referencia adecuada: o o An�lisis de brechas
en las fases B, C y D ahora referencia a la Parte III , 27. An�lisis Gap . Gesti�n
de Requisitos en varias fases ahora hace referencia la parte II , 17.2.2 Requisitos
para el Desarrollo en la fase de gesti�n de requisitos.
Algunos de los artefactos han sido renombrados para reflejar mejor su uso: o o o o
o o o o Matriz System / Data se convierte en matriz de aplicaciones / datos
Diagrama de clases ha sido reemplazado con el diagrama conceptual de datos y el
diagrama de l�gica de datos Matriz del sistema / Organizaci�n convierte matriz
Aplicaci�n / Organizaci�n Matriz de Papel / System convierte matriz Papel /
Aplicaci�n Matriz de Sistema / Funci�n convierte en matriz de Aplicaci�n / Funci�n
Diagrama Realizaci�n de proceso / sistema convierte diagrama Realizaci�n de proceso
/ aplicaci�n Diagrama del sistema de casos de uso se convierte en el diagrama de
casos de uso de aplicaciones Matriz del sistema / tecnolog�a se convierte en
matriz de Aplicaci�n / Tecnolog�a
La descripci�n de la arquitectura de principios ahora los divide en dos �nicos
tipos Enterprise y Arquitectura -, mientras que antes de que llamaran a los
Principios de TI por separado. IT Principios ahora son vistos como s�lo una parte
de los Principios Empresariales. El Stakeholder Mapa incorporado en el cap�tulo de
gesti�n de los interesados ( Parte III , 24. Gesti�n de los grupos de inter�s ) que
ahora se hace referencia expl�cita a modo de ejemplo, la tabla se ha puesto de
relieve para referirse a las preocupaciones de las partes interesadas, y la lista
de objetos para cada grupo de inter�s actualizada.
P�gina 34 de 670

TOGOF 9.1
El cap�tulo Escenarios empresariales ( Parte III , 26. Escenarios empresariales y
objetivos de la empresa ) se ha renombrado a escenarios empresariales y objetivos
de la empresa para reflejar mejor el contenido del cap�tulo. La relaci�n de la
Enterprise Repository al Repositorio Arquitectura se aclara en la Parte V , 41.
Arquitectura Repositorio . Los criterios de evaluaci�n y directrices se han
eliminado de la Parte V , 42. Herramientas para el desarrollo de la arquitectura .
El cap�tulo sobre la Arquitectura de Madurez Modelos ( Parte VII , 51. Arquitectura
de Madurez Modelos ) ha sido revisada su redacci�n para mantener la coherencia y la
claridad.
4.2 Los beneficios de TOGAF 9

TOGAF 9 proporciona un conjunto amplio de revisiones de la especificaci�n TOGAF.
Cuando se combinan, estas ediciones buscan lograr un conjunto de objetivos para
mejorar el valor del marco TOGAF.
Mayor usabilidad
Una serie de mejoras dentro de TOGAF 9 apoyo mayor facilidad de uso de la

especificaci�n general. En primer lugar, la estructura modular de la especificaci�n
hace que sea m�s f�cil para un arquitecto para que considere la posibilidad de un
aspecto espec�fico de la Capacidad de Arquitectura. En todas las �reas, la
especificaci�n pretende agregar el detalle y la claridad por encima y m�s all� de
las versiones anteriores TOGAF.
M�s de enfoque sobre el cambio de empresa Hol�stica
TOGAF tiene una s�lida historia en la arquitectura de TI, teniendo en cuenta las
formas en que se puede apoyar el cambio de empresa. Sin embargo, como TOGAF ha
crecido en profundidad y madurez se ha convertido en un marco para la gesti�n de
todo el espectro de los cambios necesarios para transformar una empresa hacia un
modelo operativo de destino. TOGAF 9 contin�a esta evoluci�n e incorpora una
perspectiva m�s amplia de cambio que permite a la arquitectura empresarial que se
utiliza para especificar la transformaci�n a trav�s de los dominios de negocio,
datos, aplicaciones y tecnolog�a.
M�s Consistencia de salida
Las versiones anteriores de TOGAF centran en proporcionar un proceso coherente para

el desarrollo de arquitecturas. TOGAF 9 incluye una consideraci�n muy mejorada de
los productos arquitect�nicos de trabajo para asegurar que un proceso coherente se
utiliza para producir salidas coherentes. El Marco de Arquitectura de contenidos
proporciona un modelo detallado de las salidas que se creen por el ADM. Adem�s, las
secciones de la empresa Continuum, Arquitectura de particiones, y arquitectura de
repositorio proporcionan orientaci�n detallada sobre c�mo entregables
arquitect�nicos pueden estar al alcance, rigen, e integradas.
P�gina 35 de 670

TOGOF 9.1
4.3 Mapeo de la Estructura TOGAF 8.1.1 a TOGAF 9

A continuaci�n se enumeran las partes de la especificaci�n TOGAF 8. Para cada
parte, se da una descripci�n para explicar donde el contenido TOGAF 8 se puede
encontrar dentro de la especificaci�n actual.
Parte I: Introducci�n
La parte de la especificaci�n Introducci�n TOGAF 8.1.1 se ha utilizado como base

para la creaci�n de la Parte I: Introducci�n . en TOGAF 9 La introducci�n de TOGAF
9 refleja el contenido de TOGAF 9 m�s que el contenido de TOGAF 8.1.1, y tambi�n
cuenta con una serie de mejoras para mejorar la accesibilidad.
Parte II: Arquitectura M�todo de Desarrollo
La esencia de la TOGAF 8.1.1 ADM se ha conservado en TOGAF 9. Parte II:

Arquitectura M�todo de Desarrollo (ADM) dentro de TOGAF 9 est� estructurado de
manera similar a la Parte II del documento TOGAF 8.1.1. Entradas y salidas
(Cap�tulo 16 de TOGAF 8.1.1) Fase TOGAF ADM se han trasladado desde la secci�n de
ADM de TOGAF 8.1.1 a la Parte IV: Marco de Arquitectura de contenido de TOGAF 9.
TOGAF 9 ADM cuenta con contenido adicional en la mayor�a de las fases de ADM, que
en su mayor parte a�ade m�s detalle y aclaraci�n para el mismo enfoque que se
describe en TOGAF 8.1.1.
Parte III: Empresa Continuum
El TOGAF 8.1.1 Empresa Continuum ha visto un importante grado de cambio. El

concepto de Enterprise Continuum es retenido dentro Parte V: Empresa Continuum y
Herramientas . El Modelo de Referencia T�cnica TOGAF y Integrado de Informaci�n
Infraestructura Modelo de referencia se extraen y se colocan dentro de la Parte VI:
Modelos de referencia TOGAF en TOGAF 9. TOGAF 9 a�ade nuevos materiales que
describen una aproximaci�n a la arquitectura de partici�n y tambi�n proporciona un
modelo estructurado de un Repositorio de Arquitectura. Estos conceptos apoyan y
elaboran en la intenci�n original de la empresa Continuum. TOGAF 9 elimina la base
de informaci�n de las Normas de la especificaci�n TOGAF. Sin embargo, un ejemplo
SIB permanece en el sitio web Open Group (www.opengroup.org ). El concepto de una
Base de Informaci�n de Normas es importante dentro de TOGAF, pero la amplitud y la
velocidad de los cambios de las normas arquitect�nicas relevantes significa que no
es pr�ctico mantener una colecci�n actual y relevante de las normas dentro de una
especificaci�n como TOGAF.
Parte IV: Base de Recursos
La base de recursos no est� incluido en esta versi�n de TOGAF. Algunos elementos de

la base de recursos han quedado en desuso a partir de la especificaci�n TOGAF, pero
todav�a estar� disponible en forma de Libro Blanco. Otros elementos de la base de
recursos se han trasladado a otras zonas de la especificaci�n.
P�gina 36 de 670

TOGOF 9.1
La siguiente tabla ilustra donde ahora se puede localizar TOGAF 8.1.1 Contenido
base de recursos.
TOGAF 8.1.1 Recursos Architecture Board Arquitectura Cumplimiento Arquitectura
contratos Arquitectura de Gobierno Modelos de Madurez Arquitectura Arquitectura
Patrones Principios Arquitectura Arquitectura Skills Framework Desarrollo
Arquitectura Vistas Bloques de Construcci�n Vistas Dominio de procesos de negocio
Escenarios empresariales Estudios de caso Glosario Otras Arquitecturas y Marcos
Herramientas para el Desarrollo de la Arquitectura ADM y el Marco Zachman Ubicaci�n
actual Trasladado a la Parte VII: Arquitectura del marco de Capacidad Trasladado a
la Parte VII: Arquitectura del marco de Capacidad Trasladado a la Parte VII:
Arquitectura del marco de Capacidad Trasladado a la Parte VII: Arquitectura del
marco de Capacidad Trasladado a la Parte VII: Arquitectura del marco de Capacidad
Trasladado a la Parte III: Directrices y T�cnicas de ADM Trasladado a la Parte III:
Directrices y T�cnicas de ADM Trasladado a la Parte VII: Arquitectura del marco de
Capacidad Elementos retenidos dentro de la Parte IV: Marco de Arquitectura de
contenido Elementos retenidos dentro de la Parte IV: Marco de Arquitectura de
contenido Elementos retenidos dentro de la Parte IV: Marco de Arquitectura de
contenido Trasladado a la Parte III: Directrices y T�cnicas de ADM Eliminado.
Estudios de caso estar�n disponibles en el sitio web Open Group. Trasladado a la
Parte I: Introducci�n Eliminado. Este material estar� disponible en el sitio web de
Open Group como un Libro Blanco. Trasladado a la Parte V: Empresa Continuum y
Herramientas Eliminado. Este material estar� disponible en el sitio web de Open
Group como un Libro Blanco.
4.4 Mapeo de TOGAF 9 Estructura de TOGAF 8.1.1

La siguiente tabla muestra los puntos de TOGAF 9 cap�tulos se asignan a los de
TOGAF 8.1.1:
TOGAF 9 Cap�tulo Parte I: Introducci�n 1 Introducci�n 2 Conceptos B�sicos 3
Definiciones 4 Notas de la versi�n Parte II: Arquitectura M�todo de Desarrollo 5
Introducci�n 6 Fase Preliminar 7 Fase A: Architecture Vision 8 Fase B: Arquitectura
de Negocios Derivaci�n de TOGAF 8.1.1 Material revisado; basado en el cap�tulo 1
Nuevo cap�tulo El material derivado de Cap�tulo 36, vuelto a trabajar en las
definiciones formales y abreviaturas secciones Nuevo cap�tulo Material revisado;
basado en el Cap�tulo 3 Material revisado; basado en el Cap�tulo 4 Material
revisado; basado en el Cap�tulo 5 Material revisado; basado en el Cap�tulo 6
P�gina 37 de 670

TOGOF 9.1
9 Fase C: Arquitecturas de Sistemas de Informaci�n 10 Fase C: Arquitectura de Datos
11 Fase C: Arquitectura de aplicaciones 12 Fase D: Architecture Tecnolog�a 13 Fase
E: Oportunidades y Soluciones 14 Fase C: planeamiento de migraci�n 15 Fase G:
Gobernanza Aplicaci�n 16 Fase H: Gesti�n Arquitectura Cambio 17 ADM Arquitectura
Gesti�n de Requisitos Parte III: Directrices y T�cnicas de ADM 18 Introducci�n 19
La aplicaci�n de la ADM a trav�s de la Arquitectura del Paisaje 20 La aplicaci�n de
la ADM en los diferentes niveles de la empresa 21 Arquitectura de Seguridad y el
ADM Material revisado; basado en el Cap�tulo 7 Material revisado; basado en el
Cap�tulo 8 Material revisado; basado en el Cap�tulo 9 Material revisado; basado en
el cap�tulo 10 Material revisado; basado en el cap�tulo 11 Material revisado;
basado en el Cap�tulo 12 Material revisado; basado en el cap�tulo 13 Material
revisado; basado en el cap�tulo 14 Ning�n cambio material; mapas del cap�tulo 15
Nuevo cap�tulo Nuevo cap�tulo Nuevo cap�tulo
Nuevo cap�tulo; derivado del Libro Blanco de Seguridad (W055) 22 Usando TOGAF para
definir y Gobierno SOAs Nuevo cap�tulo 23 Principios Arquitectura Ning�n cambio
material; mapas del cap�tulo 29 24 Gesti�n de las partes interesadas Nuevo cap�tulo
25 Arquitectura Patrones Ning�n cambio material; mapas del cap�tulo 28 26
Escenarios empresariales Ning�n cambio material; mapas para el Cap�tulo 34 27
An�lisis Gap Nuevo cap�tulo; derivado del an�lisis de las deficiencias 28 T�cnicas
de Planificaci�n Migraci�n Nuevo cap�tulo 29 Requisitos de interoperabilidad Nuevo
cap�tulo 30 Evaluaci�n de la preparaci�n de Nuevo cap�tulo transformaci�n de
negocios 31 Gesti�n de Riesgos Nuevo cap�tulo 32 Planificaci�n de Capacidad basada
en Nuevo cap�tulo Parte IV: Marco de Arquitectura de contenido 33 Introducci�n
Nuevo cap�tulo 34 Metamodel contenido Nuevo cap�tulo 35 Architectural Artifacts
Derivado del cap�tulo 31, adem�s de nuevo material 36 Arquitectura Entregables
Revisado; era Cap�tulo 16 37 Bloques de Construcci�n Revisado del cap�tulo 32 Parte
V: Empresa Continuum y Herramientas 38 Introducci�n Nuevo cap�tulo 39 Continuum
Empresarial Derivado de los cap�tulos 17 y 18 con las revisiones sustanciales 40
Arquitectura Particiones Nuevo cap�tulo 41 Arquitectura Repositorio Nuevo cap�tulo
42 Herramientas para el Desarrollo de la Derivado del Cap�tulo 38, con las
directrices de Arquitectura evaluaci�n eliminados. Parte VI: Modelos TOGAF
Referencia 43 Fundaci�n Arquitectura: T�cnico Ning�n cambio material; Los mapas de
los Cap�tulos 19 Modelo de Referencia y 20 44 Integrado de Informaci�n
Infraestructura Ning�n cambio material; mapas del cap�tulo 22 Modelo de Referencia
Parte VII: Arquitectura del marco de Capacidad 45 Introducci�n Nuevo cap�tulo 46
Establecer una capacidad de Arquitectura Nuevo cap�tulo
P�gina 38 de 670

TOGOF 9.1
47 Architecture Board 48 Arquitectura Cumplimiento 49 Arquitectura contratos 50
Arquitectura de Gobierno 51 Modelos de Madurez Arquitectura 52 Arquitectura Skills
Framework La Glosario de Definiciones complementarias B Abreviaturas Con cambios
m�nimos; mapas del cap�tulo 23 Con cambios m�nimos; mapas para el Cap�tulo 24 Con
cambios m�nimos; mapas para el Cap�tulo 25 Con cambios m�nimos, se asigna al
Cap�tulo 26 Con cambios m�nimos; mapas del cap�tulo 27 Algunos cambios cosm�ticos;
mapas del cap�tulo 30 Derivado del Cap�tulo 36 Derivado del Cap�tulo 36
4.5 Utilizar TOGAF

4.5.1 Condiciones de uso
La documentaci�n TOGAF est� libremente disponible para ver en l�nea sin licencia.
Alternativamente, el conjunto completo de documentaci�n TOGAF puede ser descargado
y almacenado bajo licencia, como se explica en el sitio web la informaci�n TOGAF.
En cualquier caso, la documentaci�n TOGAF puede ser utilizado libremente por
cualquier organizaci�n que as� lo deseen para desarrollar una arquitectura para su
uso dentro de esa organizaci�n. Ninguna parte de ella puede ser reproducida,
almacenada en un sistema de recuperaci�n, o transmitida de ninguna forma ni por
ning�n medio, ya sea electr�nico, mec�nico, fotocopia, grabaci�n, o de otra manera,
para cualquier otro prop�sito, incluyendo, pero no a modo de limitaci�n, cualquier
utilizaci�n con fines comerciales, sin el permiso previo de los propietarios de
derechos de autor.
4.5.2 �Cu�nto cuesta TOGAF?

The Open Group opera como un consorcio sin fines de lucro comprometida con la
entrega de una mayor eficiencia de las empresas, reuniendo a compradores y
proveedores de sistemas de informaci�n para reducir las barreras de la integraci�n
de las nuevas tecnolog�as en la empresa. Su objetivo es hacer realidad la visi�n de
Flujo de informaci�n sin fronteras. TOGAF es una parte clave de su estrategia para
lograr este objetivo, y The Open Group quiere TOGAF que deben abordarse y se
utiliza en los proyectos de arquitectura pr�cticos y la experiencia de su uso
realimenta a ayudar a mejorarlo. Por tanto, el Open Group publica TOGAF en su
servidor web p�blico, y permite y alienta la reproducci�n y el uso libre de cargo
por cualquier organizaci�n que desee utilizarlo internamente para desarrollar una
arquitectura empresarial. (Existen restricciones para su explotaci�n comercial, sin
embargo, ver 4.5.1 Condiciones de uso .)
4.5.3 Descargas
Descargas de la documentaci�n TOGAF, incluyendo un archivo PDF para imprimir, est�n
disponibles bajo licencia desde el sitio web la informaci�n TOGAF
(consultewww.opengroup.org / Arquitectura / togaf ). La licencia es libre para
cualquier organizaci�n que desee utilizar TOGAF exclusivamente para fines internos
(por ejemplo, para desarrollar una empresa de arquitectura para su uso dentro de la
organizaci�n).
P�gina 39 de 670

TOGOF 9.1
4.6 �Por qu� unirse The Open Group?

Las organizaciones que deseen reducir el tiempo, costo y riesgo de la
implementaci�n de soluciones de m�ltiples proveedores que se integran dentro de y
entre las empresas necesitan The Open Group como su socio clave. The Open Group
re�ne a los compradores y proveedores de sistemas de informaci�n en todo el mundo,
y les permite trabajar juntos, tanto para garantizar que las soluciones de TI a
cumplir las necesidades de los clientes, y para hacer m�s f�cil la integraci�n de
TI en toda la empresa. TOGAF es un factor clave en esta tarea. S�, s� TOGAF est�
disponible gratuitamente. Pero, �cu�nto va a gastar en el desarrollo o la
actualizaci�n de su arquitectura empresarial utilizando TOGAF? �Y cu�nto va a
gastar en adquisiciones en base a que la arquitectura? El precio de la membres�a de
The Open Group es insignificante en comparaci�n con estas cantidades. Adem�s de los
beneficios generales de la pertenencia, como miembro de The Open Group usted ser�
elegible para participar en el Foro de Arquitectura Open Group, que es el programa
de desarrollo en el que se desarroll� TOGAF, y en el que los usuarios TOGAF
reunirse para intercambiar informaci�n y la retroalimentaci�n. Los miembros de la
ganancia Architecture Forum: Acceso inmediato a los frutos del actual programa de
trabajo TOGAF (no disponible para el p�blico hasta la publicaci�n de la pr�xima
edici�n del documento TOGAF) - de hecho, la �ltima informaci�n sobre TOGAF El
intercambio de experiencias con otras organizaciones de clientes y proveedores que
participan en la arquitectura empresarial en general, y la creaci�n de redes con
los arquitectos que utilizan TOGAF en proyectos de desarrollo de arquitectura
importantes de todo el mundo La revisi�n por pares de la caja material de estudio
arquitectura espec�fica
P�gina 40 de 670

P 1 Togaf91 Es

Cargado por

Información del documento

Título original

Derechos de autor

Formatos disponibles

Compartir este documento

Compartir o incrustar documentos

Opciones para compartir

¿Le pareció útil este documento?

¿Este contenido es inapropiado?

Copyright:

Formatos disponibles

P 1 Togaf91 Es

Cargado por

Copyright:

Formatos disponibles

The Open Group Architecture Framework

The Open Group Architecture Framework

1.1 Estructura del documento TOGAF

The Open Group Architecture Framework

Figura 1-1: Estructura del documento TOGAF

1.2 Resumen Ejecutivo

The Open Group Architecture Framework

El prop�sito de la arquitectura de la empresa es la optimizaci�n de toda la empresa

Una operaci�n de TI m�s eficiente: o o o o Bajo desarrollo de software, soporte y

The Open Group Architecture Framework

M�s r�pido, m�s sencillo y m�s barato de adquisiciones: o o o o Las decisiones de

Espec�ficamente, �qu� me incitar�a a desarrollar una empresa de arquitectura?

Por lo general, la preparaci�n para las necesidades de transformaci�n de negocios o

Un marco de arquitectura es una estructura fundamental, o conjunto de estructuras,

The Open Group Architecture Framework

TOGAF se ha desarrollado gracias a la colaboraci�n de m�s de 300 empresas miembros

Toda empresa de organizaci�n o planificaci�n para llevar a cabo el desarrollo e

The Open Group Architecture Framework

2.1 �Qu� es TOGAF?

2.2 �Qu� es la arquitectura en el contexto de TOGAF?

1. Una descripci�n formal de un sistema, o un plan detallado del sistema a nivel de

2.3 �Qu� tipo de arquitectura TOGAF �El trato con?

The Open Group Architecture Framework

2.4 Arquitectura M�todo de Desarrollo

The Open Group Architecture Framework

2.5 Entregables, Artefactos y bloques de construcci�n

The Open Group Architecture Framework

Figura 21: Las relaciones entre los entregables, Artefactos y bloques de

Figura 22: Ejemplo Arquitectura de definici�n de documento P�gina 11 de 670

The Open Group Architecture Framework

Continuum 2.6 Empresa

2.7 Arquitectura Repositorio

The Open Group Architecture Framework

Figura 24: TOGAF Arquitectura Estructura del repositorio

Los componentes principales dentro de un repositorio de Arquitectura son los

The Open Group Architecture Framework

2.8 Establecer y mantener una capacidad de Arquitectura Empresarial

Figura 25: Introducci�n a la arquitectura TOGAF Capability

2.9 Establecimiento de la Capacidad de Arquitectura como una

The Open Group Architecture Framework

Central a la idea de operar una arquitectura en curso es la ejecuci�n del bien

The Open Group Architecture Framework

Mayores detalles sobre el establecimiento de una capacidad de arquitectura

2.10 El uso de TOGAF con otros marcos

Con algunas excepciones, la mayor�a de los marcos de arquitectura empresarial se

The Open Group Architecture Framework

3.4 Arquitectura de la aplicaci�n

3.5 Application Platform

The Open Group Architecture Framework

3.6 Plataforma de Aplicaciones (API)

3.7 Estilo arquitect�nico

3.9 Arquitectura Bloque de construcci�n (ABB)

3.10 Arquitectura Continuum

3.11 Arquitectura M�todo de Desarrollo (ADM)

The Open Group Architecture Framework

3.12 Arquitectura de dominio

3.13 Marco de Arquitectura

3.14 Arquitectura de Gobierno

3.15 Arquitectura del Paisaje

3.16 Principios Arquitectura

3,17 Architecture Vision

como una visi�n pol�tica y un l�mite para el desarrollo detallado de la

The Open Group Architecture Framework