Togaf 9 1 Parte I

The Open Group Architecture Framework
TOGOF9.1
FASE I
Introduccin
Pgina1de670
TOGOF9.1
1. Introduccin
TOGAF es un marco - un mtodo detallado y un conjunto de herramientas de apoyo - para el
desarrollo de una empresa de arquitectura. Puede ser utilizado libremente por cualquier
organizacin que desee desarrollar una empresa de arquitectura para su uso dentro de esa
organizacin
TOGAF es desarrollado y mantenido por miembros de The Open Group, trabajando dentro del Foro
de Arquitectura.
El desarrollo original de TOGAF Versin 1 en 1995 se bas en el Marco de Arquitectura Tcnica

para la Gestin de la Informacin (TAFIM), desarrollado por el Departamento de Defensa de
EE.UU. ( DoD ). El Departamento de Defensa dio el permiso explcito Open Group y el estmulo
para crear TOGAF apoyndose en la TAFIM, que a su vez fue el resultado de muchos aos de
esfuerzo de desarrollo y muchos millones de dlares de inversin Gobierno de los EE.UU..
A partir de esta slida base, los miembros de El Foro Open Group Architecture han desarrollado
versiones sucesivas de TOGAF y publicado cada uno en el sitio web pblico 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 documentacin TOGAF refleja la estructura y el contenido de una capacidad de
Arquitectura dentro de una empresa, como se muestra en la Figura 1-1 .
Pgina2de670
TOGOF9.1
Figura 1-1: Estructura del documento TOGAF

Hay siete partes en el documento de TOGAF:
PARTE I
(Introduccin) Esta parte proporciona una introduccin de alto nivel a los conceptos clave
de la arquitectura de la empresa y, en particular, el enfoque TOGAF.Contiene las
definiciones de los trminos utilizados en TOGAF y notas de la versin que detallan los
cambios entre esta versin y la versin anterior de TOGAF.
PARTE II
(Arquitectura Mtodo de Desarrollo) Esta parte es el ncleo de TOGAF. En l se describe
la Arquitectura Mtodo de Desarrollo de TOGAF (ADM) - un enfoque paso a paso para el
desarrollo de una empresa de arquitectura.
PARTE III
(Directrices de ADM y Tcnicas) Esta parte contiene una coleccin de guas y tcnicas
disponibles para su uso en la aplicacin 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 arquitectnicos, el uso de bloques
de la arquitectura de construccin reutilizables, y una visin general de los entregables
arquitectura tpica.
Pgina3de670
TOGOF9.1
PARTE V
(Enterprise Continuum y Herramientas) Esta parte trata sobre las taxonomas 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 seleccin de los modelos de
referencia de arquitectura, que incluye la Fundacin Arquitectura TOGAF y el Integrado de
Informacin de Referencia Infraestructura Modelo (III-RM).
PARTE VII
(Capability Framework Architecture) Esta parte se analiza la organizacin, procesos,
habilidades, roles y responsabilidades necesarias para establecer y operar una funcin de
la arquitectura dentro de una empresa.
La intencin de dividir la especificacin TOGAF en estas partes independientes es permitir que
diferentes reas de especializacin que se considerarn en detalle y potencialmente abordados de
manera aislada. Aunque todas las partes funcionan juntos como un todo, tambin es factible
seleccionar determinadas partes para su aprobacin y se excluyan otros. Por ejemplo, una
organizacin podra 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
especificacin para su aprobacin inicial, con otras reas presentadas para su
consideracin posterior.
Las organizaciones que ya han implementado marcos de arquitectura pueden optar por
combinar estos marcos con los aspectos de la especificacin TOGAF.
1.2 Resumen Ejecutivo

En esta seccin se ofrece un panorama general ejecutivo de la arquitectura empresarial, los
conceptos bsicos de lo que es (no slo 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
adopcin 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 podra ser una agencia del gobierno, toda una
corporacin, una divisin de una corporacin, un solo departamento, o una cadena de
organizaciones geogrficamente distantes unidos entre s por la propiedad comn.
El trmino "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 informacin y
tecnologa, los procesos y la infraestructura - y un dominio especfico dentro de la empresa. En
ambos casos, la arquitectura cruza mltiples sistemas, y mltiples grupos funcionales dentro de la
empresa.
La confusin surge a menudo de la naturaleza evolutiva del trmino "empresa". Una empresa
extendida incluye hoy en da con frecuencia socios, proveedores y clientes. Si el objetivo es la
integracin de una empresa extendida, entonces la empresa cuenta con los socios, proveedores y
clientes, as como las unidades de negocio internas.
Pgina4de670
TOGOF9.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 organizacin. 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 comn acerca de los sistemas de informacin en cada empresa, y por lo
general hay un gran potencial para el aumento en el uso de un marco de arquitectura comn. Por
ejemplo, un marco comn puede proporcionar la base para el desarrollo de un repositorio de
Arquitectura para la integracin y la reutilizacin de modelos, diseos y datos de referencia.
Por qu necesito una empresa de arquitectura?
El propsito de la arquitectura de la empresa es la optimizacin 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 aplicacin de la estrategia de negocios.
CEOs de hoy saben que la gestin y explotacin de la informacin eficaz a travs 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
estratgico para la evolucin 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 innovacin empresarial. Permite a las unidades de negocios individuales
para innovar de forma segura en su bsqueda de la ventaja competitiva. Al mismo tiempo, se
asegura que las necesidades de la organizacin de una estrategia de TI integrada se cumplen, lo
que permite la sinergia ms cercano posible a travs 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 prdida neta de una empresa
u organizacin:
Una operacin de negocio ms eficiente:
o Menores costos de operacin de negocios
o Organizacin ms gil
o Capacidades empresariales compartidos a travs de la organizacin
o Costos de gestin del cambio Inferior
o Fuerza de trabajo ms flexible
o Mejora de la productividad de las empresas
Una operacin de TI ms eficiente:
o Bajo desarrollo de software, soporte y mantenimiento de los costos
o El aumento de la portabilidad de las aplicaciones
o Interoperabilidad mejorada y ms fcil sistema y red de gestin
o Mejora de la capacidad para abordar cuestiones crticas a nivel de empresa como

la seguridad
Pgina5de670
TOGOF9.1
o Ms fcil actualizacin y el intercambio de los componentes del sistema
Mejor retorno de la inversin existente, menor riesgo para la inversin futura:
o Reduccin de la complejidad en el negocio y TI
o Mximo rendimiento de la inversin en la infraestructura de TI de negocios

existentes y
o La flexibilidad de hacer, comprar o subcontratar las soluciones de negocio y de TI
o Reduccin del riesgo general en las nuevas inversiones y su coste de propiedad
Ms rpido, ms sencillo y ms barato de adquisiciones:
o Las decisiones de compra son ms simples, ya que la informacin que rige la

contratacin est fcilmente disponible en un plan coherente
o El proceso de contratacin es ms rpido - maximizar la velocidad de adquisicin y

flexibilidad sin sacrificar la coherencia arquitectnica
o La capacidad de suministro de los sistemas abiertos heterogneos de mltiples

proveedores
o La capacidad de asegurar las capacidades ms econmicos
Especficamente, qu me incitara a desarrollar una empresa de arquitectura?
Por lo general, la preparacin para las necesidades de transformacin de negocios o de cambios

en la infraestructura radicales inicia una revisin 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 comnmente como las "partes
interesadas" en el cambio. El papel del arquitecto es hacer frente a sus preocupaciones a travs
de:
La identificacin y el perfeccionamiento de los requisitos que los interesados tienen
Desarrollo de vistas de la arquitectura que muestran cmo las preocupaciones y

necesidades van a ser tratados
Mostrando las compensaciones que se van a realizar en la conciliacin 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 sern 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
mtodo para el diseo de un estado objetivo de la empresa en trminos de un conjunto de bloques
de construccin, y para mostrar cmo los bloques de construccin encajan. Debe contener un
conjunto de herramientas y proporcionar un vocabulario comn. Tambin debe incluir una lista de
estndares recomendados y los productos compatibles que se pueden utilizar para implementar los
bloques de construccin.
Pgina6de670
TOGOF9.1
Por qu necesito TOGAF como marco para la arquitectura de la empresa?
TOGAF se ha desarrollado gracias a la colaboracin de ms 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 prcticas, y le da la debida atencin tanto a las
necesidades actuales y las necesidades futuras percibidas de la empresa.
Desarrollar y mantener una empresa de arquitectura es un proceso tcnicamente complejo que

implica a muchos interesados y los procesos de decisin en la organizacin.TOGAF juega un papel
importante en la normalizacin y de-riesgo el proceso de desarrollo de la arquitectura. TOGAF
proporciona un marco de mejores prcticas para agregar valor, y permite a la organizacin para
construir soluciones viables y econmicas que permitan atender a sus problemas de negocio y
necesidades.
Quin se beneficiara del uso de TOGAF?
Toda empresa de organizacin o planificacin para llevar a cabo el desarrollo e implementacin

de una empresa de arquitectura para el soporte de la transformacin del negocio se beneficiarn
del uso de TOGAF.
Las organizaciones que buscan sin fronteras Flujo de informacin pueden usar TOGAF para definir
y poner en prctica las estructuras y procesos para permitir el acceso a la informacin integrada
dentro de y entre las empresas.
Las organizaciones que disean e implementan arquitecturas empresariales utilizando TOGAF

tienen la garanta de un diseo y una especificacin de adquisiciones que pueden facilitar una
puesta en prctica de sistemas abiertos, permitiendo as que los beneficios de los sistemas
abiertos con un menor riesgo.
Pgina7de670
TOGOF9.1
2. Conceptos Bsicos
A los efectos de TOGAF 9, los conceptos bsicos proporcionados en este captulo se aplican.
2.1 Qu es TOGAF?
TOGAF es un marco de arquitectura. TOGAF proporciona los mtodos y herramientas para ayudar
en la aceptacin, la produccin, el uso y el mantenimiento de una empresa de arquitectura. Se
basa en un modelo de proceso iterativo con el apoyo de las mejores prcticas 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 organizacin fundamental de un sistema, encarnada en sus componentes, sus relaciones entre
s y con el medio ambiente, y los principios que rigen su diseo y evolucin."
TOGAF abarca pero no se adhiere estrictamente a la norma ISO / IEC 42010:2007

terminologa. En TOGAF, "arquitectura" tiene dos significados, dependiendo del contexto:
1. Una descripcin formal de un sistema, o un plan detallado del sistema a nivel de

componente para orientar su aplicacin
2. La estructura de los componentes, sus interrelaciones, y los principios y directrices que

rigen su diseo y evolucin en el tiempo
TOGAF considera la empresa como un sistema y se esfuerza por lograr un equilibrio entre la
promocin de los conceptos y la terminologa de la norma ISO / IEC 42010:2007 - garantizar que el
uso de los trminos definidos por la norma ISO / IEC 42010:2007 es compatible con la norma - y
retener otra frecuencia aceptado la terminologa que es familiar para la mayora de los lectores
TOGAF. Para ms informacin sobre la terminologa, 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 comnmente aceptadas como subconjuntos de un
conjunto de arquitectura empresarial, todo lo cual TOGAF est diseado para soportar:
La arquitectura de negocio define la estrategia empresarial, el gobierno, la organizacin y

los procesos clave del negocio.
La Arquitectura de Datos describe la estructura de los activos de datos lgicos y fsicos

de una organizacin y los recursos de gestin de datos.
Pgina8de670
TOGOF9.1
La Arquitectura de la aplicacin proporciona un modelo para las aplicaciones

individuales que se desplegarn, sus interacciones y su relacin con los procesos de
negocio de la organizacin.
La Tecnologa de la Arquitectura describe las capacidades de software y hardware

lgicos 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 Mtodo de Desarrollo

La Arquitectura Mtodo 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 transicin, y que rige la realizacin de
arquitecturas.
Todas estas actividades se llevan a cabo dentro de un ciclo iterativo de definicin de la arquitectura
y la realizacin 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 preparacin e iniciacin necesarios para

crear una capacidad de Arquitectura incluyendo personalizacin de TOGAF y definicin de
Arquitectura Principios.
Fase A: Arquitectura Visin describe la fase inicial de un ciclo de desarrollo de la

arquitectura. Incluye informacin sobre cmo definir el alcance de la iniciativa de desarrollo
de la arquitectura, la identificacin de las partes interesadas, la creacin de la arquitectura
de la Visin, y obtener la aprobacin 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 Informacin Arquitecturas describe el desarrollo de Sistemas de

Informacin Arquitecturas para apoyar el acuerdo Architecture Vision.
Fase D: Architecture Tecnologa describe el desarrollo de la arquitectura de la

tecnologa para apoyar el acuerdo Architecture Vision.
Fase E: Oportunidades y Soluciones lleva a cabo la planificacin de la implementacin

inicial y la identificacin de los vehculos de reparto para la arquitectura se define en las
fases anteriores.
Fase C: planeamiento de migracin aborda cmo pasar de la lnea de base a las

arquitecturas objetivo al finalizar una implementacin detallada y Plan de Migracin.
Fase G: Gobernanza Aplicacin proporciona una supervisin de arquitectura de la

aplicacin.
Fase H: Arquitectura de Gestin del Cambio , establece los procedimientos para la

gestin del cambio a la nueva arquitectura.
Pgina9de670
TOGOF9.1
Gestin de Requisitos examina el proceso de gestin de requisitos de arquitectura en

todo el ADM.
2.5 Entregables, Artefactos y bloques de construccin

Arquitectos ejecutores del ADM producirn una serie de resultados, como resultado de sus
esfuerzos, como los flujos de procesos, requisitos arquitectnicos, planes de proyectos,
evaluaciones de cumplimiento de proyectos, etc El marco de contenido TOGAF Arquitectura
(ver la Parte IV , 33. Introduccin ) 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 categoras 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 documentacin sern tpicamente archivadas en la finalizacin de un
proyecto, o la transicin hacia un repositorio arquitectura como un modelo de referencia,
estndar o instantnea de la arquitectura del paisaje en un punto en el tiempo.
Un artefacto es un producto del trabajo arquitectnico que describe un aspecto de la

arquitectura. Los artefactos se clasifican generalmente como catlogos (listas de cosas),
matrices (que muestran las relaciones entre las cosas), y diagramas (imgenes de las
cosas). Los ejemplos incluyen un catlogo de necesidades, matriz de interaccin de
negocios, y un diagrama de casos de uso. Un entregable arquitectnica puede contener
muchos objetos y artefactos formarn el contenido de la Arquitectura Repository.
Un bloque de construccin representa un (potencialmente reutilizable), componente de

negocio, TI, o la capacidad de la arquitectura que se puede combinar con otros bloques de
construccin para ofrecer arquitecturas y soluciones.
Bloques de construccin 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 construccin puede consistir simplemente en un nombre o una
breve descripcin. Ms tarde, un bloque de construccin se puede descomponer en varios
bloques de edificios de apoyo y puede ir acompaada de una especificacin
completa. Bloques de construccin pueden relacionarse con "arquitecturas" o "soluciones".
o Arquitectura Bloques de Construccin (Abs) suelen describir la capacidad

requerida y dar forma a la especificacin de soluciones de Bloques de
Construccin (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 aplicacin.
o Solucin Building Blocks (SBB) representan los componentes que se utilizarn

para implementar la capacidad requerida. Por ejemplo, una red es un bloque de
construccin que se puede describir a travs de artefactos complementarios y
luego objeto de un uso para darse cuenta de las soluciones para la empresa.
Pgina10de670
TOGOF9.1
Las relaciones entre los entregables, artefactos y bloques de construccin se muestran en

la Figura 2-1 .
Figura21:Lasrelacionesentrelosentregables,Artefactosybloquesdeconstruccin
Por ejemplo, una definicin de documento La arquitectura es un entregable que documenta una
descripcin de la arquitectura. Este documento contendr una serie de artefactos complementarios
que son puntos de vista de los componentes bsicos de inters para la arquitectura. Por ejemplo,
un diagrama de flujo del proceso (un artefacto) puede ser creado para describir el proceso de
gestin de llamadas de destino (un bloque de construccin). Este artefacto puede tambin describir
otros bloques de construccin, 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 construccin se ilustra en la Figura 2-2 .

Figura22:EjemploArquitecturadedefinicindedocumento
Pgina11de670
TOGOF9.1
Continuum 2.6 Empresa

TOGAF incluye el concepto de Enterprise Continuum, que establece el contexto ms amplio de un
arquitecto y explica cmo las soluciones genricas pueden ser apalancados y especializada con el
fin de apoyar las necesidades de una organizacin en particular. The Enterprise Continuum es una
vista del Repositorio de Arquitectura que proporciona mtodos para clasificar la arquitectura y los
artefactos de la solucin a medida que evolucionan a partir de genricos Arquitecturas Fundacin a
las arquitecturas Organizacin Especficos. The Enterprise Continuum comprende dos conceptos
complementarios: la arquitectura y el Continuum Continuum Solutions.
Una visin general de la estructura y el contexto para la empresa Continuum se muestra en

la Figura 2-3 .

Figura23:EmpresaContinuum
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 produccin arquitectnica en diferentes niveles
de abstraccin, creado por el ADM. De esta manera, TOGAF facilita la comprensin y la
cooperacin 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 arquitectnicos relevantes en el desarrollo de una
arquitectura de organizacin especfica.
En este contexto, el TOGAF ADM puede ser considerada como la descripcin de un ciclo de vida
proceso que opera en mltiples niveles dentro de la organizacin, que operan dentro de un marco
global de gobernanza y la produccin de resultados alineados que residen en un repositorio de
Pgina12de670
TOGOF9.1
Arquitectura. The Enterprise Continuum proporciona un contexto til para la comprensin de los
modelos arquitectnicos: muestra bloques de construccin 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 .

Figura24:TOGAFArquitecturaEstructuradelrepositorio

Los componentes principales dentro de un repositorio de Arquitectura son los siguientes:
La Arquitectura Metamodel describe la aplicacin organizativo adaptado de un marco de

arquitectura, incluyendo un metamodelo para el contenido de la arquitectura.
La Capacidad de Arquitectura define los parmetros, estructuras y procesos que ayuden

a la gobernabilidad de la arquitectura de repositorio.
La arquitectura del paisaje es la representacin arquitectnica de activos desplegados

dentro de la empresa de explotacin en un punto determinado en el tiempo.El paisaje es
probable que exista en mltiples niveles de abstraccin para adaptarse a diferentes
objetivos de la arquitectura.
Pgina13de670
TOGOF9.1
La Base de informacin 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
organizacin.
La Biblioteca de Referencia proporciona directrices, plantillas, patrones y otras formas de

material de referencia que se puede aprovechar el fin de acelerar la creacin 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 arquitectnica con eficacia dentro de una empresa, es
necesario poner en marcha una capacidad de negocio apropiado para la arquitectura, a travs de
las estructuras de organizacin, funciones, responsabilidades, habilidades y procesos. Una visin
general de la capacidad TOGAF Arquitectura se muestra en la Figura 2-5 .

Figura25:IntroduccinalaarquitecturaTOGAFCapability
2.9 Establecimiento de la Capacidad de Arquitectura como una

Entidad Operacional
Salvo capacidades de arquitectura creados para apoyar exclusivamente los programas de
prestacin de cambio, se reconoce cada vez ms que una prctica exitosa de la arquitectura
empresarial debe sentarse sobre una base operativa firme. En efecto, una prctica de la
Pgina14de670
TOGOF9.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
bsicos definidos en el ADM, una prctica de la arquitectura empresarial debe establecer
capacidades en las siguientes reas:
Gestin Financiera
Gestin del rendimiento (vase 3.52 Performance Management )
Gestin de Servicios
Gestin de Riesgos (vase Gestin de Riesgos A.75 )
Gestin de Recursos
Comunicaciones y Gestin de los interesados (vase 3.29 Comunicaciones y Gestin de

los grupos de inters )
Gestin de la Calidad
Gestin de Proveedores (vase Gestin de Proveedores A.82 )
Gestin de la Configuracin (ver Gestin de la Configuracin A.15 )
Gestin Ambiental
Central a la idea de operar una arquitectura en curso es la ejecucin del bien definido y un
gobierno eficaz, por lo que toda la actividad de gran importancia arquitectnica es controlado y
alineado en un marco nico.
Como el gobierno se ha convertido en un requisito cada vez ms visible de la gestin

organizacional, la inclusin de la gobernabilidad dentro de TOGAF alinea el marco de las mejores
prcticas de negocio actual y tambin asegura un nivel de visibilidad, orientacin 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 rendicin de cuentas, y la delegacin inform de la

autoridad
La gestin del riesgo controlado
Proteccin de la base de activos existente a travs de la maximizacin de la reutilizacin

de los componentes arquitectnicos existentes
Mecanismos de control proactivo, monitoreo y gestin
Proceso, concepto, y el componente de reutilizacin a travs de todas las unidades de

negocio de la organizacin
La creacin de valor a travs del monitoreo, medicin, evaluacin y retroalimentacin
Pgina15de670
TOGOF9.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 estratgicas para la organizacin
Gran valor para el accionista; en particular, la arquitectura empresarial representa cada vez
ms la propiedad intelectual del ncleo de la empresa - los estudios han demostrado una
correlacin entre el aumento de valor para los accionistas y las empresas bien gobernadas
Se integra con los procesos y las metodologas existentes y complementa la funcionalidad

mediante la adicin de capacidades de control
Mayores detalles sobre el establecimiento de una capacidad de arquitectura empresarial se da

en la parte VII , 45. Introduccin .
2.10 El uso de TOGAF con otros marcos

Dos de los elementos clave de cualquier marco de arquitectura de la empresa son:
Una definicin de los entregables que la actividad architecting debera producir
Una descripcin del mtodo por el cual esto se debe hacer
Con algunas excepciones, la mayora de los marcos de arquitectura empresarial se centran en el

primero de ellos - el conjunto especfico de prestaciones - y son relativamente en silencio acerca de
los mtodos que se utilizarn para generarlos (intencionalmente as, en algunos casos).
Debido TOGAF es un marco genrico 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 genricos.
Como resultado, TOGAF se puede utilizar ya sea en su propio derecho, con las prestaciones
genricas que en l se describen; o bien estas prestaciones podrn ser sustituidos o ampliados por
un conjunto ms especfico, 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 mtodo a medida que se integra en los procesos y estructuras de organizacin
de la empresa. Esta arquitectura adaptacin puede incluir la adopcin de elementos de otros
marcos de arquitectura, o la integracin de mtodos TOGAF con otros marcos estndar, tales
como ITIL, CMMI, COBIT, PRINCE2, PMBOK, y MSP. Directrices para la adaptacin de la TOGAF
ADM de tal manera se proporcionan en la Parte II , 5.3 Adaptacin de la ADM .
Como un marco genrico y un mtodo para la arquitectura empresarial, TOGAF proporciona la

capacidad y el entorno de colaboracin para la integracin con otros marcos.Las organizaciones
son capaces de utilizar plenamente los dominios verticales de negocios, reas tecnolgicas
horizontales (como la seguridad o la capacidad de gestin), o reas de aplicacin (por ejemplo, e-
Commerce) para producir un marco de arquitectura empresarial competitivo que maximiza sus
oportunidades de negocio.
Pgina16de670
TOGOF9.1
3. Definiciones
A los efectos de TOGAF 9, los siguientes trminos y definiciones. A. Glosario de Definiciones
complementarias debe ser referido para las definiciones suplementarios no definidos en el
presente captulo. Collegiate Dictionary de Merriam-Webster debe ser referido para los trminos no
definidos en esta seccin o A. Glosario de definiciones complementarias .
3.1 Abstraccin
La tcnica de proporcionar descripciones resumidas o generalizadas de contenido detallado y
complejo.
La abstraccin, como en "nivel de abstraccin", tambin puede significar que proporciona un

enfoque de anlisis que tiene que ver con un nivel consistente y comn de detalle o la
abstraccin. Abstraccin en este sentido se utiliza normalmente en la arquitectura para permitir un
nivel consistente de la definicin y la comprensin que deben alcanzarse en cada rea de la
arquitectura con el fin de apoyar la comunicacin 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 ms detalle.
3.2 Actor
Una persona, organizacin o sistema que tiene un papel que inicia o interacta con las
actividades; por ejemplo, un representante de ventas que viaja a visitar a los clientes.Actores
puede ser interno o externo a la organizacin. En la industria automotriz, un fabricante de equipo
original se considera un actor por un concesionario de automviles que interacta con sus
actividades de la cadena de suministro.
3.3 Aplicacin
Un sistema informtico desplegado y operativo que soporte las funciones y servicios a las
empresas; por ejemplo, una nmina. Las aplicaciones utilizan los datos y son apoyados por
mltiples componentes de la tecnologa, pero son distintos de los componentes tecnolgicos que
apoyan la solicitud.
3.4 Arquitectura de la aplicacin

Una descripcin de la estructura y la interaccin de las aplicaciones como grupos de capacidades
que proporcionan las funciones de negocio clave y gestionar los activos de datos.
Nota:
Arquitectura de la aplicacin se describe en la Parte II , 11. Fase C: Arquitecturas de

Sistemas de Informacin - Arquitectura de aplicaciones .
3.5 Application Platform
Pgina17de670
TOGOF9.1
La coleccin de componentes de tecnologa 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 aplicacin y / o de la plataforma de
aplicaciones.
3.7 Estilo arquitectnico

La combinacin de caractersticas distintivas en que se realiza o se expresa la arquitectura.
3.8 Arquitectura
1. Una descripcin formal de un sistema, o un plan detallado del sistema a nivel de

componente, para orientar su aplicacin (fuente: ISO / IEC 42010:2007).
2. La estructura de los componentes, sus interrelaciones, y los principios y directrices que

rigen su diseo y evolucin en el tiempo.
3.9 Arquitectura Bloque de construccin (ABB)

Un componente del modelo de arquitectura que describe un solo aspecto del modelo general.
Ver tambin 3.21 Mdulo .
3.10 Arquitectura Continuum

Una parte de la Empresa de Continuum. Un repositorio de elementos arquitectnicos con creciente
detalle y especializacin. Este Continuum comienza con las definiciones fundamentales como
modelos de referencia, estrategias bsicas y los bloques de construccin bsicos. A partir de ah
se extiende a las arquitecturas de la industria y todo el camino a la arquitectura especfica de una
organizacin.
Ver tambin 3.35 Empresa Continuum .
3.11 Arquitectura Mtodo de Desarrollo (ADM)

El ncleo 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 Mtodo de Desarrollo (ADM) .
Pgina18de670
TOGOF9.1
3.12 Arquitectura de dominio

. El rea arquitectnica est considerando Hay cuatro mbitos de arquitectura dentro de TOGAF:
de negocio, de datos, de aplicaciones y tecnologa.
3.13 Marco de Arquitectura

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

La prctica y la orientacin 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 diseo) y la operacin de sistemas de productos (gobernanza operativa).
Ver tambin 3.39 Gobernabilidad .
3.15 Arquitectura del Paisaje

La representacin arquitectnica de los activos en uso, o previsto, por la empresa en determinados
puntos en el tiempo.
3.16 Principios Arquitectura

Una declaracin 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
UnadescripcinsucintadelaArquitecturaobjetivoquedescribesuvalorparaelnegocioy
loscambiosenlaempresa,queserelresultadodesuimplementacinexitosa.Sirve
comounavisinpolticayunlmiteparaeldesarrollodetalladodela
arquitectura.
Pgina19de670
TOGOF9.1
Nota:
Fase A (Architecture Vision) se describe en la Parte II , 7. Fase A: Architecture Vision .
3.18 Artefacto
Un producto del trabajo arquitectnico que describe un aspecto de la arquitectura.
3.19 Lnea de Base

Una especificacin 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 slo se puede cambiar a travs de los
procedimientos de control de cambios formales o de un tipo de procedimiento como la gestin de la
configuracin.
3.20 Flujo de Informacin sin fronteras
1. Una marca registrada de The Open Group.
2. Una representacin abreviada de "acceso a la informacin integrada para apoyar mejoras

en los procesos de negocio", que representan un estado deseado de la infraestructura de
una empresa especfica a las necesidades de negocio de la organizacin.
Una infraestructura que ofrece sin fronteras Flujo de Informacin cuenta con componentes
estndares abiertos que ofrecen servicios en la empresa extendida que de un cliente:
Combine mltiples fuentes de informacin
Segura entregar la informacin cuando y donde sea necesario, en el contexto adecuado

para las personas o sistemas que utilicen dicha informacin.
Nota:
La necesidad de flujo de informacin sin fronteras se describe en la Parte
VI , 44. Integrado de Informacin de Referencia Infraestructura Modelo .
3.21 Mdulo
Representa un (potencialmente reutilizable), componente de negocio, TI, o la capacidad de la
arquitectura que se puede combinar con otros bloques de construccin para ofrecer arquitecturas y
soluciones.
Pgina20de670
TOGOF9.1
Bloques de construccin 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
construccin puede consistir simplemente en un nombre o una breve descripcin. Ms tarde, un
bloque de construccin se puede descomponer en varios bloques de edificios de apoyo y puede ir
acompaada de una especificacin completa. Bloques de construccin pueden relacionarse con
"arquitecturas" o "soluciones".
Ver tambin 3.18 Artefacto .
Nota:
Bloques de construccin se describen en la Parte IV , 37. Building Blocks .
3.22 Arquitectura de Negocios

Una descripcin de la estructura y la interaccin entre la estrategia de negocio, necesita
organizacin, funciones, procesos de negocio y la informacin.
Nota:
Arquitectura de Negocios se describe en la Parte II , 8. Fase B: Configuracin de asunto .
3.23 Funcin de Empresas

Proporciona capacidades de negocio estrechamente alineadas a una organizacin, pero no
necesariamente gobernadas de forma explcita por la organizacin.
3.24 Gobierno de Empresas

Preocupado por asegurar que los procesos de negocio y las polticas (y su operacin) entregar los
resultados del negocio y se adhieran a la regulacin empresarial relevante.
3.25 Servicios de Negocio

Soporta capacidades de negocio a travs de una interfaz definida explcitamente y se rige
explcitamente por una organizacin.
3.26 Capacidad
Una habilidad que una organizacin, persona o sistema posee. Las capacidades se expresan
normalmente en trminos generales y de alto nivel y por lo general requieren una combinacin de
organizacin, personas, procesos y tecnologa para alcanzar. Por ejemplo, marketing, contacto con
el cliente o telemarketing.
3.27 Capacidad de Arquitectura

Una descripcin muy detallada de la propuesta de arquitectura para darse cuenta de una solucin
particular o una solucin de aspecto.
Pgina21de670
TOGOF9.1
Incremento de 3,28 Capacidad

Una porcin discreta de una arquitectura de capacidad que ofrece un valor especfico. Cuando
todos los incrementos se han completado, la capacidad ha sido realizada.
3.29 Comunicaciones y Gestin de las partes interesadas

La gestin de las necesidades de las partes interesadas de la prctica de la arquitectura
empresarial. Tambin gestiona la ejecucin de la comunicacin entre la prctica y los grupos de
inters y la prctica y los consumidores de sus servicios.
Nota:
Arquitectura gestin de los interesados se describe en el 24. Gestin 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 distribucin, y capacidad
de evolucin.
Ver tambin 3.68 Stakeholder .
3.31 Restriccin
Un factor externo que impide que una organizacin de la bsqueda de enfoques particulares para
cumplir sus objetivos. Por ejemplo, los datos del cliente no est armonizada dentro de la
organizacin, regional o nacional, lo que limita la capacidad de la organizacin para ofrecer un
servicio al cliente eficaz.
3.32 Arquitectura de Datos

Una descripcin de la estructura y la interaccin de los principales tipos de la empresa y las fuentes
de datos, los activos de datos lgicos, los activos fsicos de datos y recursos de gestin de datos.
Nota:
Arquitectura de datos se describe en la Parte II , 10. Fase C: Arquitecturas de Sistemas

de Informacin - Arquitectura de Datos .
3.33 Disponible
Un producto de la obra arquitectnica 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 documentacin normalmente se
Pgina22de670
TOGOF9.1
archiva en la finalizacin de un proyecto, o de transicin a un repositorio de arquitectura como un

modelo de referencia, estndar o instantnea de la arquitectura del paisaje en un punto en el
tiempo.
3.34 Empresa
El nivel ms alto (por lo general) de la descripcin de una organizacin 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 clasificacin de la arquitectura y la solucin artefactos, tanto internos
como externos a la arquitectura de repositorio, a medida que evolucionan a partir de genricos
Arquitecturas Fundacin a las arquitecturas Organizacin especficas de categorizacin.
Ver tambin 3.10 Arquitectura Continuum y 3.67 Soluciones Continuum .
3.36 Fundacin Arquitectura

Bloques genricos de construccin, sus interrelaciones con otros bloques de construccin, junto
con los principios y directrices que proporcionan una base sobre la que las arquitecturas ms
especficas 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 declaracin de la diferencia entre los dos estados. Utilizado en el contexto del anlisis de las
lagunas, donde se identifica la diferencia entre la lnea de base y Arquitectura Target.
Nota:
El anlisis de brechas se describe en la Parte III , 27. Anlisis 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 tambin 3.14 Arquitectura Gobernabilidad , Gobernanza 3.24 Negocios y A.60 Gobierno
Operacional en A. Glosario de definiciones complementarias .
Pgina23de670
TOGOF9.1
3.40 Informacin
Cualquier comunicacin o representacin de hechos, datos u opiniones, en cualquier medio o
forma, incluyendo textual, numrico, grfico, cartogrfico, la narrativa, o formas audiovisuales.
3,41 Tecnologa de la Informacin (IT)
1. La gestin del ciclo de vida de la informacin y la tecnologa relacionada utilizado por una
organizacin.
2. Un trmino general que incluye todas o algunas de las materias relacionadas con la
industria de la computacin, tales como la Continuidad del Negocio, Negocio Interfaz IT,
Business Process Modeling y Gestin, Comunicacin, Cumplimiento y Legislacin,
Informtica, Gestin de Contenidos, Hardware, Gestin de la Informacin, Internet ,
Offshoring, Redes, Programacin y Software, Asuntos Profesionales, Gestin de
Proyectos, Seguridad, Estndares, almacenamiento, voz y comunicaciones de
datos. Varios pases e industrias emplean otros trminos paraguas para describir esta
misma coleccin.
3. Un trmino comnmente asignada a un departamento dentro de una organizacin

encargada de aprovisionamiento de algunos o todos los dominios descritos en (2)
anteriormente.
4. Los nombres alternativos comnmente adoptadas incluyen Servicios de Informacin,

Gestin de la Informacin, et al.
3.42 Interoperabilidad
1. La capacidad de compartir informacin y servicios.
2. La capacidad de dos o ms sistemas o componentes para intercambiar y utilizar la

informacin.
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 Lgico
Una definicin independiente de la implementacin de la arquitectura, a menudo agrupar entidades
fsicas relacionadas en funcin de su finalidad y estructura. Por ejemplo, los productos de mltiples
proveedores de software de infraestructura pueden ser agrupados de forma lgica como
plataformas de servidor de aplicaciones Java.
Pgina24de670
TOGOF9.1
3.44 Metadatos
Los datos acerca de los datos, de cualquier tipo en cualquier medios de comunicacin,
que describe las caractersticas de una entidad.
3.45 Metamodel
Un modelo que describe cmo y con qu la arquitectura se describir de una manera estructurada.
3.46 Mtodo
Un enfoque repetible definida para hacer frente a un tipo particular de problema.
Ver tambin 3.47 Metodologa .
3.47 Metodologa
A definido, serie repetible de medidas para abordar un determinado tipo de problema, que por lo
general se centra en un proceso definido, pero tambin puede incluir la definicin de los
contenidos.
Ver tambin Mtodo 3,46 .
3.48 Modelo
Una representacin de un tema de inters. Un modelo proporciona una escala ms pequea y
simplificada, y / o representacin 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 inters particulares; es decir, sus "puntos de vista" en relacin con el tema en cuestin.
Ver tambin 3.68 Stakeholder , 3.75 Vista , y 3.76 Viewpoint .
3.49 Modelado
Una tcnica a travs de la construccin 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 organizacin utiliza para demostrar el progreso hacia una
meta; por ejemplo, "Aumentar la utilizacin de la capacidad en un 30% a finales de 2009 para
apoyar el aumento previsto en el mercado de la cuota ".
Pgina25de670
TOGOF9.1
3.51 Patrones
Una tcnica para poner bloques de construccin en su contexto; ., por ejemplo, para describir una
solucin reutilizable a un problema de construccin bloques son lo que usted utiliza: patrones
pueden decir cmo usarlos, cundo, por qu, y qu ventajas y desventajas que tiene que hacer
con ello.
3.52 Gestin del Rendimiento

El seguimiento, control y reporte de la ejecucin prctica de la arquitectura
empresarial. relacionados tambin con la mejora continua.
3.53 Fsica
Una descripcin de una entidad del mundo real. Elementos fsicos en una empresa de arquitectura
todava puede abstraerse considerablemente de Arquitectura de la solucin, diseo, o puntos de
vista de implementacin.
3.54 Plataforma
Una combinacin de productos de infraestructura de tecnologa y componentes que establece que
los requisitos para albergar software de aplicacin.
3.55 Plataforma de Servicios

Una capacidad tcnica 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 estndares o especificaciones que
apoyan ese ambiente consistentes. Un modelo de referencia se basa en un pequeo nmero de
conceptos unificadores y puede ser utilizado como base para la educacin y las normas que
explican a un no especialista. Un modelo de referencia no est directamente ligada a las normas,
tecnologas u otros detalles de implementacin concretos, pero s busca proporcionar semntica
comn que se pueden utilizar de forma inequvoca a travs y entre diferentes implementaciones.
Pgina26de670
TOGOF9.1
3.58 Repositorio
Un sistema que gestiona todos los datos de una empresa, incluidos los modelos de proceso de
datos y la informacin de la empresa y otra. Por lo tanto, los datos de un repositorio es mucho ms
extensa que la de un diccionario de datos, que por lo general slo define los datos que componen
una base de datos .
3.59 Requisito
Una declaracin 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 tecnologa, por lo general operan a travs de
mltiples disciplinas largo de varios aos. Normalmente se utiliza en las frases Technology
Roadmap, Arquitectura Roadmap, etc
3.61 Papel
1. La funcin habitual o esperado de un actor, o la parte que alguien o algo juega en una
accin o evento en particular. Un actor puede tener una serie de funciones.
2. La parte de un individuo desempea en una organizacin y la contribucin que hacen a

travs de la aplicacin de sus habilidades, conocimientos, experiencia y habilidades.
3.62 Segmento de Arquitectura

Una descripcin 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 Orientacin

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

. Un estilo arquitectnico que apoya la orientacin al servicio Tiene las siguientes caractersticas
distintivas:
Pgina27de670
TOGOF9.1
Se basa en el diseo de los servicios - que reflejan las actividades empresariales del
mundo real - que comprenden la empresa (o entre empresas) los procesos de negocio.
Representacin del Servicio utiliza descripciones empresariales para proporcionar el

contexto (es decir, los procesos de negocio, meta, regla, poltica, interfaz de servicio, y el
componente de servicio) e implementa servicios utilizando la orquestacin de servicios.
Coloca los requisitos nicos de la infraestructura -, se recomienda que las

implementaciones utilizan estndares abiertos para darse cuenta de la interoperabilidad y
la transparencia de ubicacin.
Las implementaciones son favorables al medio especfico - se ven limitados o habilitadas

por el contexto y deben ser descritas dentro de ese contexto.
Se requiere un gobierno fuerte de la representacin de servicios y la ejecucin.
Se requiere de una "prueba de fuego", lo que determina un "buen servicio".
3.65 Arquitectura de la solucin

Una descripcin de un discreto y se centr operacin o actividad mercantil y cmo SI / TI soporta
esa operacin. Una solucin de arquitectura tpicamente se aplica a un solo proyecto o proyecto de
liberacin, la asistencia en la traduccin de los requisitos en una solucin visin, negocio de alto
nivel y / o especificaciones de los sistemas de TI, y una cartera de competencias de ejecucin.
3.66 Solucin Mdulo (SBB)

Una solucin candidata que se ajusta a la especificacin de una Arquitectura Bloque de
construccin (ABB).
3.67 Soluciones Continuum

Una parte del Continuum Enterprise. Un repositorio de soluciones reutilizables para los futuros
esfuerzos de aplicacin. Contiene implementaciones de las definiciones correspondientes en la
Arquitectura Continuum.
3.68 Stakeholder
Un individuo, equipo u organizacin (o clases de los mismos) con intereses en, o preocupaciones
en relacin con el resultado de la arquitectura. Diferentes actores con diferentes roles tienen
diferentes preocupaciones.
3.69 Normas de Informacin 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 organizacin especfica.
Pgina28de670
TOGOF9.1
3.70 Arquitectura Estratgica

Un resumen descripcin formal de la empresa, proporcionando un marco de organizacin de la
actividad operativa y el cambio, y un nivel ejecutivo, visin a largo plazo para el ajuste de la
direccin.
3.71 Arquitectura Target

La descripcin de un estado futuro de la arquitectura est siendo desarrollado para una
organizacin. puede haber varios estados futuros desarrollados como hoja de ruta para mostrar la
evolucin de la arquitectura a un estado objetivo.
3.72 Taxonoma de Arquitectura Vistas

El conjunto organizado de todas las opiniones pertinentes para una arquitectura.
3.73 Tecnologa de Arquitectura

Una descripcin de la estructura y la interaccin de los servicios de la plataforma, y los
componentes lgicos y fsicos de la tecnologa.
Nota:
Tecnologa de la Arquitectura se describe en la Parte II , 12. Fase D: Architecture

Tecnologa .
3.74 Transicin Arquitectura

Una descripcin formal de un estado de la arquitectura en un punto de vista arquitectnico
significativa en el tiempo. Uno o ms arquitecturas de transicin puede ser usado para describir la
progresin en el tiempo desde la lnea base hasta la arquitectura destino.
3.75 Ver
La representacin 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 inters en la arquitectura. Un punto de vista no
tiene por qu ser visual o grfica en la naturaleza.
3.76 Punto de vista

Una definicin de la perspectiva desde la cual se tiene una vista. Es una especificacin de los
convenios para la construccin 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
Pgina29de670
TOGOF9.1
Un conjunto de acciones identificadas para alcanzar uno o ms objetivos para el negocio. Un

paquete de trabajo puede ser una parte de un proyecto, un proyecto completo, o un programa.
Pgina30de670
TOGOF9.1
4. Notas de la versin
A los efectos de TOGAF 9, las notas de la versin se proporcionan en este captulo se aplican.
4.1 Qu hay de nuevo en TOGAF 9?

En esta seccin se ofrece un panorama general de las principales caractersticas nuevas en
TOGAF 9.
Estructura Modular
Uno de los focos de TOGAF 9 desarrollo ha sido asegurar que el contenido de la especificacin 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 propsito definido (por oposicin a los "recursos" genricas).
La estructura modular de TOGAF se pretende contribuir a una mayor facilidad de uso, ya que cada
parte tiene un propsito definido y puede leerse de manera aislada como un stand-alone conjunto
de directrices. Se espera que la estructura modular para apoyar la adopcin gradual de la
especificacin TOGAF. Finalmente, la estructura modular soporta gestin de versiones ms
sofisticadas de la especificacin TOGAF. En el futuro, las partes individuales pueden evolucionar a
diferentes velocidades y la estructura actual especificacin tiene por objeto permitir cambios en un
rea que se llevan a cabo con un impacto limitado en toda la especificacin.
Marco de Contenido
Una importante adicin de nuevos contenidos a la especificacin 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 construccin arquitectnicos que representan los artefactos. La intencin de incluir un marco de
contenidos dentro de TOGAF es impulsar una mayor coherencia en las salidas que se crean
cuando se sigue un mtodo de desarrollo de la arquitectura (ADM).
La ventaja de incluir un marco de contenido se aplica a un nmero 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 podra crearse y en consecuencia reducir
el riesgo de brechas dentro de la arquitectura final conjunto entregable.
La segunda ventaja importante de la inclusin 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 estndares
arquitectnicos, trminos 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 inclusin de un marco contenido dentro de TOGAF es que
proporciona (por primera vez) un estndar abierto detallada de cmo se deben describir
Pgina31de670
TOGOF9.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 ms coherentes y mejor
comparabilidad entre las arquitecturas de referencia relacionados .
Orientacin extendido en adopcin TOGAF dentro de una empresa
Dentro de las organizaciones ms grandes, la prctica 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 especfico, en un ideal arquitecturas situacin se puede
considerar como un grupo con el fin de desarrollar una visin integrada global de cmo la empresa
est cambiando.
Esta versin de TOGAF cuenta con un amplio conjunto de conceptos y directrices para apoyar el
establecimiento de una jerarqua integrada de las arquitecturas estn siendo desarrollados por los
equipos que operan dentro de un modelo de gobernanza arquitectnico 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
especficas. TOGAF discute el concepto de la separacin y ofrece una variedad de
tcnicas y consideraciones de cmo particionar las diversas arquitecturas dentro de una
empresa.
Arquitectura Repositorio : TOGAF proporciona un modelo de informacin lgica para un

repositorio Arquitectura, que puede ser utilizado como un almacn integrado para todas las
salidas creados por la ejecucin de la ADM.
Marco Capacidad : Esta versin de TOGAF ofrece una definicin ms estructurado a la

organizacin, competencias, funciones y responsabilidades que se requieren para operar
una capacidad efectiva de arquitectura empresarial. Los nuevos materiales TOGAF
tambin proporcionan orientacin sobre un proceso que se puede seguir para identificar y
establecer una capacidad Arquitectura apropiado.
Consideracin explcita de estilos arquitectnicos, incluyendo SOA y Arquitectura de Seguridad
La nueva parte III: Directrices y Tcnicas ADM rene un conjunto de materiales que muestran con
ms detalle cmo el ADM se puede aplicar a las situaciones especficas de apoyo. Las nuevas
pautas discuten:
Los diversos usos de iteracin que son posibles dentro de la ADM y cuando cada tcnica
se deben aplicar
Los vnculos entre el TOGAF ADM y Arquitectura Orientada a Servicios (SOA)
Las consideraciones especficas que se requieren para hacer frente a la arquitectura de

seguridad dentro de la ADM
Pgina32de670
TOGOF9.1
Los diversos tipos de desarrollo de la arquitectura necesarios dentro de una empresa y

cmo se relacionan entre s
Detalle adicional ADM
Esta versin de la especificacin TOGAF incluye informacin ms detallada apoyo a la ejecucin

de la ADM. reas particulares de mejora son:
La fase preliminar, que cuenta con una gua extendida en el establecimiento de un marco
de arquitectura de la empresa y la planificacin para el desarrollo de la arquitectura. La
Fase Preliminar extendido tambin ofrece consejos para la definicin de un modelo de
gobernanza para la realizacin arquitectura beneficio y tambin analiza la vinculacin entre
TOGAF y otros marcos de gestin.
Las Oportunidades y fase Soluciones y planeamiento de migracin de fase, que cuentan

con un mtodo ms detallado y slido para la definicin y planificacin de transformacin
de la empresa, con base en los principios de la planificacin basada en la capacidad.
4.1.1 Los cambios aplicados en esta edicin
Esta edicin de TOGAF 9 incluye un conjunto de actualizaciones de mantenimiento en base a los

comentarios recibidos en la publicacin de 2009. . Un documento detallado por separado de los
cambios est disponible como TOGAF 9 Rectificacin Tcnica N 1 (Documento U112) se incluye
a continuacin una lista resumida de los cambios:
Se han eliminado las definiciones de los trminos en que el uso por TOGAF no es distintivo
de la definicin de diccionario comn.
El uso de los trminos "aplicacin" 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 terminologa para la transicin Arquitectura / Roadmap Estrategia /

Implementacin han aclarado y hecho consistente.
Los conceptos de niveles / iteraciones / particiones han aclarado y hecho consistente. Esto
incluye una reorganizacin de material en la parte III , 19. La aplicacin de la iteracin de
la ADM y 20. La aplicacin de la ADM a travs 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 tcnicas o una lista de pasos.
Los artefactos posibles (puntos de vista) para cada fase se muestran ahora en la
descripcin de esa fase, no slo en la Parte IV , 35. Architectural Artifacts .
Los trminos "artefacto" en comparacin con "punto de vista" se han aclarado y hecho
consistente. Esto incluye una reestructuracin de la Parte IV , 35.Architectural Artifacts .
El captulo 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.
Pgina33de670
TOGOF9.1
Texto introductorio adicional sobre los estilos arquitectnicos se ha aadido en la Parte

III , 18. Introduccin .
Pequeos cambios se han hecho para el captulo 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 construccin se ha eliminado.
La categorizacin de modelo de documento se ha eliminado.
Duplicar texto en varios lugares ha sido reemplazado con una referencia adecuada:
o Anlisis de brechas en las fases B, C y D ahora referencia a la Parte

III , 27. Anlisis Gap .
o Gestin de Requisitos en varias fases ahora hace referencia la parte II , 17.2.2

Requisitos para el Desarrollo en la fase de gestin de requisitos.
Algunos de los artefactos han sido renombrados para reflejar mejor su uso:
o Matriz System / Data se convierte en matriz de aplicaciones / datos
o Diagrama de clases ha sido reemplazado con el diagrama conceptual de datos y el

diagrama de lgica de datos
o Matriz del sistema / Organizacin convierte matriz Aplicacin / Organizacin
o Matriz de Papel / System convierte matriz Papel / Aplicacin
o Matriz de Sistema / Funcin convierte en matriz de Aplicacin / Funcin
o Diagrama Realizacin de proceso / sistema convierte diagrama Realizacin de

proceso / aplicacin
o Diagrama del sistema de casos de uso se convierte en el diagrama de casos de

uso de aplicaciones
o Matriz del sistema / tecnologa se convierte en matriz de Aplicacin / Tecnologa
La descripcin 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 slo una parte de los Principios
Empresariales.
El Stakeholder Mapa incorporado en el captulo de gestin de los interesados ( Parte

III , 24. Gestin de los grupos de inters ) que ahora se hace referencia explcita 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 inters actualizada.
Pgina34de670
TOGOF9.1
El captulo 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 captulo.
La relacin de la Enterprise Repository al Repositorio Arquitectura se aclara en la Parte

V , 41. Arquitectura Repositorio .
Los criterios de evaluacin y directrices se han eliminado de la Parte V , 42. Herramientas

para el desarrollo de la arquitectura .
El captulo sobre la Arquitectura de Madurez Modelos ( Parte VII , 51. Arquitectura de

Madurez Modelos ) ha sido revisada su redaccin para mantener la coherencia y la
claridad.
4.2 Los beneficios de TOGAF 9

TOGAF 9 proporciona un conjunto amplio de revisiones de la especificacin 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 especificacin
general. En primer lugar, la estructura modular de la especificacin hace que sea ms fcil para un
arquitecto para que considere la posibilidad de un aspecto especfico de la Capacidad de
Arquitectura. En todas las reas, la especificacin pretende agregar el detalle y la claridad por
encima y ms all de las versiones anteriores TOGAF.
Ms de enfoque sobre el cambio de empresa Holstica
TOGAF tiene una slida 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 gestin de todo el espectro de los cambios
necesarios para transformar una empresa hacia un modelo operativo de destino. TOGAF 9
contina esta evolucin e incorpora una perspectiva ms amplia de cambio que permite a la
arquitectura empresarial que se utiliza para especificar la transformacin a travs de los dominios
de negocio, datos, aplicaciones y tecnologa.
Ms Consistencia de salida
Las versiones anteriores de TOGAF centran en proporcionar un proceso coherente para el

desarrollo de arquitecturas. TOGAF 9 incluye una consideracin muy mejorada de los productos
arquitectnicos 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. Adems, las secciones de la empresa Continuum, Arquitectura
de particiones, y arquitectura de repositorio proporcionan orientacin detallada sobre cmo
entregables arquitectnicos pueden estar al alcance, rigen, e integradas.
Pgina35de670
TOGOF9.1
4.3 Mapeo de la Estructura TOGAF 8.1.1 a TOGAF 9

A continuacin se enumeran las partes de la especificacin TOGAF 8. Para cada parte, se da una
descripcin para explicar donde el contenido TOGAF 8 se puede encontrar dentro de la
especificacin actual.
Parte I: Introduccin
La parte de la especificacin Introduccin TOGAF 8.1.1 se ha utilizado como base para la creacin
de la Parte I: Introduccin . en TOGAF 9 La introduccin de TOGAF 9 refleja el contenido de
TOGAF 9 ms que el contenido de TOGAF 8.1.1, y tambin cuenta con una serie de mejoras para
mejorar la accesibilidad.
Parte II: Arquitectura Mtodo de Desarrollo
La esencia de la TOGAF 8.1.1 ADM se ha conservado en TOGAF 9. Parte II: Arquitectura Mtodo
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 (Captulo 16 de TOGAF 8.1.1) Fase TOGAF ADM se
han trasladado desde la seccin 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 mayora de las fases de ADM, que en su
mayor parte aade ms detalle y aclaracin 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 Tcnica TOGAF y Integrado de Informacin Infraestructura Modelo de referencia se
extraen y se colocan dentro de la Parte VI: Modelos de referencia TOGAF en TOGAF 9.
TOGAF 9 aade nuevos materiales que describen una aproximacin a la arquitectura de particin y
tambin proporciona un modelo estructurado de un Repositorio de Arquitectura. Estos conceptos
apoyan y elaboran en la intencin original de la empresa Continuum.
TOGAF 9 elimina la base de informacin de las Normas de la especificacin TOGAF. Sin embargo,
un ejemplo SIB permanece en el sitio web Open Group (www.opengroup.org ). El concepto de una
Base de Informacin de Normas es importante dentro de TOGAF, pero la amplitud y la velocidad
de los cambios de las normas arquitectnicas relevantes significa que no es prctico mantener una
coleccin actual y relevante de las normas dentro de una especificacin como TOGAF.
Parte IV: Base de Recursos
La base de recursos no est incluido en esta versin de TOGAF. Algunos elementos de la base de
recursos han quedado en desuso a partir de la especificacin TOGAF, pero todava estar
disponible en forma de Libro Blanco. Otros elementos de la base de recursos se han trasladado a
otras zonas de la especificacin.
Pgina36de670
TOGOF9.1
La siguiente tabla ilustra donde ahora se puede localizar TOGAF 8.1.1 Contenido base de
recursos.
TOGAF 8.1.1 Recursos Ubicacin actual

Architecture Board Trasladado a la Parte VII: Arquitectura del marco de
Capacidad
Arquitectura Cumplimiento Trasladado a la Parte VII: Arquitectura del marco de
Capacidad
Arquitectura contratos Trasladado a la Parte VII: Arquitectura del marco de
Capacidad
Arquitectura de Gobierno Trasladado a la Parte VII: Arquitectura del marco de
Capacidad
Modelos de Madurez Arquitectura Trasladado a la Parte VII: Arquitectura del marco de
Capacidad
Arquitectura Patrones Trasladado a la Parte III: Directrices y Tcnicas de ADM
Principios Arquitectura Trasladado a la Parte III: Directrices y Tcnicas de ADM
Arquitectura Skills Framework Trasladado a la Parte VII: Arquitectura del marco de
Capacidad
Desarrollo Arquitectura Vistas Elementos retenidos dentro de la Parte IV: Marco de
Arquitectura de contenido
Bloques de Construccin Elementos retenidos dentro de la Parte IV: Marco de
Vistas Dominio de procesos de negocio Elementos retenidos dentro de la Parte IV: Marco de
Escenarios empresariales Trasladado a la Parte III: Directrices y Tcnicas de ADM
Estudios de caso Eliminado. Estudios de caso estarn disponibles en el
sitio web Open Group.
Glosario Trasladado a la Parte I: Introduccin
Otras Arquitecturas y Marcos Eliminado. Este material estar disponible en el sitio web
de Open Group como un Libro Blanco.
Herramientas para el Desarrollo de la Trasladado a la Parte V: Empresa Continuum y
Arquitectura Herramientas
ADM y el Marco Zachman 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 captulos se asignan a los de TOGAF 8.1.1:
TOGAF 9 Captulo Derivacin de TOGAF 8.1.1

Parte I: Introduccin
1 Introduccin Material revisado; basado en el captulo 1
2 Conceptos Bsicos Nuevo captulo
3 Definiciones El material derivado de Captulo 36, vuelto a trabajar en
las definiciones formales y abreviaturas secciones
4 Notas de la versin Nuevo captulo
Parte II: Arquitectura Mtodo de Desarrollo
5 Introduccin Material revisado; basado en el Captulo 3
6 Fase Preliminar Material revisado; basado en el Captulo 4
7 Fase A: Architecture Vision Material revisado; basado en el Captulo 5
8 Fase B: Arquitectura de Negocios Material revisado; basado en el Captulo 6
Pgina37de670
TOGOF9.1
9 Fase C: Arquitecturas de Sistemas de Material revisado; basado en el Captulo 7

Informacin
10 Fase C: Arquitectura de Datos Material revisado; basado en el Captulo 8
11 Fase C: Arquitectura de aplicaciones Material revisado; basado en el Captulo 9
12 Fase D: Architecture Tecnologa Material revisado; basado en el captulo 10
13 Fase E: Oportunidades y Soluciones Material revisado; basado en el captulo 11
14 Fase C: planeamiento de migracin Material revisado; basado en el Captulo 12
15 Fase G: Gobernanza Aplicacin Material revisado; basado en el captulo 13
16 Fase H: Gestin Arquitectura Cambio Material revisado; basado en el captulo 14
17 ADM Arquitectura Gestin de Requisitos Ningn cambio material; mapas del captulo 15
Parte III: Directrices y Tcnicas de ADM
18 Introduccin Nuevo captulo
19 La aplicacin de la ADM a travs de la Nuevo captulo
Arquitectura del Paisaje
20 La aplicacin de la ADM en los diferentes Nuevo captulo
niveles de la empresa
21 Arquitectura de Seguridad y el ADM Nuevo captulo; derivado del Libro Blanco de Seguridad
(W055)
22 Usando TOGAF para definir y Gobierno SOAs Nuevo captulo
23 Principios Arquitectura Ningn cambio material; mapas del captulo 29
24 Gestin de las partes interesadas Nuevo captulo
25 Arquitectura Patrones Ningn cambio material; mapas del captulo 28
26 Escenarios empresariales Ningn cambio material; mapas para el Captulo 34
27 Anlisis Gap Nuevo captulo; derivado del anlisis de las deficiencias
28 Tcnicas de Planificacin Migracin Nuevo captulo
29 Requisitos de interoperabilidad Nuevo captulo
30 Evaluacin de la preparacin de Nuevo captulo
transformacin de negocios
31 Gestin de Riesgos Nuevo captulo
32 Planificacin de Capacidad basada en Nuevo captulo
Parte IV: Marco de Arquitectura de
contenido
34 Metamodel contenido Nuevo captulo
35 Architectural Artifacts Derivado del captulo 31, adems de nuevo material
36 Arquitectura Entregables Revisado; era Captulo 16
37 Bloques de Construccin Revisado del captulo 32
Parte V: Empresa Continuum y
Herramientas
39 Continuum Empresarial Derivado de los captulos 17 y 18 con las revisiones
sustanciales
40 Arquitectura Particiones Nuevo captulo
41 Arquitectura Repositorio Nuevo captulo
42 Herramientas para el Desarrollo de la Derivado del Captulo 38, con las directrices de
Arquitectura evaluacin eliminados.
Parte VI: Modelos TOGAF Referencia
43 Fundacin Arquitectura: Tcnico Ningn cambio material; Los mapas de los Captulos 19
Modelo de Referencia y 20
44 Integrado de Informacin Infraestructura Ningn cambio material; mapas del captulo 22
Modelo de Referencia
Parte VII: Arquitectura del marco de
Capacidad
46 Establecer una capacidad de Arquitectura Nuevo captulo
Pgina38de670
TOGOF9.1
47 Architecture Board Con cambios mnimos; mapas del captulo 23

48 Arquitectura Cumplimiento Con cambios mnimos; mapas para el Captulo 24
49 Arquitectura contratos Con cambios mnimos; mapas para el Captulo 25
50 Arquitectura de Gobierno Con cambios mnimos, se asigna al Captulo 26
51 Modelos de Madurez Arquitectura Con cambios mnimos; mapas del captulo 27
52 Arquitectura Skills Framework Algunos cambios cosmticos; mapas del captulo 30
La Glosario de Definiciones complementarias Derivado del Captulo 36
B Abreviaturas Derivado del Captulo 36
4.5 Utilizar TOGAF
4.5.1 Condiciones de uso
La documentacin TOGAF est libremente disponible para ver en lnea sin

licencia. Alternativamente, el conjunto completo de documentacin TOGAF puede ser descargado
y almacenado bajo licencia, como se explica en el sitio web la informacin TOGAF.
En cualquier caso, la documentacin TOGAF puede ser utilizado libremente por cualquier
organizacin que as lo deseen para desarrollar una arquitectura para su uso dentro de esa
organizacin. Ninguna parte de ella puede ser reproducida, almacenada en un sistema de
recuperacin, o transmitida de ninguna forma ni por ningn medio, ya sea electrnico, mecnico,
fotocopia, grabacin, o de otra manera, para cualquier otro propsito, incluyendo, pero no a modo
de limitacin, cualquier utilizacin con fines comerciales, sin el permiso previo de los propietarios
de derechos de autor.
4.5.2 Cunto 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
informacin para reducir las barreras de la integracin de las nuevas tecnologas en la
empresa. Su objetivo es hacer realidad la visin de Flujo de informacin 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 prcticos y la experiencia
de su uso realimenta a ayudar a mejorarlo.
Por tanto, el Open Group publica TOGAF en su servidor web pblico, y permite y alienta la
reproduccin y el uso libre de cargo por cualquier organizacin que desee utilizarlo internamente
para desarrollar una arquitectura empresarial. (Existen restricciones para su explotacin comercial,
sin embargo, ver 4.5.1 Condiciones de uso .)
4.5.3 Descargas
Descargas de la documentacin TOGAF, incluyendo un archivo PDF para imprimir, estn

disponibles bajo licencia desde el sitio web la informacin TOGAF (consultewww.opengroup.org /
Arquitectura / togaf ). La licencia es libre para cualquier organizacin que desee utilizar TOGAF
exclusivamente para fines internos (por ejemplo, para desarrollar una empresa de arquitectura para
su uso dentro de la organizacin).
Pgina39de670
TOGOF9.1
4.6 Por qu unirse The Open Group?

Las organizaciones que deseen reducir el tiempo, costo y riesgo de la implementacin de
soluciones de mltiples proveedores que se integran dentro de y entre las empresas necesitan The
Open Group como su socio clave.
The Open Group rene a los compradores y proveedores de sistemas de informacin 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 ms fcil la integracin de TI en toda la empresa. TOGAF
es un factor clave en esta tarea.
S, s TOGAF est disponible gratuitamente. Pero, cunto va a gastar en el desarrollo o la

actualizacin de su arquitectura empresarial utilizando TOGAF? Y cunto va a gastar en
adquisiciones en base a que la arquitectura? El precio de la membresa de The Open Group es
insignificante en comparacin con estas cantidades.
Adems 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 informacin y la retroalimentacin.
Los miembros de la ganancia Architecture Forum:
Acceso inmediato a los frutos del actual programa de trabajo TOGAF (no disponible para el
pblico hasta la publicacin de la prxima edicin del documento TOGAF) - de hecho, la
ltima informacin sobre TOGAF
El intercambio de experiencias con otras organizaciones de clientes y proveedores que

participan en la arquitectura empresarial en general, y la creacin de redes con los
arquitectos que utilizan TOGAF en proyectos de desarrollo de arquitectura importantes de
todo el mundo
La revisin por pares de la caja material de estudio arquitectura especfica
Pgina40de670

Togaf 9 1 Parte I

Diunggah oleh

Informasi Dokumen

Judul Asli

Hak Cipta

Format Tersedia

Bagikan dokumen Ini

Bagikan atau Tanam Dokumen

Opsi Berbagi

Apakah menurut Anda dokumen ini bermanfaat?

Apakah konten ini tidak pantas?

Hak Cipta:

Format Tersedia

Togaf 9 1 Parte I

Diunggah oleh

Hak Cipta:

Format Tersedia

The Open Group Architecture Framework

El desarrollo original de TOGAF Versin 1 en 1995 se bas en el Marco de Arquitectura Tcnica

Si usted es nuevo en el campo de la arquitectura de la empresa y / o TOGAF, se recomienda leer

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

Figura 1-1: Estructura del documento TOGAF

1.2 Resumen Ejecutivo

El trmino "empresa" en el contexto de la "arquitectura de la empresa" puede ser utilizado para

El concepto de modelo de funcionamiento empresarial es til para determinar la naturaleza y

Por qu necesito una empresa de arquitectura?

El propsito de la arquitectura de la empresa es la optimizacin de toda la empresa el legado

CEOs de hoy saben que la gestin y explotacin de la informacin eficaz a travs de TI es un

Una operacin de negocio ms eficiente:

o Menores costos de operacin de negocios

o Capacidades empresariales compartidos a travs de la organizacin

o Costos de gestin del cambio Inferior

o Fuerza de trabajo ms flexible

o Mejora de la productividad de las empresas

Una operacin de TI ms eficiente:

o Bajo desarrollo de software, soporte y mantenimiento de los costos

o El aumento de la portabilidad de las aplicaciones

o Interoperabilidad mejorada y ms fcil sistema y red de gestin

o Mejora de la capacidad para abordar cuestiones crticas a nivel de empresa como

o Ms fcil actualizacin y el intercambio de los componentes del sistema

Mejor retorno de la inversin existente, menor riesgo para la inversin futura:

o Reduccin de la complejidad en el negocio y TI

o Mximo rendimiento de la inversin en la infraestructura de TI de negocios

o La flexibilidad de hacer, comprar o subcontratar las soluciones de negocio y de TI

o Reduccin del riesgo general en las nuevas inversiones y su coste de propiedad

Ms rpido, ms sencillo y ms barato de adquisiciones:

o Las decisiones de compra son ms simples, ya que la informacin que rige la

o El proceso de contratacin es ms rpido - maximizar la velocidad de adquisicin y

o La capacidad de suministro de los sistemas abiertos heterogneos de mltiples

o La capacidad de asegurar las capacidades ms econmicos

Especficamente, qu me incitara a desarrollar una empresa de arquitectura?

Por lo general, la preparacin para las necesidades de transformacin de negocios o de cambios

La identificacin y el perfeccionamiento de los requisitos que los interesados tienen

Desarrollo de vistas de la arquitectura que muestran cmo las preocupaciones y

Mostrando las compensaciones que se van a realizar en la conciliacin de los intereses

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

Por qu necesito TOGAF como marco para la arquitectura de la empresa?

TOGAF se ha desarrollado gracias a la colaboracin de ms de 300 empresas miembros del Foro

Desarrollar y mantener una empresa de arquitectura es un proceso tcnicamente complejo que

Quin se beneficiara del uso de TOGAF?

Toda empresa de organizacin o planificacin para llevar a cabo el desarrollo e implementacin

Las organizaciones que disean e implementan arquitecturas empresariales utilizando TOGAF

2.2 Qu es la arquitectura en el contexto de TOGAF?

TOGAF abarca pero no se adhiere estrictamente a la norma ISO / IEC 42010:2007

1. Una descripcin formal de un sistema, o un plan detallado del sistema a nivel de

2. La estructura de los componentes, sus interrelaciones, y los principios y directrices que

2.3 Qu tipo de arquitectura TOGAF El trato con?

La arquitectura de negocio define la estrategia empresarial, el gobierno, la organizacin y

La Arquitectura de Datos describe la estructura de los activos de datos lgicos y fsicos

La Arquitectura de la aplicacin proporciona un modelo para las aplicaciones

La Tecnologa de la Arquitectura describe las capacidades de software y hardware

2.4 Arquitectura Mtodo de Desarrollo

Fases dentro de la ADM son los siguientes:

La fase preliminar describe las actividades de preparacin e iniciacin necesarios para

Fase A: Arquitectura Visin describe la fase inicial de un ciclo de desarrollo de la

Fase B: Arquitectura de Negocios describe el desarrollo de una arquitectura de

Fase C: Sistemas de Informacin Arquitecturas describe el desarrollo de Sistemas de

Fase D: Architecture Tecnologa describe el desarrollo de la arquitectura de la