1 - TOGAF Version 9.1 A Pocket Guide (PDFDrive - Com) .En - Es

Edición PDF personales
TOGAF ® versión 9.1

Una guía de bolsillo
Edición PDF personal. No para su redistribución

TOGAF ® Versión 9.1 - Una Guía de bolsillo
Copyright © 2009-2011, The Open Group
Todos los derechos reservados.
Ninguna parte de esta publicación puede ser reproducida, almacenada en un sistema de recuperación, o transmitida, en cualquier forma o por cualquier medio,
electrónico, mecánico, de fotocopiado, de grabación, o de otra manera, sin la previa autorización del propietario del copyright.
Las opiniones expresadas en este documento no son necesariamente las de cualquier miembro particular de The Open Group.
En caso de cualquier discrepancia entre el texto de este documento y la documentación oficial TOGAF, la documentación TOGAF sigue
siendo la versión autorizada para la certificación, pruebas de examen, y para otros fines. La documentación oficial TOGAF se puede
obtener en línea en www.opengroup.org/togaf .
TOGAF ® versión 9.1
Una guía de bolsillo
Número de documento: G117
Publicado por The Open Group, diciembre de 2011.
Comentarios relativos a los materiales contenidos en este documento pueden ser enviadas a:
La lectura Open
Group Apex Plaza
Forbury carretera
Berkshire, RG1 1AX

Reino Unido
o por correo electrónico a:
[email protected]
ii Copyright © 2009-2011 The Open Group. Todos los derechos reservados. Guía (2011)

Contenido
Capítulo 1 Introducción ................................................. .................................................. ..................... 1
1.1 Introducción a TOGAF ............................................... ............................................ 1
1.2 Estructura del documento TOGAF ............................................. ............................ 1
1.3 ¿Qué es la Arquitectura en el contexto de TOGAF? .................................................. 2 ..
1.4 ¿Qué tipo de arquitectura no tratar con TOGAF? .............................................. 3
1.5 ¿Qué contiene TOGAF? .................................................. ................................. 3
1.5.1 El Método de Desarrollo de Arquitectura (ADM) ....................................... 4
1.5.2 Directrices y técnicas ADM .............................................. ............... 5
1.5.3 Marco contenido Arquitectura ............................................... ............... 5
1.5.4 La empresa Continuum ............................................... ......................... 5
1.5.5 Modelos de referencia TOGAF ............................................... ........................ 5
1.5.6 El Marco de Arquitectura Capacidad .............................................. 6 .....
Capitulo 2 El método de desarrollo Arquitectura .............................................. ............................... 7

2.1 ¿Cuál es el ADM? .................................................. ................................................. 7
2.2 ¿Cuáles son las fases de la ADM? .................................................. ......................... 7
2.3 El ADM en detalle .............................................. .................................................. 10
2.3.1 Fase Preliminar ................................................ .................................... 10
2.3.2 Fase A: Architecture Vision ............................................. ..................... 12
2.3.3 Fase B: Arquitectura de Negocios ............................................. .................. 14
2.3.4 Fase C: Arquitecturas de Sistemas de Información .......................................... 15
2.3.5 Fase D: Arquitectura Tecnología ............................................. ............. 18
2.3.6 Fase E: Oportunidades y Soluciones ............................................ ......... 19
2.3.7 Fase F: planeamiento de migración ............................................. ...................... 20
2.3.8 Fase G: Implementación de Gobierno ............................................. ....... 21
2.3.9 Fase H: Arquitectura de Gestión del Cambio ........................................... 22
2.3.10 Gestión de requerimientos ................................................ ..................... 23
2.4 La determinación del alcance de la Actividad Arquitectura .............................................. ........................... 23
Capítulo 3 Las técnicas y los entregables del Ciclo ADM clave .......................................... ........... 25
3.1 A medida arquitectura marco ............................................... .......................... 27
3.2 Modelo de organización de la arquitectura empresarial ............................................. ... 27
3.3 Principios de Arquitectura ................................................ .......................................... 28
3.3.1 El desarrollo de principios de arquitectura ............................................... ......... 28
3.3.2 La definición de principios de arquitectura ............................................... .............. 29
3.3.3 Cualidades de Principios ............................................... .............................. 29
3.3.4 Aplicación de los principios Arquitectura ............................................... ............. 30
3.4 Principios de Actuación, los objetivos de negocio, y el negocio controladores .................................. 31
3.5 Arquitectura Repositorio ................................................ ......................................... 31
3.6 Herramientas de arquitectura ................................................ ................................................. 32
3.7 Solicitud de Trabajo Arquitectura .............................................. ................................ 32
3.8 Declaración de Arquitectura Trabajo .............................................. .............................. 32
3.9 Architecture Vision ................................................ ................................................ 33
3.10 Gestión de los interesados ................................................ ...................................... 34
3.10.1 Pasos en el proceso de gestión de los grupos de interés ....................................... 34
3.11 Plan de comunicaciones ................................................ ............................................ 36
3.12 Transformación de Negocios Evaluación de la Preparación .............................................. .... 37
Guía (2011) Copyright © 2009-2011 The Open Group. Todos los derechos reservados. iii

3.13 Evaluación de la capacidad ................................................ ........................................... 37

3.14 Gestión de riesgos ................................................ .................................................. 38
3.15 Arquitectura definición de documento ............................................... ......................... 39
3.15.1 Arquitectura de Negocios ................................................ .............................. 40
3.15.2 Arquitecturas de Sistemas de Información ............................................... .......... 41
3.15.3 Arquitectura Tecnología ................................................ ......................... 41
3.16 Requisitos Arquitectura Especificación ............................................... ............... 42
3.16.1 Requisitos de la arquitectura de negocio ............................................... ........ 42
3.16.2 Requisitos de Sistemas de Información Arquitecturas .................................. 43
3.16.3 Requisitos Tecnología Arquitectura ............................................... ... 43
3.16.4 Requisitos de interoperabilidad ................................................ ................. 43
3.17 Arquitectura Hoja de Ruta ................................................ ........................................... 43
3.18 Los escenarios de negocio ................................................ ................................................ 45
3.19 Análisis de las deficiencias ................................................ .................................................. ....... 45
3.20 Puntos de vista de arquitectura ................................................ ........................................ 47
3.21 Arquitectura Vistas ................................................ ................................................ 48
3.21.1 Vistas desarrollar en el ADM ............................................. .................. 49
3.22 Arquitectura Building Blocks ............................................... ................................. 49
3.23 Solución Building Blocks ............................................... ........................................ 49
3.24 Capacidad de planificación basada en .............................................. ...................................... 50
3.25 Técnicas de planificación de la migración ............................................... .............................. 51
3.25.1 Evaluación de la instrumentación Factor y Matrix Deducción ..................... 51
3.25.2 Las lagunas consolidados, soluciones y Dependencias Matrix ....................... 51
3.25.3 Arquitectura Definición Incrementos Tabla .............................................. . 52
3.25.4 Arquitectura transición Estado Tabla Evolución ........................................ 52
3.25.5 Técnica de Evaluación de negocios Valor .............................................. ..... 53
3.26 Implementación y Plan de Migración .............................................. ........................ 54
3.27 Arquitectura transición ................................................ .......................................... 55
3.28 Implementación Modelo de Gobierno ............................................... ....................... 55
3.29 Los contratos Arquitectura ................................................ ........................................... 56
3.30 Solicitud de cambio ................................................ .................................................. ... 57
3.31 Evaluación del cumplimiento ................................................ ........................................ 58
3.32 Requisitos de Evaluación de Impacto ............................................... .......................... 59
Capítulo 4 Directrices para la adaptación de la ADM ............................................. ...................................... 60
4.1 Introducción ................................................. .................................................. ........ 60

4.2 La aplicación de iteración a la ADM ............................................. ................................ 61
4.3 La aplicación de la ADM a través de la arquitectura del paisaje ........................................ 65
4.4 Arquitectura de Seguridad y el ADM ............................................. ......................... 66
4.5 El uso de TOGAF para definir y Govern SOA ........................................... .............. 67
4.5.1 El uso de TOGAF para SOA .............................................. ............................ 69
Capítulo 5 Marco contenido Arquitectura ............................................... ...................................... 70

5.1 Arquitectura de contenido del esquema general .............................................. ............ 70
5.2 Metamodel contenido ................................................ ............................................... 71
5.2.1 Núcleo y las extensiones ............................................... ................................. 72
5.2.2 Catálogos, matrices y diagramas ............................................ ............... 72
5.3 Los artefactos arquitectónicos ................................................ ........................................... 73
5.4 Arquitectura entregables ................................................ ...................................... 76
5.5 Bloques de construcción ................................................ .................................................. ... 76
Capítulo 6 La empresa Continuum ............................................... ................................................ 78

6.1 Descripción general de la empresa Continuum ............................................. .................... 78
6.1.1 El Continuum Empresa y Arquitectura reutilización .............................. 79
6.1.2 Se utilice la empresa Continuum dentro del ADM .................................. 79
iv Copyright © 2009-2011 The Open Group. Todos los derechos reservados. Guía (2011)

6.2 Arquitectura Partición ................................................ ....................................... 79

6.3 Arquitectura Repositorio ................................................ ......................................... 81
6.3.1 El Enterprise Repository ............................................... ........................ 82
Capítulo 7 Modelos de referencia TOGAF ............................................... ............................................... 83

7.1 TOGAF Fundación Arquitectura ............................................... ........................... 83
7.1.1 Technical Reference Model (TRM) ............................................ ............ 83
7.2 Información Integrado Modelo de Referencia de Infraestructura (III-RM) ......................... 84
Capítulo 8 Marco de Capacidad de la arquitectura ............................................... .................................. 85

8.1 Establecer una capacidad de Arquitectura .............................................. .................. 86
8.2 Arquitectura de Gobierno ................................................ ....................................... 87
8.3 Architecture Board ................................................ ................................................ 87
8.4 Arquitectura Cumplimiento ................................................ ....................................... 88
8.5 Arquitectura Marco Habilidades ............................................... ............................... 89
Apéndice A Resumen de migración ................................................ .................................................. ....... 90

A.1 Los cambios entre TOGAF 8.1.1 y 9.1 TOGAF ......................................... ........ 90
A.2 Resumen de los cambios entre TOGAF 9 y TOGAF 9.1 .................................. 96
Guía (2011) Copyright © 2009-2011 The Open Group. Todos los derechos reservados. v

Prefacio
Este documento
Esta es la Guía de bolsillo TOGAF, un grupo abierto estándar, versión 9.1. Su objetivo es ayudar a los arquitectos se centran en las
operaciones eficientes y efectivas de su organización y los altos directivos a entender los conceptos básicos de TOGAF. Está
organizado de la siguiente manera:
• Capítulo 1 proporciona una vista de alto nivel de TOGAF, arquitectura de la empresa, y el contenido y los conceptos clave de
TOGAF.
• El capítulo 2 proporciona una introducción al método de arquitectura de Desarrollo (ADM), el método que proporciona
TOGAF para desarrollar arquitecturas empresariales.
• Capítulo 3 proporciona una visión general de las técnicas y resultados clave del ciclo de ADM.
• Capítulo 4 proporciona una visión general de las directrices para la adaptación de la ADM.
• Capítulo 5 proporciona una introducción al marco de arquitectura de contenidos, un metamodelo estructurado para los
artefactos arquitectónicos.
• Capítulo 6 proporciona una introducción a la empresa Continuum, un concepto de alto nivel que se puede utilizar con el ADM
para desarrollar una arquitectura empresarial.
• El capítulo 7 proporciona una introducción a los modelos de referencia TOGAF, incluyendo la Fundación Arquitectura
TOGAF y el Modelo de Referencia de Infraestructura de Información Integrado (III-RM).
• Capítulo 8 proporciona una introducción al Marco de Arquitectura de capacidad, un conjunto de recursos proporcionados para el
establecimiento y funcionamiento de una función de la arquitectura dentro de una empresa.
• Apéndice A proporciona una visión general de las diferencias entre TOGAF 9.1 y TOGAF
8.1.1, y también un resumen de los cambios entre TOGAF 9 y 9,1.
La audiencia de este documento es:
• arquitectos de la empresa, arquitectos, arquitectos de negocio de TI, arquitectos de datos, arquitectos de sistemas, arquitectos de
soluciones, y altos directivos que buscan una primera introducción a TOGAF
No es necesario un conocimiento previo de la arquitectura empresarial. Después de leer este documento, el lector que desee más
información debe consultar la documentación TOGAF 1 disponible en línea en www.opengroup.org/architecture/togaf9-doc/arch y
también está disponible un libro en papel.
1 TOGAF, Versión 9.1 (ISBN: 978 90 8753 679 4, G116); Referirse a www.opengroup.org/bookstore/catalog/g116.htm .
vi Copyright © 2009-2011 The Open Group. Todos los derechos reservados. Guía (2011)

Sobre TOGAF Versión 9.1
TOGAF 9.1 es una actualización de mantenimiento de TOGAF 9, examinar las observaciones planteadas desde la introducción de
TOGAF 9 en 2009. Esto mantiene las características y estructura de TOGAF 9, que incluye:
Estructura modular: TOGAF 9 tiene una estructura modular. La estructura modular soporta:
• Una mayor facilidad de uso - propósito definido para cada parte; se puede utilizar de forma aislada como un conjunto independiente de
directrices
• adopción incremental de la especificación TOGAF
Marco de contenido: TOGAF 9 incluye un marco de contenido para conducir una mayor consistencia en las salidas que se crean
cuando se sigue el método de desarrollo Architecture (ADM). El marco de contenido TOGAF proporciona un modelo detallado de
los productos de trabajo de arquitectura.
Orientación extendida: TOGAF 9 cuenta con un extenso conjunto de conceptos y directrices para apoyar el establecimiento de
una jerarquía integrada de arquitecturas siendo desarrollado por los equipos dentro de grandes organizaciones que operan
dentro de un modelo de gobierno de arquitectura global. En particular, se introducen los siguientes conceptos:
• Particionamiento: Un número de técnicas y consideraciones de cómo particionar las diversas arquitecturas dentro de
una empresa.
• Arquitectura Repositorio: Un modelo de información lógica para un repositorio de arquitectura que puede ser utilizado como una tienda
integrada para todas las salidas creados por la ejecución de la ADM.
• Marco de la capacidad: Una definición estructurada de la organización, habilidades, roles y responsabilidades necesarias para
operar una capacidad de arquitectura empresarial efectiva. TOGAF también proporciona orientación sobre un proceso que se
puede seguir para identificar y establecer una capacidad de arquitectura apropiada.
Estilos arquitectonicos: TOGAF 9, en la Parte III: Directrices ADM y Técnicas, reúne un conjunto de materiales que
muestran en detalle cómo el ADM se puede aplicar a situaciones específicas de apoyo:
• Los usos variados de iteración que son posibles dentro del ADM y cuando cada técnica se debe aplicar
• Los vínculos entre el TOGAF ADM y arquitectura orientada a servicios (SOA)
• Las consideraciones específicas necesarias para hacer frente a la arquitectura de seguridad dentro de la ADM
• Los diversos tipos de desarrollo de la arquitectura requiere dentro de una empresa y cómo se relacionan entre sí
ADM adicional detalle: TOGAF 9 incluye información detallada adicional sobre las versiones anteriores de TOGAF
para soportar la ejecución de la ADM. Las áreas particulares de mejora son:
• Las características fase preliminar extendieron orientación sobre el establecimiento de una capacidad de arquitectura de la empresa y la
planificación para el desarrollo de la arquitectura.
Guía (2011) Copyright © 2009-2011 The Open Group. Todos los derechos reservados. vii

• Las oportunidades y soluciones y fases de planeamiento de migración cuentan con un método detallado y robusto para la definición y
planificación de transformación de la empresa.
Convenciones utilizadas en este documento
Las siguientes convenciones se usan en este documento con el fin de ayudar a identificar la información importante y evitar la
confusión sobre el significado deseado:
• Los puntos suspensivos (...)
Indica una continuación; tales como una lista incompleta de ejemplo artículos, o una continuación de precedente texto.
• Negrita
Se utiliza para resaltar los términos específicos.
• Cursiva
Se utiliza para dar énfasis. También puede hacer referencia a otros documentos externos.
Acerca de The Open Group
The Open Group es un consorcio global que permite el logro de los objetivos de negocio a través de estándares de TI. Con más de
375 organizaciones miembros, The Open Group tiene una membresía diversa que abarca todos los sectores de la comunidad de TI
- clientes, proveedores de sistemas y soluciones, los proveedores de herramientas, integradores y consultores, así como
académicos e investigadores - a:
• Captura, comprender y abordar las necesidades actuales y emergentes, y establecer políticas y compartir las mejores
prácticas
• Facilitar la interoperabilidad, el desarrollo de consenso, y evolucionar e integrar las especificaciones y tecnologías de código
abierto
• Ofrecer un conjunto integral de servicios para mejorar la eficiencia operativa de los consorcios
• Operar la industria "s de servicios de certificación Premier
Para más información sobre The Open Group está disponible en www.opengroup.org .
The Open Group tiene más de 15 años de experiencia "en el desarrollo y funcionamiento de los programas de certificación y tiene una
amplia experiencia en el desarrollo y facilitar la adopción de la industria de pruebas utilizadas para validar la conformidad con una
norma o especificación abierta.
The Open Group publica una amplia gama de documentación técnica, la mayoría de los cuales se centra en el desarrollo de
Normas y Guías grupo abierto, pero que también incluye documentos técnicos, estudios técnicos, certificación y documentación
de pruebas y títulos comerciales.
Un catálogo está disponible en www.opengroup.org/bookstore .
viii Copyright © 2009-2011 The Open Group. Todos los derechos reservados. Guía (2011)

Marcas comerciales
Información sin fronteras Flow ™ es una marca comercial y ArchiMate ®, Jericho Forum ®, Making Standards Work ®, Motivo ®, OSF
/ 1 ®, The Open Group ®, TOGAF ®, UNIX ®, y el '' dispositivo `` X son marcas registradas de The Open Group en los Estados
Unidos y en otros países.
Todas las demás marcas, compañías y nombres de productos se utilizan sólo con fines de identificación y pueden ser marcas comerciales que
son propiedad exclusiva de sus respectivos dueños.
Guía (2011) Copyright © 2009-2011 The Open Group. Todos los derechos reservados. ix

Sobre los autores

Andrew Josey, The Open Group
Andrew Josey es Director de Normas dentro de The Open Group. Actualmente se está gestionando el proceso de las normas
de The Open Group, y ha dado lugar recientemente a los proyectos de desarrollo de normas para TOGAF 9 y 9.1, IEEE Std
1003,1 a 2008 (POSIX), y las especificaciones básicas de la Single UNIX Specification, versión 4. Anteriormente, que ha dado
lugar al desarrollo y funcionamiento de muchos de los proyectos de desarrollo certificación del Open Group, incluyendo los
programas de certificación de toda la industria para el sistema UNIX, Linux Standard Base, TOGAF, e IEEE POSIX. Es
miembro de la IEEE, USENIX, UKUUG, y la Asociación de Enterprise Architects (AEA).
Profesor Rachel Harrison, Universidad de Oxford Brookes
Rachel Harrison es un profesor de informática en el Departamento de Informática y Tecnologías de la Comunicación en la

Universidad de Oxford Brookes. Anteriormente fue profesor de informática, Jefe del Departamento de Informática y Director
de Investigación de la Facultad de Ingeniería de Sistemas en la Universidad de Reading. Sus intereses de investigación
incluyen la evolución de los sistemas, las métricas de software, ingeniería de requisitos, arquitectura de software,
usabilidad y pruebas de software. Ha publicado más de 100 artículos con arbitraje y consultados ampliamente con la
industria, trabajando con organizaciones como IBM, el DERA, Philips Research Labs, sistemas críticos Praxis, y The Open
Group. Ella es Editor en Jefe de la Calidad de Software Journal, publicado por Springer. Ella es la autora de las guías de
estudio para el programa de certificación TOGAF 9.
Paul Homan, IBM
Paul Homan es un consultor de Estrategia de Tecnología en IBM "s Global Business Services. Él es un arquitecto Master
Certificado, especializada en arquitectura de la empresa con más de 20 años de experiencia en TI ". Muy apasionada y
prácticamente con experiencia en la arquitectura, la estrategia, la autoridad de diseño, y las áreas de gobierno, Paul está
especialmente interesado en el liderazgo de la arquitectura empresarial, gestión de requisitos, y la arquitectura de negocios. Se
unió a IBM desde entornos de usuario final, después de haber trabajado como arquitecto jefe, tanto en la Oficina de Correos del
Reino Unido y Royal Mail. Él no sólo ha establecido prácticas de arquitectura de la empresa, sino que también ha vivido con los
resultados! Desde su incorporación a IBM, Paul ha dedicado su tiempo a ambos asesoramiento a clientes sobre la capacidad
de la arquitectura, así como los principales esfuerzos de la configuración en forma activa los programas cliente de gran tamaño.
X Copyright © 2009-2011 The Open Group. Todos los derechos reservados. Guía (2011)

Matthew F. Rouse, Hewlett-Packard
Mateo Rouse es un EA en HP Enterprise Services. Mateo tiene más de 20 años "IS / IT experiencia en desarrollo de
aplicaciones, arquitectura de sistemas, IS / estrategia de TI y arquitectura de la empresa. Él aporta su experiencia en
estratégica de SI / TI y la arquitectura planeando para asegurar que las empresas a alinear sus inversiones de SI / TI con
sus objetivos de negocio. Matthew es un Chartered TI miembro profesional de la British Computer Society, un maestro
arquitecto Certified IT, y un miembro de la IEEE Computer Society.
Tom van Sante, KPN / Getronics
Tom van Sante es Consultor Principal y Director del Programa de KPN / Getronics. Empezó su carrera en TI hace más
de 30 años después de estudiar arquitectura en la Universidad Técnica de Delft. Trabajando en una variedad de
funciones, desde las operaciones de gestión, que ha operado siempre en las fronteras entre negocio y TI. Estuvo
involucrado en la introducción y desarrollo de ITIL / ASL / BiSL en los Países Bajos. Tom van Sante ha trabajado en
numerosas citas de Gobierno e Industria orientar el uso de las TIC en la sociedad moderna. Fue el responsable de la
introducción y desarrollo de TOGAF dentro de KPN / Getronics.
Mike Turner, Nokia
Mike Turner dirigió el esfuerzo de desarrollo de Capgemini en TOGAF Versión 9 y también trabajó en el equipo central que se
desarrolló el Marco de SAP Enterprise Architecture (una iniciativa conjunta entre Capgemini y SAP). En la actualidad trabaja
como Arquitecto Empresa de Nokia.
Paul van der Merwe, Connexion de negocios
Paul van der Merwe, Director de la Unidad de Negocios de Negocios Connexion, es uno de los profesionales de arquitectura
empresarial más dinámicas e interesantes de Sudáfrica. Un pensador conceptual, ha impulsado una serie de avances en los
campos en los que se ha especializado, entre ellos el desarrollo de software, inteligencia empresarial, gestión de las TIC, y la
arquitectura de la empresa. El enfoque fundamental de la arquitectura de la empresa defendido por él es arquitectura empresarial
basada en un repositorio que debe establecerse dentro de las organizaciones como una práctica continua que permite capacidades
de negocio y de tecnología. Él consulta y entrena en la puesta en práctica de TOGAF y con frecuencia se presenta en la
arquitectura de la empresa en eventos del sector.
Guía (2011) Copyright © 2009-2011 The Open Group. Todos los derechos reservados. xi

Expresiones de gratitud
The Open Group agradece el siguiente:
• miembros pasados y presentes de The Open Group Foro de Arquitectura para el desarrollo de
togaf (TOGAF)
• Capgemini y SAP para los materiales aportados
• Los siguientes revisores de este documento:
• David Hornford
• Bill Estrem
• Henry Franken
• Judith Jones
• Henk Jonkers
• Mike Lambert
• Kiichiro Onishi
• Roger lectura
• Saverio Rinaldi
• John Rogers
• Robert Weisman
• Nicholas Yakoubovsky
xii Copyright © 2009-2011 The Open Group. Todos los derechos reservados. Guía (2011)

Capítulo 1 Introducción
En este capítulo se proporciona una introducción a TOGAF, una norma Open Group.
Los temas abordados en este capítulo incluyen:
• Una introducción a TOGAF
• TOGAF, su estructura y contenido
• Los tipos de arquitectura que las direcciones de TOGAF
1.1 Introducción a TOGAF
TOGAF es un marco de arquitectura. En pocas palabras, TOGAF es una herramienta para ayudar en la aceptación, la producción, el uso y
mantenimiento de las arquitecturas. Se basa en un modelo de proceso iterativo con el apoyo de las mejores prácticas y una re-utilizable
conjunto de activos arquitectónicos existentes.
TOGAF es desarrollado y mantenido por The Open Group Architecture Forum. La primera versión de TOGAF,
desarrollado en 1995, se basó en el Departamento de Defensa de EE.UU. Técnico Marco de Arquitectura para la
Gestión de la Información (TAFIM). Partiendo de esta base sólida, El Foro de Arquitectura Open Group ha
desarrollado versiones sucesivas de TOGAF a intervalos regulares y publicado cada uno en el sitio web público Open
Group.
Este documento cubre TOGAF Versión 9.1, conocido simplemente como “TOGAF” en el texto de este documento. TOGAF 9.1 fue
publicado por primera vez en diciembre de 2011, y es una actualización de mantenimiento de TOGAF 9 que fue publicado en
enero de 2009. Esta última versión es una evolución de TOGAF 8.1.1 y una descripción de los cambios se proporciona en el
Apéndice A.
TOGAF se puede utilizar para el desarrollo de una amplia gama de diferentes arquitecturas empresariales. TOGAF
complementa, y se puede utilizar en conjunción con otros marcos, que son más centrado en productos específicos para
determinados sectores verticales, como Gobierno, Telecomunicaciones, Manufactura, Defensa, y Finanzas. La clave para
TOGAF es el método - el método de desarrollo de arquitectura TOGAF (ADM) - para el desarrollo de una arquitectura
empresarial que se ocupa de las necesidades del negocio.
1.2 Estructura del documento TOGAF
El documento TOGAF se divide en siete partes, tal como se resume en la Tabla 1.
Guía (2011) Copyright © 2009-2011 The Open Group. Todos los derechos reservados. 1

Tabla 1: Estructura del documento 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, al enfoque TOGAF. Contiene las definiciones de los términos utilizados a lo
largo TOGAF y notas de la versión que detallan los cambios entre esta versión y la versión anterior de
TOGAF.
Parte II: Método de Desarrollo Esta parte es el núcleo de TOGAF. En él se describe el método de TOGAF Arquitectura Desarrollo
de Arquitectura (ADM) - un enfoque paso a paso para el desarrollo de una arquitectura empresarial.
Parte III: Directrices y técnicas de Esta parte contiene una colección de guías y técnicas disponibles para su uso en la aplicación de la
ADM ADM.
Parte IV: Marco de Esta parte describe el marco de contenido TOGAF, incluyendo un metamodelo estructurado para
Arquitectura contenido artefactos arquitectónicos, el uso de los reutilizables Arquitectura Building Blocks (Abs), y una visión
general de las prestaciones típicas de arquitectura.
Parte V: Continuum Empresa y Esta parte discute las taxonomías y las herramientas apropiadas para clasificar y almacenar los resultados de la
Herramientas actividad de la arquitectura dentro de una empresa.
Parte VI: Modelos de referencia TOGAF Esta parte proporciona dos modelos de referencia de arquitectura, a saber, el Modelo TOGAF
Referencia técnica (TRM), y el modelo de infraestructura de Referencia Integrado de Información
(III-RM).
Parte VII: Marco de Esta parte analiza la organización, procesos, habilidades, roles y responsabilidades necesarias
Capacidad de Arquitectura para establecer y operar un estudio de arquitectura dentro de una empresa.
1.3 ¿Qué es la Arquitectura en el contexto de TOGAF?
ISO / IEC 42010: 2007 2 define la “arquitectura” como:
“La organización fundamental de un sistema, encarnado en sus componentes, sus relaciones entre sí y con el medio
ambiente y los principios que gobiernan su diseño y evolución.”
TOGAF abraza y se extiende esta definición. 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 componentes de
orientar su aplicación
2. La estructura de los componentes, sus interrelaciones, así como los principios y directrices
que regulan su diseño y evolución en el tiempo
2 ISO / IEC 42010: 2007, Sistemas e Ingeniería de Software - Práctica recomendada para la descripción arquitectónica de los sistemas de software intensivo,
Edición 1 (técnicamente idéntica a la norma ANSI / IEEE Std 1471-2000).
2 Copyright © 2009-2011 The Open Group. Todos los derechos reservados. Guía (2011)

1.4 ¿Qué tipo de arquitectura no tratar con TOGAF?
TOGAF cubre el desarrollo de cuatro tipos relacionados de la arquitectura. Estos cuatro tipos de arquitectura son comúnmente
aceptados como subconjuntos de una arquitectura global de la empresa, todos los cuales TOGAF está diseñado para soportar. Se
muestran en la Tabla 2.
Tabla 2: Arquitectura tipos soportados por TOGAF
Tipo de Arquitectura Descripción
Arquitectura de Negocios La estrategia de negocio, gobierno, organización y procesos clave del negocio.
Arquitectura de datos 3 La estructura de gestión de los recursos lógicos y físicos activos de datos y datos de una
organización.
Arquitectura de la aplicación Un modelo para las aplicaciones individuales para ser desplegado, sus interacciones y su
relación con los procesos de negocio de la organización.
Arquitectura tecnología 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 y normas.
1.5 ¿Qué contiene TOGAF?
TOGAF refleja la estructura y el contenido de una capacidad de arquitectura dentro de una empresa, como se muestra en la Figura 1.
3 Arquitectura de datos se denomina Arquitectura de la Información en algunas organizaciones.

Figura 1: Visión general del contenido TOGAF
Central para TOGAF es el método de arquitectura de Desarrollo (documentado en TOGAF, parte II). La arquitectura de
capacidad (documentado en TOGAF, Parte VII) opera el método. El método se apoya en una serie de orientaciones y
técnicas (documentado en TOGAF, Parte III). Esto produce contenido para ser almacenados en el repositorio
(documentado en TOGAF, Parte IV), que se clasifica de acuerdo a la Empresa Continuum (documentado en TOGAF,
Parte V). El repositorio está poblada inicialmente con los modelos de referencia (TOGAF documentados en TOGAF,
Parte VI).
1.5.1 El Método de Desarrollo de Arquitectura (ADM)
los ADM describe cómo derivar una arquitectura empresarial específica de la organización que se ocupa de los requerimientos del
negocio. El ADM es el componente principal de TOGAF y proporciona una guía para arquitectos en varios niveles:
• Se proporciona un número de fases de desarrollo arquitectura ( Arquitectura de Negocios, Arquitecturas de Sistemas de

Información, Tecnología de la Arquitectura) en un ciclo, como una plantilla para la actividad global del proceso de desarrollo de
arquitectura.

• Proporciona una narrativa de cada fase arquitectura, la descripción de la fase en términos de objetivos, el enfoque, entradas,
pasos y salidas. Las secciones de entradas y salidas proporcionan una definición de la estructura de contenidos arquitectura y
entregables (una descripción detallada de las entradas de fase y salidas de fase está dada en el Marco contenido
Architecture).
• Proporciona resúmenes de fase cruzada que cubren la gestión de requisitos.
El ADM se describe adicionalmente en el Capítulo 2.
1.5.2 Directrices y técnicas de ADM
Directrices y técnicas de ADM proporciona un número de directrices y técnicas para soportar la aplicación de la ADM. La dirección de la
adaptación de las directrices de la ADM para hacer frente a una serie de escenarios de uso, incluyendo diferentes estilos de proceso (por
ejemplo, el uso de iteración) y también las arquitecturas de especialidad específicas (como la seguridad). Las técnicas permiten realizar tareas
específicas dentro de la ADM (tales como los principios que definen, escenarios de negocio, objetivos de negocio, análisis de las deficiencias, la
planificación de la migración, la gestión de riesgos, etc.).
Directrices ADM se describen en el Capítulo 4. Técnicas de ADM se describen en detalle en el capítulo 3, junto con los
resultados clave.
1.5.3 Arquitectura Marco de contenido
los Arquitectura Marco de contenido proporciona un modelo detallado de los productos arquitectónicos de trabajo, incluyendo
entregables, los artefactos dentro de entregables, y los bloques de construcción Arquitectura (Abs) que representan las prestaciones.
El Marco de Arquitectura contenido se describe con más detalle en el capítulo 5.
1.5.4 El Continuum Empresa
los Continuum empresa proporciona un modelo para la estructuración de un repositorio virtual y proporciona métodos para la
clasificación de los artefactos de la arquitectura y de la solución, que muestra cómo evolucionan los diferentes tipos de artefactos, y la
forma en que se pueden aprovechar y re-utilizada. Esto se basa en arquitecturas y soluciones (modelos, patrones, las descripciones de la
arquitectura, etc.) que existen dentro de la empresa y en la industria en general, y de la cual la empresa ha recogido para su uso en el
desarrollo de sus arquitecturas.
La Empresa Continuum se describe adicionalmente en el Capítulo 6.
1.5.5 Modelos de referencia TOGAF
TOGAF proporciona dos modelos de referencia para su posible inclusión en la propia empresa Continuum de una empresa, a
saber, el TOGAF Modelo de referencia técnica ( TRM) y el Infraestructura de Información Integrado Modelo ( III-RM).
Los modelos de referencia de TOGAF se describen con más detalle en el capítulo 7.

1.5.6 El Marco de Arquitectura de Capacidad
los Marco de Arquitectura de Capacidad es un conjunto de recursos, directrices, plantillas, información de fondo, etc.
proporciona para ayudar al arquitecto a establecer un estudio de arquitectura dentro de una organización.
El Marco de Arquitectura capacidad se describe con más detalle en el capítulo 8.

Capítulo 2 Desarrollo de la Arquitectura

Método
En este capítulo se describe el método de arquitectura de Desarrollo (ADM), su relación con el resto de TOGAF, y las
consideraciones de alto nivel para su uso. También incluye un resumen de cada fase dentro de la ADM.
Los temas abordados en este capítulo incluyen:
• Una introducción a la ADM
• Las fases de la ADM
• Los objetivos, pasos, entradas y salidas a las fases de ADM
• Gestión de requisitos durante el ciclo de ADM
• La determinación del alcance de la actividad de la arquitectura
2.1 ¿Cuál es el ADM?
El ADM, el resultado de las contribuciones de muchos profesionales de la arquitectura, forma el núcleo de TOGAF. Es un método para
derivar las arquitecturas empresariales específicos de la organización y está diseñado específicamente para satisfacer los
requerimientos del negocio. El ADM describe:
• Una forma segura, probada de desarrollo y uso de una arquitectura empresarial
• Un método de desarrollo de arquitecturas en diferentes niveles 4 ( negocio, aplicaciones, datos, tecnología) que permiten el
arquitecto para asegurarse de que un complejo conjunto de requisitos se abordan adecuadamente
• Un conjunto de directrices y técnicas para el desarrollo de la arquitectura
2.2 ¿Cuáles son las fases de la ADM?
El ADM consiste en un número de fases que ciclo a través de una serie de dominios de arquitectura que permiten al arquitecto para
asegurarse de que un complejo conjunto de requisitos se trate adecuadamente. La estructura básica de la ADM se muestra en la
Figura 2.
4 En TOGAF Esto se denomina como un conjunto de dominios de arquitectura.

Figura 2: El ciclo del método de desarrollo de arquitectura
El ADM se aplica iterativamente durante todo el proceso, entre las fases, y dentro de ellos. Durante todo el ciclo de
ADM, no debería haber validación frecuente de resultados contra los requisitos originales, tanto los de todo el ciclo de
ADM, y aquellos para la fase particular del proceso. Dicha validación debe reconsiderar alcance, el detalle, horarios, y
los hitos. Cada fase debe considerar activos producidos a partir de iteraciones anteriores del proceso y de los activos
externos del mercado, tales como otros marcos o modelos.
El ADM es compatible con el concepto de iteración en tres niveles:
• En bicicleta por el ADM: El ADM se presenta en una forma circular que indica que la terminación de una fase de trabajo
de arquitectura alimenta directamente en fases posteriores de trabajo de arquitectura.
• Iterar entre fases: TOGAF describe el concepto de iteración a través de las fases (por ejemplo, volviendo a la Arquitectura
de Negocios en la terminación de Arquitectura de Tecnología).
• Ciclo alrededor de una sola fase: TOGAF apoya repite la ejecución de las actividades dentro de una sola fase de ADM
como una técnica para la elaboración de contenido arquitectónico.

Para más información sobre iteración se da en TOGAF, Parte III: Directrices y técnicas de ADM (véase el capítulo 4).
Tabla 3: Desarrollo, Arquitectura Método Actividades de la Fase
Fase ADM Actividad
Fase preliminar Preparar a la organización para el éxito de los proyectos de arquitectura TOGAF. Llevar a cabo
las actividades de preparación e iniciación necesarios para crear una capacidad de
Arquitectura, incluyendo la personalización de TOGAF, selección de herramientas, y la
definición de los principios de la arquitectura.
Gestión de requerimientos Todas las etapas de un proyecto se basa en TOGAF y valida los requerimientos del
negocio.
Requisitos se identifican, almacenan, y se introducen en y fuera de las fases de ADM

pertinentes, que disponen de, dirección, y dar prioridad a los requisitos.
Fase A: Establecer el alcance, limitaciones y expectativas para un proyecto TOGAF. Crear el

Architecture Vision Architecture Vision. Identificar a los interesados. Validar el contexto empresarial y crear la
Declaración de Arquitectura de trabajo. Obtener las aprobaciones.
Fase B: Desarrollar arquitecturas en cuatro dominios:

Arquitectura de Negocios Fase 1. Negocio
C: 2. Sistemas de Información - Aplicación
Arquitecturas de Sistemas de Información
3. - Sistemas de Información de Datos
(Aplicación y Datos) Fase D:
4. Tecnología
Arquitectura tecnología En cada caso, el desarrollo de la línea de base y Arquitectura Target y analizar las deficiencias.
Fase E: Realizar la planificación de la implementación inicial y la identificación de los

Oportunidades y soluciones vehículos de reparto de los bloques definidos en las fases anteriores. Determinar si
se requiere un enfoque gradual, y si es así identificar Transición arquitecturas.
Fase F: Desarrollar implementación detallada y Plan de conversión que se ocupa de

Planificación de la migración cómo pasar de la línea de base a la arquitectura destino.
Fase G: Proporcionar una supervisión arquitectónica para la aplicación. Preparar y contratos

Gobierno implementación tema Arquitectura. Asegúrese de que el proyecto de ejecución se ajusta a la
arquitectura.
Fase H: Permitan un seguimiento continuo y un proceso de gestión de cambios para asegurar

Arquitectura Gestión del Cambio que la arquitectura responde a las necesidades de la empresa y maximiza el valor de
la arquitectura para el negocio.

2.3 El ADM en detalle
Las siguientes tablas resumen los objetivos, las medidas y las entradas y salidas 5 de cada fase del ciclo de ADM.
2.3.1 Fase preliminar
La fase preliminar se prepara una organización para llevar a cabo con éxito proyectos de arquitectura empresarial.
Una visión general de la fase se da a continuación:
objetivos Pasos
Determinar la capacidad de la arquitectura deseada por la Alcance los marcos de gobierno y de apoyo Confirmar
organización: organizaciones empresariales afectadas definir y establecer la
• Revisar el contexto de la organización para la realización empresa equipo de arquitectura y organización
de la arquitectura empresarial
• Identificar y alcance, los elementos de las Identificar y establecer principios de arquitectura TOGAF a medida
organizaciones empresariales afectadas por la
y, en su caso, otros marcos de Arquitectura seleccionados
capacidad de Arquitectura
Implementar herramientas de arquitectura
• Identificar los marcos, métodos y procesos establecidos
que se cruzan con la capacidad de Arquitectura
• Establecer objetivo de Madurez de Capacidades
Capacidad de establecer la Arquitectura:
• Definir y establecer el modelo de organización de la

arquitectura empresarial
• Definir y establecer el proceso detallado y recursos para la

gobernabilidad arquitectura
• Seleccionar e implementar herramientas que apoyan la actividad de la
arquitectura
• Definir los principios de la arquitectura
5 Los números de versión para productos específicos se han omitido de esta guía de bolsillo ya TOGAF afirma que el esquema de numeración
ADM es un ejemplo y que deben adaptarse según proceda.

entradas salidas
TOGAF modelo de organización de la arquitectura empresarial Tailored
Otro marco (s) de la arquitectura arquitectura marco, incluidos los principios de arquitectura inicial
estrategias de mesa, planes de negocio, estrategia de negocio, estrategia de TI, los Reformulación Arquitectura Repositorio de, o referencia a los
principios de negocio, objetivos de negocio, y los conductores de negocios principios de negocio, objetivos de negocio, y los conductores de
negocio Solicitar Marco de Gobierno de Arquitectura de Trabajo
Gobernabilidad y legal marcos capacidad de Arquitectura de
colaboración y contratos Los contratos en curso modelo de
organización de la arquitectura empresarial
Existente estructura de arquitectura, en su caso, incluyendo:
• método de la arquitectura
• contenido de la arquitectura
• herramientas configuradas y desplegadas
• Principios de Arquitectura
• Arquitectura Repositorio

2.3.2 Fase A: Architecture Vision
La fase A es sobre el establecimiento del proyecto e inicia una iteración del ciclo de desarrollo de la arquitectura, la determinación del
alcance, limitaciones y expectativas para la iteración. Se requiere con el fin de validar el contexto empresarial y la creación de la
Declaración de Arquitectura de Trabajo aprobado.
objetivos Pasos
Desarrollar una visión política de alto nivel de las capacidades y el valor Establecer el proyecto de arquitectura identificar a los interesados,
de negocio a ser entregado como consecuencia de la arquitectura de la preocupaciones y requerimientos del negocio
empresa se propone obtener la aprobación de una Declaración de
Arquitectura de trabajo que define un programa de trabajos para
Confirman y elaboran los objetivos de negocio, los impulsores del negocio, y
desarrollar e implementar la arquitectura se indica en la Architecture
las limitaciones de evaluar las capacidades de negocio evaluar la preparación
Vision
para la transformación del negocio Definir el alcance
Confirmar y elaborar principios de arquitectura, incluyendo los

principios de negocio Desarrollar Architecture Vision Definir las
propuestas de valor arquitectura objetivo y KPI
Identificar los riesgos de transformación de negocio y actividades de

mitigación
Desarrollar Declaración de Arquitectura de trabajo; obtener la aprobación
entradas salidas
Solicitud de Trabajo Arquitectura Declaración aprobada de Arquitectura de trabajo refinados declaraciones
principios de actuación, los objetivos de negocio, y los conductores de negocios de principios de negocio, objetivos de negocio, y los conductores de
negocios principios de arquitectura evaluación de la capacidad Tailored

modelo de organización para la arquitectura de la empresa Tailored arquitectura Marco de Arquitectura Architecture Vision, incluyendo:
marco, incluido el método de la arquitectura a la medida, el contenido de la
arquitectura, principios de arquitectura, herramientas configuradas y
desplegadas
• requisitos de los interesados de alto nivel clave

Poblada Arquitectura repositorio; es decir, la documentación de la arquitectura
refinados
(Marco de Descripción, las descripciones de la arquitectura, las descripciones
de referencia existentes, etc.) existente Proyecto de Documento de definición de la arquitectura, incluyendo (cuando en su
alcance):
• Arquitectura línea base de negocios (de alto nivel)
• Arquitectura de datos de línea de base (de alto nivel)
• Arquitectura de la aplicación de línea de base (de alto nivel)
• Arquitectura Tecnología de línea de base (de alto nivel)
• Objetivo Arquitectura de Negocios (de alto nivel)
• Arquitectura de datos de destino (de alto nivel)

• Arquitectura Aplicación de destino (de alto nivel)
• Arquitectura Tecnología de destino (de alto nivel) plan de

comunicaciones de contenido adicional poblar el repositorio de
Arquitectura

2.3.3 Fase B: Arquitectura de Negocios
La fase B se refiere al desarrollo de una arquitectura de negocios para apoyar una Architecture Vision acordado.
objetivos Pasos
Desarrollar la Arquitectura de Negocios de destino que describe cómo la Algunos modelos de referencia, puntos de vista, y las herramientas de línea de
empresa necesita para operar para alcanzar los objetivos de negocio, base Desarrollar Arquitectura Descripción de actividad
responde a los conductores estratégicos establecidos en la arquitectura de la
visión, y se dirige a la solicitud de Arquitectura trabajo y preocupaciones de los
Objetivo Desarrollar Arquitectura Descripción Realizar análisis de las
interesados
deficiencias Definir los componentes de la hoja de ruta candidata Resolver
Identificar candidatos componentes Arquitectura Hoja de ruta sobre la base impactos a través de la revisión de los interesados formal de la arquitectura
de las diferencias entre los de referencia y objetivos comerciales del paisaje Conducta Finalizar la Arquitectura de Negocios Crear definición
Arquitecturas
de la arquitectura de documento
entradas salidas
Solicitud de Trabajo Arquitectura Declaración de Arquitectura de Trabajo, actualizado si es necesario
principios de actuación, los objetivos de negocio, y los conductores de negocios
validados principios de negocio, objetivos de negocio, y los conductores de
negocios
Plan de Evaluación de la capacidad
Elaborado Arquitectura de Negocios principios Proyecto de Arquitectura definición
de Comunicaciones
de documento que contiene las actualizaciones de contenido:
modelo de organización para la Declaración de arquitectura de
la empresa Tailored Arquitectura marco aprobado de los

• Arquitectura línea base de negocios (detallado), en su caso
principios Arquitectura Arquitectura trabajo, incluidos los
principios de negocio, cuando preexistente Empresa Continuum

• Objetivo Arquitectura de Negocios (detallado)
Arquitectura Repositorio Architecture Vision, incluyendo:
• Vistas correspondientes a puntos de vista seleccionados frente a
problemas clave de las partes interesadas Proyecto de Arquitectura
especificación de requisitos incluyendo actualizaciones de contenido:
• requisitos de los interesados de alto nivel clave

• los resultados del análisis Gap
refinados
• Requerimientos técnicos
Proyecto de Arquitectura de definición de documento, incluyendo:
• Arquitectura componentes requisitos de negocio
• Arquitectura línea base de negocios (de alto nivel)
de negocios actualizadas de una Arquitectura Hoja de
Ruta
• Arquitectura de la aplicación de línea de base (de alto nivel)
• Objetivo Arquitectura de Negocios (de alto nivel)
• Arquitectura de datos de destino (de alto nivel)
• Arquitectura Aplicación de destino (de alto nivel)
• Arquitectura Tecnología de destino (de alto nivel)

2.3.4 Fase C: Arquitecturas de Sistemas de Información
La fase C se trata de la documentación de la organización fundamental de una organización "s sistemas informáticos, incorporados en
los principales tipos de información y los sistemas de aplicación que los procesan. Hay dos pasos en esta fase, que puede ser
desarrollado de forma secuencial o simultáneamente:
• Arquitectura de datos
• Arquitectura de la aplicación

2.3.4.1 Arquitectura de datos
objetivos Pasos
Desarrollar la arquitectura de datos de destino que permite la arquitectura Algunos modelos de referencia, puntos de vista, y las herramientas de línea de base
de negocios y la visión Arquitectura, mientras que frente a la solicitud de Desarrollar Arquitectura de datos Descripción Desarrollar Objetivo Arquitectura de
Arquitectura trabajo y preocupaciones de los interesados identificar los
datos Descripción Realizar análisis de las deficiencias Definir los componentes de la
componentes de la Hoja de Ruta Arquitectura candidatos en base a las
hoja de ruta candidatos se resuelven los impactos a través de la revisión de los
diferencias entre las arquitecturas de datos de referencia y objetivos
interesados formal de la arquitectura del paisaje Conducta Finalizar la Arquitectura
de Datos Crear definición de la arquitectura de documento
entradas salidas
Solicitud de Plan de Evaluación de la Declaración de Arquitectura de Trabajo, actualizado si es necesario
Capacidad de Comunicaciones Arquitectura

principios validados los datos, o nuevo Documento principios de datos Proyecto
Trabajo
de definición de la arquitectura, que contienen actualizaciones de contenido:
modelo de organización de los principios de arquitectura
empresarial Tailored arquitectura de datos Marco

• Arquitectura de datos de línea de base
• Arquitectura de datos de destino

Declaración de Arquitectura de trabajo de la
• Arquitectura vistas datos correspondientes a los puntos de vista
configuración Visión Arquitectura Repositorio
seleccionados, abordar preocupaciones de los interesados clave Proyecto de
Arquitectura Requisitos especificación, incluyendo las actualizaciones de

Proyecto de Arquitectura de definición de documento, que
contenido:
contiene:
• Arquitectura línea base de negocios (detallado)

• requisitos de interoperabilidad de datos
• requisitos técnicos pertinentes que se aplicarán a
• Arquitectura de datos de destino (de alto nivel) esta evolución del ciclo de desarrollo de la
• Arquitectura de aplicaciones de línea de base (visión detallada o) arquitectura
• Las limitaciones de la Arquitectura Tecnología
• Arquitectura Aplicación de destino (visión detallada o) • requisitos de negocio actualizados
• componentes requisitos de la aplicación Arquitectura de datos

• Arquitectura Tecnología de línea de base (de alto nivel) actualizados de una arquitectura Hoja de Ruta
• Arquitectura Tecnología de destino (de alto nivel) Proyecto de

Arquitectura Requisitos Especificación, incluyendo:
• componentes de la arquitectura de negocios
requisitos técnicos pertinentes de una hoja de ruta
Arquitectura
dieciséis Copyright © 2009-2011 The Open Group. Todos los derechos reservados. Guía (2011)

2.3.4.2 Arquitectura de la aplicación
objetivos Pasos
Desarrollar la Arquitectura Aplicación de destino que permite la Algunos modelos de referencia, puntos de vista, y herramientas de desarrollar
arquitectura de negocios y la visión Arquitectura, mientras que frente a la una arquitectura de aplicaciones de línea de base Descripción
solicitud de Arquitectura trabajo y preocupaciones de los interesados

Identificar los componentes de la Hoja de Ruta Arquitectura candidatos
Desarrollar una arquitectura de aplicación de destino Descripción Realizar
en base a las diferencias entre la línea base y Destino de la aplicación
análisis de las deficiencias Definir los componentes de la hoja de ruta candidata
Arquitecturas
Resolver impactos a través de la revisión de los interesados formal de la
arquitectura del paisaje Conducta Finalizar la arquitectura de aplicaciones Crear
definición de la arquitectura de documento
entradas salidas
Trabajo principios de aplicación validados, o nuevos principios de aplicación
modelo de organización para la arquitectura de la empresa Tailored

Proyecto de Arquitectura definición de documento, que contiene
arquitectura marco de los principios de aplicación Declaración de
actualizaciones de contenido:
Arquitectura de trabajo de la configuración Visión Arquitectura
• Arquitectura de aplicaciones de línea de base
Repositorio
• Arquitectura Aplicación de destino
• vistas arquitectura de aplicaciones correspondientes a los puntos de vista
seleccionados, abordar preocupaciones de los interesados clave Proyecto de

Proyecto de Arquitectura de definición de documento, que contiene:
Arquitectura Requisitos especificación, incluyendo las actualizaciones de
• Arquitectura línea base de negocios (detallado) contenido:
• Línea de Base de Datos Arquitectura (detallada o de alto nivel) • los resultados del análisis Gap
• requisitos de interoperabilidad de aplicaciones
• Objetivo Arquitectura de Datos (detallada o de alto nivel) • requisitos técnicos pertinentes que se aplicarán a
esta evolución del ciclo de desarrollo de la
• Arquitectura de la aplicación de línea de base (de alto nivel) arquitectura
• Arquitectura Aplicación de destino (de alto nivel) • Las limitaciones de la Arquitectura Tecnología
• Arquitectura Tecnología de línea de base (de alto nivel) • requisitos de negocio actualizados
• Arquitectura Tecnología de destino (de alto nivel) Proyecto de • Arquitectura componentes requisitos de datos de
Arquitectura Requisitos Especificación, incluyendo: aplicaciones actualizadas de una Arquitectura Hoja de Ruta
• Los requisitos de negocio y arquitectura de datos componentes
técnicos relevantes de una Hoja de Ruta de Arquitectura

2.3.5 Fase D: Arquitectura Tecnología
La fase D se trata de documentar la organización fundamental de los sistemas de TI, encarnado en el hardware, el software y la
tecnología de las comunicaciones.
objetivos Pasos
Desarrollar la Arquitectura Tecnología de destino que permite a los Algunos modelos de referencia, puntos de vista, y herramientas de desarrollar
componentes lógicos y físicos de datos y aplicaciones y la Visión una arquitectura de tecnología de línea de base Descripción
Arquitectura, dirigiéndose a la Solicitud de Arquitectura trabajo y
preocupaciones de los interesados
Desarrollar Arquitectura Tecnología Objetivo Descripción Realizar análisis de
las deficiencias Definir los componentes de la hoja de ruta candidata Resolver

Identificar candidatos componentes Arquitectura Hoja de ruta sobre la base
impactos a través de la revisión de los interesados formal de la arquitectura
de las diferencias entre las arquitecturas de tecnología de referencia y
objetivos del paisaje Conducta Finalizar la Tecnología de la Arquitectura Arquitectura
Crear definición de documento
entradas salidas

validados principios tecnológicos o nuevos principios tecnológicos (si
Trabajo
generados aquí) Proyecto de Arquitectura definición de documento, que
modelo de organización para la arquitectura de la empresa
contiene actualizaciones de contenido:
Tailored Arquitectura Tecnología Marco principios Declaración
de Arquitectura de trabajo de la configuración Visión Arquitectura

• Arquitectura Tecnología de línea de base
Repositorio
• Arquitectura Tecnología de destino
• Arquitectura Tecnología vistas correspondientes a los puntos de
vista seleccionados, abordar preocupaciones de los interesados clave

Proyecto de Arquitectura de definición de documento, que
Proyecto de Arquitectura Requisitos especificación, incluyendo las
contiene:
actualizaciones de contenido:
• Arquitectura línea base de negocios (detallado)
• Objetivo Arquitectura de Negocios (detallado) • informe de análisis de Gap

• Línea de Base de Datos Arquitectura (detallado)
• salida Requisitos de las fases B y C
• Arquitectura de datos de destino (detallado)
• Arquitectura componentes requisitos de tecnología
• Arquitectura de la aplicación de línea de base (detallado)
tecnología actualizada de una arquitectura Hoja de Ruta
• Arquitectura Aplicación de destino (detallada)
• Arquitectura Tecnología de destino (de alto nivel) Proyecto de

Arquitectura Requisitos Especificación, incluyendo:
• requisitos técnicos comerciales, componentes
pertinentes de datos, y la arquitectura de la aplicación de una
arquitectura Hoja de Ruta

2.3.6 Fase E: Oportunidades y Soluciones
Fase E es la primera fase que se ocupa directamente de la aplicación. En él se describe el proceso de identificación de los
vehículos de reparto (proyectos, programas o carpetas) que ofrecen la arquitectura destino identificados en las fases anteriores.
objetivos Pasos
Generar la versión completa inicial de la Arquitectura Roadmap, en Determinar y / o confirmar los atributos clave de cambio corporativo determinan las
base a los componentes de la hoja de ruta de análisis de brecha y restricciones del negocio de Revisión de la Implementación y consolidan los
candidato Arquitectura de las fases B, C, y D
resultados de análisis de carencias de las Fases B a D
Determinar si se requiere un enfoque gradual, y si es así identificar

Revisar los requisitos consolidados a través de las funciones de
las arquitecturas de transición que va a proporcionar un valor
negocio relacionadas Consolidar y concilien los requerimientos de
comercial continua
interoperabilidad refinar y validar dependencias confirman la
disposición y el riesgo de transformación del negocio
Formular estrategia de implementación y migración Identificar y
grandes paquetes de trabajo en grupo Identificar Arquitecturas de
transición Crear Hoja de Ruta Arquitectura e Implementación y Plan
de Migración
entradas salidas
Solicitar información del producto para la Declaración de Arquitectura de Trabajo, actualizado si es necesario
capacidad de Arquitectura de Comunicaciones
metodologías de trabajo para evaluar la Architecture Vision, actualizado si es necesario Proyecto de Arquitectura
planificación Plan de gobernanza y modelos de definición de documento, incluyendo:
declaración Marcos Tailored Marco de • Arquitectura de transición, número y alcance, en su caso
Arquitectura de Arquitectura de Trabajo Visión

Proyecto de Arquitectura Requisitos Especificación, si actualiza
Arquitectura Repositorio
evaluación de la capacidad necesaria, incluyendo:
• Capacidad de negocios
• Capacidad de Arquitectura de hoja de

Proyecto de Arquitectura definición de documento Requisitos Proyecto de
ruta, incluyendo:
Arquitectura Especificación solicitudes de cambio para los programas
• cartera paquete de trabajo
existentes y los proyectos componentes de la Hoja de Ruta Candidato
Arquitectura de las fases B, C, y D

• Identificación de Transición Arquitecturas, en su caso
• recomendaciones de implementación Implementación

y Plan de Migración (contorno), incluyendo:
• Implementación y estrategia de migración

2.3.7 Fase F: planeamiento de migración
Fase F aborda la planificación de la migración; es decir, cómo pasar de la línea de base a las arquitecturas objetivo de finalizar
una implementación detallada y Plan de Migración.
objetivos Pasos
Finalizar la Arquitectura Hoja de Ruta y la aplicación de soporte y Plan Confirmar las interacciones marco de gestión para la aplicación y el Plan
de Migración garantizar que la aplicación y el Plan de Migración se de Migración Asignar un valor de negocio para cada paquete de trabajo
coordina con el enfoque de la empresa para la gestión y aplicación de Estimación de las necesidades de recursos, tiempos de proyectos, y la
los cambios en la cartera global de cambio de la empresa Asegúrese disponibilidad de vehículos / entrega Dar prioridad a los proyectos de
de que el valor del negocio y el costo de los paquetes de trabajo y la migración a través de la realización de una evaluación de validación costo
transición Arquitecturas se entiende por las principales partes / beneficio y riesgo
interesadas
Arquitectura confirmar Hoja de Ruta y la actualización de definición de
la arquitectura documento completo del Plan de Implementación y
Migración Completa las lecciones ciclo de desarrollo y de documentos
aprendidas
entradas salidas
Solicitud de Plan de Trabajo Arquitectura de Implementación y Plan de Migración (detallado), incluyendo:
Comunicaciones
modelo de organización para los modelos de gobierno de • Implementación y estrategia de migración
arquitectura empresarial y la Declaración de los marcos de • Proyectos y carteras desglose de la ejecución
Tailored Marco de Arquitectura de Arquitectura de Trabajo

• las cartas de proyecto (opcional) Finalizado Arquitectura
Visión Arquitectura Repositorio
definición de documento, incluyendo:
• Finalizada la transición de arquitecturas, en su caso Finalizado

Proyecto de Arquitectura de definición de documento, incluyendo:
Arquitectura especificación de requisitos finalizados Arquitectura Roadmap
• Arquitecturas de transición, si alguna solicitudes de cambio Proyecto de
reutilizable Arquitectura Building Blocks Solicitudes de Arquitectura de
Arquitectura Requisitos de especificaciones para los programas existentes y
Trabajo para los aspectos de la arquitectura de los proyectos de
proyectos de arquitectura Hoja de Ruta evaluación de la capacidad, incluyendo:
implementación (si lo hay) Los contratos arquitectura para proyectos de
implementación Implementación Modelo de Gobierno las solicitudes de
cambio para la capacidad de la arquitectura que surge de lecciones

• Capacidad de negocios aprendidas
• Capacidad de TI
Implementación y Plan de Migración (contorno), incluyendo:
• Implementación de Alto Nivel y estrategia de migración

2.3.8 Fase G: Implementación de Gobierno
Fase G define cómo la arquitectura constriñe los proyectos de implementación, lo monitoriza mientras que la construcción, y produce
una Arquitectura contrato firmado.
objetivos Pasos
Asegurar la conformidad con la arquitectura destino de proyectos de Confirmar el alcance y las prioridades para la implementación con la gestión
implementación del desarrollo Identificar los recursos de implementación y desarrollo de
Arquitectura realizar funciones de gobierno adecuada para la habilidades Guía de despliegue de soluciones empresariales críticas
solución y las solicitudes de cambio de arquitectura Realizan la arquitectura de cumplimiento Implementar los negocios y
implementationdriven
operaciones de TI Realizar revisión posterior a la implementación y cerrar la
aplicación
entradas salidas
Solicitud de evaluación de la capacidad de Contrato Arquitectura (firmado) El cumplimiento de las
Arquitectura Trabajo evaluaciones del cambio Pide Análisis de Impacto -
modelo de organización para la arquitectura de la empresa Recomendaciones de implementación de soluciones
Declaración Tailored Marco de Arquitectura de Arquitectura de compatibles arquitectura-desplegados, incluyendo:
Trabajo Visión Arquitectura Arquitectura Repositorio definición
de la arquitectura Documento de Especificación de Requisitos
Arquitectura Hoja de Ruta de Gobierno Implementación

• El sistema implementado una arquitectura compatible
Modelo de contrato Arquitectura
• Repositorio Arquitectura poblada
• recomendaciones y dispensas de cumplimiento

Arquitectura
• Recomendaciones sobre los requisitos de prestación de

Solicitud de Arquitectura de trabajo identificadas en las Fases E y F servicios
• Recomendaciones sobre las métricas de rendimiento

Plan de Implementación y Migración
• Acuerdos de Nivel de Servicio (SLA)
• Architecture Vision, posterior a la implementación

actualizada
• Arquitectura definición de documento, actualizado

post-implementación
• Negocio y de TI que operan modelos para la solución

implementada

2.3.9 Fase H: Arquitectura de Gestión del Cambio
Fase H garantiza que los cambios en la arquitectura se gestionan de una manera controlada.
objetivos Pasos
Asegúrese de que el ciclo de vida de la arquitectura se mantiene a Establecer proceso de realización del valor Implementar
asegurar que se ejecuta el Marco de Arquitectura de Gobierno herramientas de supervisión de gestionar los riesgos
Asegúrese de que la capacidad de la empresa Arquitectura cumple con los

Proporcionar análisis para la gestión del cambio
requisitos actuales
arquitectura
Desarrollar requisitos de cambio para cumplir con los objetivos de rendimiento
Administrar proceso de gobierno de activar el proceso para implementar el
cambio
entradas salidas
Solicitud de modelo de organización del trabajo Arquitectura para actualizaciones Arquitectura
la arquitectura de la empresa Declaración Tailored Marco de Modificaciones del marco y los principios nueva solicitud de
Arquitectura de Arquitectura de trabajo de la configuración Visión Arquitectura trabajo, para iniciar otro ciclo de la Declaración de ADM de
Arquitectura Arquitectura repositorio de documentos Definición Arquitectura de trabajo de la configuración, actualizan si es necesario
Requisitos Arquitectura Arquitectura Especificación Hoja de Ruta
Arquitectura Contrato, actualizado si las evaluaciones de conformidad
necesarias, actualizado si es necesario
Las solicitudes de cambio debido a la tecnología cambia las
solicitudes de cambio debido a cambios en las solicitudes de
cambio de negocio a partir de las lecciones aprendidas de Gobierno
Implementación Modelo Arquitectura contrato (firmado)
Evaluaciones de Aplicación y Cumplimiento Plan de Migración

2.3.10 Gestión de requerimientos
El proceso de gestión de requisitos de arquitectura se aplica a todas las fases del ciclo de ADM. El proceso de gestión de requisitos es un
proceso dinámico, que se ocupa de la identificación de las necesidades de la empresa, su almacenamiento y, a continuación, la
alimentación de ellos dentro y fuera de las fases de ADM pertinentes. Como se muestra en la Figura 2, este proceso es central para la
conducción del proceso de ADM.
La capacidad para hacer frente a los cambios en los requisitos es crucial para el proceso de ADM, ya que la arquitectura por su
propia naturaleza ofertas con incertidumbre y cambio, reducir la brecha entre las aspiraciones de los grupos de interés y lo que puede
ser entregado como una solución práctica.
objetivos Pasos
Asegúrese de que el proceso de gestión de requisitos es sostenido y Identificar los requisitos / documentos Requisitos de referencia Monitor
funciona para todas las fases pertinentes de ADM de requisitos básicos identificar las nuevas exigencias; eliminar,
agregar, modificar y volver a evaluar las prioridades Identificar las

Administrar requisitos de arquitectura identificados durante cualquier
nuevas exigencias y prioridades de registro; identificar y resolver
ejecución del ciclo ADM o una fase asegurar que los requisitos de
conflictos; generan declaraciones requisitos de impacto evaluar el
arquitectura relevantes están disponibles para su uso por cada fase como
impacto de las nuevas exigencias de ADM fases actuales y anteriores
se ejecuta la fase de
Implementar exigencias derivadas de la Fase H actualización de los
requisitos repositorio de implementar un cambio en la actual fase
Evaluar y revisar el análisis de brecha para las fases anteriores
entradas salidas
Las entradas al proceso de gestión de requisitos son las salidas requisitos modificados
de los requisitos relacionados con cada fase de ADM. Requisitos de evaluación del impacto, que identifica las fases de la
ADM que necesitan ser revisados para hacer frente a cualquier
Los primeros requisitos de alto nivel se producen como parte de la cambio. La versión final debe incluir todas las implicaciones de los
arquitectura de la visión. requisitos (por ejemplo, costos, plazos, y las métricas de negocio).
Cada dominio arquitectura genera entonces requisitos detallados.

Entregables en fases posteriores ADM contienen asignaciones a
nuevos tipos de requisitos (por ejemplo, requisitos de conformidad).
2.4 La determinación del alcance de la Actividad Arquitectura
El ADM define una secuencia recomendada para las diversas fases y pasos implicados en el desarrollo de una arquitectura
empresarial en toda la organización, pero el ADM no puede determinar Alcance: este debe ser determinada por la propia
organización.
Hay muchas razones para restringir (o restringir) el alcance de la actividad arquitectónica que ha de realizar, la mayoría de los cuales se
refieren a los límites en:

• La autoridad para la organización del equipo de producción de la arquitectura
• Los objetivos y las preocupaciones de los interesados a dirigirse dentro de la arquitectura
• La disponibilidad de personas, finanzas y otros recursos
El ámbito elegido para la actividad de la arquitectura, lo ideal sería permitir que el trabajo de todos los arquitectos dentro de la
empresa que se rige y se integra de manera efectiva. Esto requiere un conjunto de particiones alineadas “arquitectura” que
aseguran los arquitectos no están trabajando en duplicado o actividades conflictivas. También se requiere la definición de la
reutilización y el cumplimiento de las relaciones entre las particiones de arquitectura. La división de la empresa y su actividad
relacionada con la arquitectura se aborda en TOGAF, Parte III: Directrices y técnicas de ADM (véase el capítulo 4).
La Tabla 4 muestra las cuatro dimensiones en el que el ámbito de aplicación puede definido y limitado.
Tabla 4: Dimensiones para limitar el alcance de la Actividad Arquitectura
Dimensión consideraciones
Amplitud ¿Cuál es la magnitud de la empresa, y qué parte de esa medida en caso de que el acuerdo con el esfuerzo
architecting?
Muchas empresas son muy grandes, que comprende efectivamente una federación de unidades organizativas que podrían ser
considerados empresas en su propio derecho.
La empresa moderna se extiende cada vez más allá de sus límites tradicionales, para abrazar una combinación
difusa de la empresa comercial tradicional combinado con proveedores, clientes y socios.
Profundidad ¿En qué nivel de detalle debe ir el esfuerzo architecting? La cantidad de la arquitectura es “suficiente”? ¿Cuál es la
adecuada delimitación entre el esfuerzo, la arquitectura y otras actividades relacionadas (diseño de sistemas, ingeniería de
sistemas, desarrollo de sistemas)?
Periodo de tiempo ¿Cuál es el período de tiempo que necesita ser articulado para la Arquitectura de la visión, y hace
Tiene sentido (en términos de practicidad y recursos) para el mismo período que se tratarán en la descripción detallada
arquitectura? Si no, ¿cómo muchas arquitecturas de transición, está por definir, y cuáles son sus periodos de tiempo?
Dominios Una completa descripción de la arquitectura de la empresa debe contener todos los cuatro dominios de la arquitectura (de
Arquitectura negocios, datos, aplicaciones, tecnología), pero la realidad de las limitaciones de recursos y tiempo a menudo significa que no hay
tiempo suficiente, la financiación, o recursos para construir una de arriba hacia abajo, todo- inclusiva descripción de la arquitectura
que abarca las cuatro áreas de arquitectura, incluso si se elige el ámbito empresarial a ser menor que la extensión total de la
empresa en general.

Capítulo 3 Técnicas y clave

Entregables del Ciclo de ADM
Este capítulo le ayudará a entender las técnicas clave y entregables del ciclo de ADM. Tabla 5 da una hoja de ruta para
este capítulo por la fase de ADM en la que se utilizan las técnicas y los resultados finales. Para cada punto, se presentan
datos clave.
Tabla 5: Plan de trabajo para el Capítulo 3
Fase ADM Referencia (s)
Fase preliminar Sección 3.1, hechas arquitectura marco de la Sección 3.2, modelo de organización
de la arquitectura empresarial, Sección 3.3 Principios de Arquitectura
Sección 3.4, Principios de Actuación, objetivos de negocio, y el negocio de controladores Sección 3.5,
Arquitectura Repositorio Sección 3.6, Arquitectura Herramientas Sección 3.7, Solicitud de Arquitectura
Trabajo
Fase A: Sección 3.8, Declaración de Arquitectura de Trabajo Sección

Architecture Vision 3.9, Architecture Vision Sección 3.10, Gestión de las partes
interesadas Sección 3.11, Plan de Comunicación
Sección 3.12, la transformación del negocio Evaluación de la Preparación Sección
3.13, 3.14 Sección de Evaluación de Capacidad, Gestión de Riesgo Sección 3.15,
Arquitectura definición de documento Sección 3.20, Arquitectura Puntos de vista
Sección 3.21, Arquitectura Vistas
Fase B: Sección 3.14, Gestión de Riesgos Sección 3.15, Arquitectura definición de

Arquitectura de Negocios documento Sección 3.16, requisitos de arquitectura Especificación Sección
3.17, Arquitectura Hoja de Ruta de la Sección 3.18, escenarios empresariales
Sección 3.19, análisis de las deficiencias Sección 3.20, Arquitectura Puntos de
vista Sección 3.21, Arquitectura vistas de sección 3.22, Bloques Arquitectura
Edificios Sección 3.23 , la solución de bloques de construcción

Fase ADM Referencia (s)
Fase C: Sección 3.15, Arquitectura definición de documento Sección 3.16, requisitos de

Arquitecturas de Sistemas de arquitectura Especificación Sección 3.17, Arquitectura Hoja de Ruta de la Sección
Información
3.19, análisis de las deficiencias Sección 3.20, Arquitectura Puntos de vista
Sección 3.21, 3.22 Arquitectura vistas de sección, los bloques de construcción
Arquitectura Sección 3.23, Bloques de construcción de soluciones
Fase D: Sección 3.15, Arquitectura definición de documento Sección 3.16, requisitos de

Arquitectura tecnología arquitectura Especificación Sección 3.17, Arquitectura Hoja de Ruta de la Sección
3.19, análisis de las deficiencias Sección 3.20, Arquitectura Puntos de vista
Sección 3.21, 3.22 Arquitectura vistas de sección, los bloques de construcción
Arquitectura Sección 3.23, Bloques de construcción de soluciones
Fase E: Sección 3.15, Arquitectura definición de documento Sección 3.19,

Oportunidades y Soluciones análisis de las deficiencias Sección 3.22, Bloques Arquitectura
Edificios Sección 3.23, Bloques solución de edificación Sección 3.24,
Capacidad de Planificación basada en la Sección 3.25, planeamiento
de migración Técnicas Sección 3.26, Implementación y Plan de
conversión Sección 3.27, Arquitectura Transición Sección 3.28 ,
Gobierno Modelo de Implementación
Fase F: Sección 3.24, 3.25 Sección de Planificación de Capacidad-base,

Planificación de la migración
técnicas de planeamiento de migración Sección 3.26,
Implementación y Plan de conversión Sección 3.27, Transición
Arquitectura Sección 3.28, Implementación Modelo de Gobierno
Fase G: Sección 3.28, Implementación Modelo de Gobierno Sección 3.29, 3.30

Gobierno implementación Arquitectura Sección de Contratos, Solicitud de cambio de la sección
3.31, Evaluación de Cumplimiento
Fase H: Sección 3.28, Implementación Modelo de Gobierno Sección 3.29, 3.31

Arquitectura Gestión del Arquitectura Sección de Contratos, Cumplimiento de Evaluación de la
Cambio
Sección 3.32, Evaluación de los requisitos de impacto

3.1 Tailored Architecture Framework
Selección y adaptación de un marco es el punto de partida para realizar un proyecto de arquitectura. Sobre la base de TOGAF tiene una
serie de ventajas con respecto a la creación de un marco a partir de cero:
• Evita el pánico inicial cuando la magnitud de la tarea se hace evidente.
• El uso de TOGAF es sistemático - “codificó el sentido común”.
• TOGAF capta lo que otros han encontrado que funcionan en la vida real.
• TOGAF tiene un conjunto básico de recursos para su reutilización.
• TOGAF define dos arquitecturas de referencia en la Empresa Continuum.
Sin embargo, antes TOGAF se puede utilizar eficazmente dentro de un proyecto de arquitectura, la adaptación a un número de
niveles es necesaria y debe ocurrir en la fase preliminar.
En primer lugar, es necesario adaptar el modelo TOGAF para la integración en la empresa. Esta adaptación incluirá la
integración con los marcos de gestión de proyectos y procesos, la personalización de la terminología, el desarrollo de estilos
de presentación, selección, configuración y despliegue de herramientas de arquitectura, etc. La formalidad y detalle de los
marcos adoptados también debe alinearse con otros factores de contexto para el de la empresa, tales como la cultura,
actores, modelos comerciales para la arquitectura de la empresa, y el nivel actual de la capacidad de la arquitectura.
Una vez que el marco se ha adaptado a la empresa, más la adaptación es necesaria con el fin de adaptar el marco del proyecto de
arquitectura específica. La adaptación a este nivel seleccionará entregables y artefactos apropiados para satisfacer las necesidades del
proyecto y las partes interesadas.
El siguiente contenido son típicos dentro de un marco adaptado Arquitectura:
• método de la arquitectura adaptada
• Adaptada contenido de la arquitectura (entregables y artefactos)
• herramientas configuradas y desplegadas
• Interfaces con modelos de gobierno y otros marcos:
• Planificación de negocios corporativa
• Arquitectura empresarial
• Cartera, Programa, Gestión de Proyectos
• Desarrollo de Sistemas / Ingeniería
• Operaciones (Servicios)
3.2 Modelo de organización de la arquitectura empresarial
Un entregable importante producido en la fase preliminar es el modelo de organización de la arquitectura empresarial.

Con el fin de establecer un marco de arquitectura para ser utilizado con éxito, debe ser apoyada por la correcta organización,
roles y responsabilidades dentro de la empresa. De particular importancia es la definición de los límites entre los distintos
profesionales de arquitectura empresarial y las relaciones de gobierno que se extienden a través de estos límites.
Contenido típico de un modelo de organización para la arquitectura de la empresa son:
• Alcance de las organizaciones impactado
• evaluación de la madurez, lagunas, y el enfoque de resolución
• Roles y responsabilidades para equipo de arquitectura (s)
• Las limitaciones de trabajo de arquitectura
• requisitos de presupuesto
• Gobernabilidad y apoyo a la estrategia
3.3 Principios de Arquitectura
Este conjunto de documentación es una salida inicial de la fase preliminar. Es el conjunto de normas y directrices generales para la
arquitectura que está desarrollando. Ver TOGAF, Parte III, Principios de Arquitectura de directrices y un conjunto detallado de
principios de arquitectura genéricos. El contenido de este documento se sugieren son los principios de negocio, los principios, los
principios de datos de aplicación, y los principios de la tecnología.
3.3.1 El desarrollo de principios de la arquitectura
principios de arquitectura suelen ser desarrollados por los arquitectos de la empresa, junto con las principales partes interesadas, y
son aprobados por la Junta de Arquitectura.
A continuación se influye por lo general el desarrollo de principios de la arquitectura:
• Misión de la empresa y los planes: La misión, planes, y la infraestructura organizativa de la empresa.
• iniciativas estratégicas de la empresa: Las características de la empresa - sus fortalezas, debilidades,

oportunidades y amenazas - y sus iniciativas a nivel de empresa actuales (como la mejora de procesos y gestión de la
calidad).
• restricciones externas: Los factores de mercado (imperativos de tiempo hasta el mercado, las expectativas del cliente, etc.); la
legislación existente y potencial.
• Los sistemas actuales y la tecnología: El conjunto de recursos de información desplegados dentro de la empresa, incluyendo la
documentación de sistemas, inventarios de equipos, diagramas de configuración de red, políticas y procedimientos.
• las tendencias de la industria informática: Las predicciones sobre el uso, la disponibilidad y costo de las tecnologías informáticas y de
comunicación, tomada de fuentes fidedignas, junto con las mejores prácticas asociadas actualmente en uso.

3.3.2 La definición de principios de la arquitectura
Dependiendo de la organización, los principios pueden establecerse dentro de los diferentes ámbitos y en diferentes niveles. Dos
dominios principales informan al desarrollo y la utilización de la arquitectura:
• principios empresariales proporcionar una base para la toma de decisiones en toda la empresa y dictar cómo la organización
cumple con su misión. Tales principios son comúnmente utilizados como medio de armonizar la toma de decisiones. Son un
elemento clave en una estrategia de gobierno de la arquitectura exitosa. Dentro del amplio dominio de los principios de la empresa,
es común tener principios subsidiarios dentro de una empresa o unidad organizativa; por ejemplo, recursos humanos, operaciones
domésticas, o operaciones en el extranjero.
• principios de la arquitectura son un conjunto de principios que se relacionan con el trabajo de arquitectura. Reflejan el
consenso en toda la empresa, y encarnan el espíritu de la arquitectura de la empresa. Arquitectura principios rigen el proceso
de arquitectura, lo que afecta el desarrollo, mantenimiento y uso de la arquitectura de la empresa.
TOGAF define una forma estándar de describir los principios. Además de una instrucción de definición, cada principio
debería haber asociado declaraciones justificación e implicaciones, tanto para promover la comprensión y la aceptación de
los principios mismos, y para apoyar el uso de los principios de explicar y justificar por qué se toman las decisiones
específicas.
Tabla 6: Plantilla TOGAF de principios que definen
Nombre Los dos deben representar la esencia de la norma, así como ser fácil de recordar. plataformas tecnológicas
específicas no deben ser mencionadas en el nombre o la declaración de un principio. Evitar palabras ambiguas
en el nombre y en la sentencia como: “apoyo”, “abierto”, “considerar”, y por falta de una buena medida de la
palabra “evitar”, sí, tener cuidado con “manejar (ment)”, y buscar adjetivos y adverbios innecesarios (fluff).
Declaración Debe comunicarse de manera sucinta y sin ambigüedades la norma fundamental. En su mayor parte, las declaraciones de
principios para la gestión de la información son similares entre las organizaciones. Es de vital importancia que la declaración de
principios sea inequívoca.
Razón fundamental Debe poner de relieve los beneficios comerciales de la adhesión al principio, utilizando la terminología de negocios.
Punto a la similitud de los principios de información y tecnología a los principios que rigen las operaciones de
negocio. También describen la relación con otros principios, y las intenciones con respecto a una interpretación
equilibrada. Describir situaciones en las que un principio se daría precedencia o tener más peso que otro para
tomar una decisión.
Trascendencia Debe poner de relieve los requisitos, tanto para el negocio y TI, para llevar a cabo el principio - en términos de
recursos, costos y actividades / tareas. A menudo será evidente que los sistemas actuales, normas o prácticas
serían incongruentes con el principio sobre la adopción. El impacto en el negocio y las consecuencias de la
adopción de un principio debe quedar claro. El lector debe discernir fácilmente la respuesta a: “¿Cómo me afecta?”
Es importante no simplificar en exceso, trivializar o juzgar el valor del impacto. Algunas de las consecuencias serán
identificados como sólo los impactos potenciales, y puede ser especulativa y no totalmente analizada.
3.3.3 Cualidades de Principios
Hay cinco criterios que distinguen a un buen conjunto de principios, como se muestra en la Tabla 7.

Tabla 7: Criterios Recomendados para Principios de Calidad
criterios Descripción
comprensibilidad Los principios subyacentes de un principio pueden ser rápidamente captados y comprendidos por las personas en
toda la organización. La intención del principio es claro y sin ambigüedades, de manera que violaciónes, ya sea
intencional o no, se reducen al mínimo.
robustez Principios deberían permitir que las decisiones de buena calidad sobre arquitecturas y planes a realizar, y las políticas y
normas de obligado cumplimiento que se creen. Cada principio debe ser lo suficientemente definitiva y precisa para
apoyar la toma de decisiones coherente en situaciones complejas y potencialmente controversiales.
Lo completo Todo principio potencialmente importante que rige la gestión de la información y la tecnología para la
organización se define. Los principios cubren cada situación percibida.
Consistencia La adhesión estricta a un principio puede requerir una interpretación libre de otro principio. El conjunto de
principios debe expresarse de una manera que permite un equilibrio de las interpretaciones. Los principios no
deben estar en contradicción con el punto en el que se adhiere a un principio violaría el espíritu de otro. Cada
palabra en un comunicado principio debe elegirse cuidadosamente para permitir una interpretación coherente y
flexible.
Estabilidad Principios deben ser duradera, sin embargo, capaz de adaptarse a los cambios. Un proceso de enmienda deberá
establecerse para añadir, eliminar o alterar los principios después de su ratificación inicialmente.
3.3.4 La aplicación de principios de la arquitectura
principios de la arquitectura se utilizan para capturar las verdades fundamentales acerca de cómo la empresa va a utilizar y desplegar los
recursos de TI y activos. Los principios se utilizan en un número de maneras diferentes:
1. Proporcionar un marco dentro del cual la empresa puede comenzar a tomar decisiones conscientes
sobre la arquitectura y proyectos de empresa que poner en práctica la arquitectura de la empresa objetivo
2. Como guía para el establecimiento de criterios de evaluación pertinentes, ejerciendo así una fuerte influencia en el
selección de productos, soluciones o arquitecturas de soluciones en las últimas etapas de la gestión de cumplimiento a la
arquitectura de la empresa
3. Como controladores para definir los requisitos funcionales de la arquitectura
4. Como insumo para la evaluación de ambas implementaciones existentes y el futuro cartera estratégica, por
cumplimiento de las arquitecturas definidos; estas evaluaciones proporcionarán información valiosa sobre las actividades de transición
necesarios para implementar una arquitectura, en apoyo de los objetivos y prioridades del negocio
5. Las declaraciones Justificación destacan el valor de la arquitectura de la empresa, y

por lo tanto, proporcionar una base para justificar las actividades de arquitectura
6. Las declaraciones Implicaciones proporcionan un esquema de la llave tareas, recursos y potencial

costos para la empresa de acuerdo con el principio; sino que también proporcionan valiosas aportaciones a futuras iniciativas de transición
y las actividades de planificación
7. Para apoyar las actividades de gobierno de la arquitectura en términos de:

• Proporcionar un “back-stop” para las evaluaciones de cumplimiento Arquitectura estándar donde se permite o se
requiere alguna interpretación
• El apoyo a una decisión de iniciar una solicitud de dispensación, donde las consecuencias de una modificación particular
arquitectura no pueden resolverse dentro del procedimiento operativo local
Principios están relacionados entre sí y deben ser aplicados como un conjunto. Principios a veces competir; por ejemplo, los
principios de “accesibilidad” y “seguridad”. Cada principio debe considerarse en el contexto de “todos en igualdad de
condiciones”. A veces se requiere una decisión sobre a qué principio tendrá prioridad sobre un tema en particular. La
justificación de este tipo de decisiones siempre debe ser documentada. El hecho de que un principio parece evidente por sí
mismo no significa que el principio está realmente observada en una organización, incluso cuando hay reconocimientos
verbales del principio. A pesar de las sanciones específicas no se prescriben en una declaración de principios, violaciónes de
los principios generalmente causan problemas operativos e inhiben la capacidad de la organización para cumplir su misión.
3.4 Principios de Actuación, objetivos de negocio, y los conductores de negocios
Una declaración de los principios de negocio, las metas y los conductores por lo general se ha definido en otra parte de la empresa
antes de la actividad de la arquitectura. Ellos se actualizan como una salida de la fase preliminar y revisados de nuevo como parte de
la Fase A: Architecture Vision. La actividad en la Fase A es para asegurar que las definiciones actuales son correctas y claras. TOGAF,
Parte III: Directrices y técnicas de ADM contiene un ejemplo conjunto de nueve principios de negocios que son un punto de partida útil.
No hay contenido definido para esta entrega como su contenido y la estructura puede variar considerablemente de
una organización a otra.
3.5 Arquitectura Repositorio
La Arquitectura Repositorio actúa como una zona de espera para todos los proyectos relacionados con la arquitectura dentro de la empresa. El
repositorio permite que los proyectos para gestionar sus entregas, localizar activos reutilizables, y publicar los resultados a las partes interesadas y
otras partes interesadas.
Vea la Sección 6.2 para una descripción del contenido de un repositorio de Arquitectura. El siguiente contenido son típicos dentro
de un repositorio de Arquitectura:
• Marco de la arquitectura
• Base de Información de normas
• La arquitectura del paisaje
• Arquitecturas de referencia
• Iniciar la gobernabilidad

3.6 Herramientas de Arquitectura
Como parte de la fase preliminar, el arquitecto debe seleccionar e implementar herramientas para apoyar la actividad de la arquitectura.
TOGAF no requiere ni recomienda ningún instrumento específico. TOGAF proporciona un breve comentario sobre cuestiones en las
herramientas de normalización en TOGAF, Parte V, Capítulo 42.
3.7 Solicitud de Trabajo Arquitectura
Este es un documento que se envía desde la organización patrocinadora a la organización arquitectura para desencadenar el inicio de un
ciclo de desarrollo de la arquitectura. Se produce con la ayuda de la organización arquitectura como una salida de la fase preliminar. Las
solicitudes de Arquitectura El trabajo también se crearán como resultado de la arquitectura de las solicitudes de cambio aprobadas, o
términos de referencia para el trabajo de la arquitectura procedente de planificación de la migración.
En general, toda la información contenida en este documento debe estar a un nivel alto. El contenido de este documento sugeridas son las
siguientes:
• patrocinadores de organizaciones
• La misión de la organización
• Los objetivos de negocio (y cambios)
• planes estratégicos de la empresa
• Límites de tiempo
• Los cambios en el entorno empresarial
• limitaciones de la organización
• información presupuestaria, las limitaciones financieras
• restricciones externas, restricciones comerciales
• Descripción actual sistema de negocio
• Descripción del sistema actual arquitectura / TI
• Descripción de la organización en desarrollo
• Descripción de los recursos disponibles para el desarrollo de la organización
3.8 Declaración de Arquitectura de Trabajo
La Declaración de Arquitectura de trabajo se crea como un entregable de la fase A, y es efectivamente un contrato entre la
organización architecting y el patrocinador del proyecto de arquitectura. Este documento es una respuesta a la solicitud de
documento de entrada Arquitectura de trabajo (véase la sección 3.6). Se debe describir un plan global para hacer frente a la
demanda de trabajo y proponen cómo se abordarán las soluciones a los problemas que han sido identificados a través del proceso
de la arquitectura.

El contenido de este documento sugeridas son las siguientes:
• Título
• solicitud de proyecto de arquitectura y antecedentes
• Arquitectura descripción del proyecto y el alcance
• Descripción general de Arquitectura Visión
• cambio específico de los procedimientos de alcance
• Funciones, responsabilidades y resultados
• criterios y procedimientos de aceptación
• plan de proyecto de arquitectura y el horario
• aprobaciones
3.9 Architecture Vision
El Architecture Vision se crea en la Fase A y proporciona un resumen de alto nivel de los cambios en la empresa que seguirá a
partir de la implementación exitosa de la arquitectura destino. El propósito de la visión es estar de acuerdo desde el principio lo que
el resultado deseado debe ser para la arquitectura, por lo que los arquitectos pueden centrarse en los detalles necesarios para
validar la viabilidad. Proporcionando una Architecture Vision también soporta comunicación con los interesados, proporcionando
una versión resumida de la definición de la arquitectura completa.
escenarios de negocio son una técnica apropiada e importante que puede ser utilizado como parte del proceso para desarrollar un
documento de la Arquitectura de la visión.
Los contenidos propuestos son los siguientes:
• Descripción del problema:
• Las partes interesadas y sus preocupaciones
• Lista de temas / escenarios que deben abordarse
• Objetivo de la Declaración de Arquitectura de Trabajo
• considera necesario Resumen de la Solicitud de Arquitectura trabajo y el alto nivel de negocios,

aplicaciones, datos y arquitecturas tecnológicas
• requisitos mapeados
• Referencia al proyecto de Arquitectura de definición de documento

3.10 Gestión de los interesados
gestión de los interesados es una disciplina importante que los arquitectos pueden utilizar con éxito para ganar el apoyo de los
demás. Esto les ayuda a garantizar que sus proyectos tengan éxito donde otros fallan. La técnica debe utilizarse durante la
fase A para identificar los actores clave en el compromiso, y también se actualizará en cada fase. El resultado de este proceso
constituye el inicio del Plan de Comunicaciones (véase la Sección 3.11).
Los beneficios de la gestión exitosa de las partes interesadas son las siguientes:
• Los más poderosos grupos de interés pueden ser identificados temprano y sus aportaciones pueden ser utilizados para dar forma
a la arquitectura; esto asegura su apoyo y mejora la calidad de los modelos producidos.
• El apoyo de los actores más poderosos ayudará a que el compromiso de ganar más recursos [s]; con lo que
el compromiso de la arquitectura más probabilidades de éxito.
• Mediante la comunicación con las partes interesadas tempranas y con frecuencia, el equipo de arquitectura puede asegurarse de que
comprenden plenamente el proceso de arquitectura, y los beneficios de la arquitectura de la empresa; esto significa que pueden apoyar al
equipo de arquitectura más activa cuando es necesario.
• El equipo de arquitectura puede anticipar más eficazmente las reacciones probable que los modelos de arquitectura e informes, y se
puede incorporar en el plan de las acciones que serán necesarias para sacar provecho de reacción positiva al mismo tiempo evitar o
hacer frente a cualquier reacción negativa.
• El equipo de arquitectura puede identificar objetivos conflicto o competencia entre los interesados temprana y desarrollar una
estrategia para resolver los problemas derivados de ellos.
3.10.1 Los pasos en el proceso de gestión de los grupos de interés
Paso 1: identificar a los interesados
La primera tarea es determinar quiénes son los principales actores de arquitectura empresarial son.
Un análisis de la muestra de las partes interesadas que distingue 22 tipos de los grupos de interés en cinco categorías amplias, se muestra en la
Figura 3.

Figura 3: Categorías de los grupos de interés
Paso 2: Clasificar las partes interesadas Posiciones
Desarrollar una buena comprensión de los actores más importantes y registrar este análisis (como se muestra en el ejemplo de la
Tabla 8) para referencia y refrescarse durante el proyecto.
Tabla 8: Ejemplo Análisis de los actores
Tenedor de Capacidad de Adjunto Adjunto El Compromiso

apuestas Tenedor de alterar actual requerida compromiso requerida Necesario
Grupo apuestas el cambio en pie en pie actual Apoyo
CIO John Smith H METRO H L METRO H
Jeff
director de Finanzas Brown METRO METRO METRO L METRO METRO
Paso 3: Determinar el enfoque de gestión de las partes interesadas
Este paso permite al equipo ver fácilmente que se espera que las partes interesadas para ser bloqueantes o críticos, y que las partes
interesadas puedan ser defensores y partidarios de la iniciativa.

Calcule el poder de las partes interesadas, la influencia y el interés, con el fin de centrar el compromiso de arquitectura de la empresa en
los individuos clave. Estos pueden ser mapeadas a una matriz de poder / interés, lo que también indica la estrategia es necesario adoptar
para encajar con ellos.
La figura 4 muestra una matriz de ejemplo la red eléctrica.
Figura 4: Power Grid
Paso 4: Sastre Engagement Deliverables
Identificar catálogos, matrices y diagramas de que el compromiso arquitectura necesita para producir y validar con cada grupo
de interés para ofrecer un modelo de arquitectura eficaz.
Es importante prestar especial atención a los intereses de los participantes mediante la definición de catálogos específicos, matrices y
diagramas que son relevantes para un modelo de arquitectura de la empresa en particular. Esto permite a la arquitectura para ser
comunicada a, y entendido por todas las partes interesadas, y les permite verificar que la iniciativa de arquitectura de la empresa se
ocupará de sus preocupaciones.
3.11 plan de comunicaciones
arquitecturas empresariales contienen grandes volúmenes de información compleja e interdependiente. La comunicación eficaz de
la información dirigida a las partes interesadas adecuadas en el momento adecuado es un factor crítico de éxito para la arquitectura
empresarial. Desarrollo de un plan de comunicaciones para la arquitectura en la Fase A permite esta comunicación se lleve a cabo
dentro de un proceso planificado y gestionado.
Los contenidos típicos de un plan de comunicaciones son:
• Identificación de los interesados y la agrupación de los requisitos de comunicación
• Identificación de las necesidades de comunicación, mensajes clave en relación con la arquitectura de la visión, los riesgos de
comunicación, y los factores críticos de éxito (CSF)
• La identificación de los mecanismos que se utilizarán para comunicarse con las partes interesadas y permitir el acceso a la información de
arquitectura, tales como reuniones, boletines de noticias, repositorios, etc.
• La identificación de un calendario de comunicaciones, que muestra qué se producen las comunicaciones con la que las partes
interesadas grupos en qué momento y en qué lugar

3.12 Evaluación de la Preparación transformación del negocio
La técnica conocida como Evaluación de la transformación del negocio de preparación se lleva a cabo en la Fase A y se utiliza para
evaluar y cuantificar la disposición de una organización a sufrir modificaciones. La comprensión de la disposición de la organización para
aceptar el cambio, la identificación de los problemas, y luego tratar con ellos es una parte clave del éxito de la transformación arquitectura.
Se recomienda esta evaluación a ser un esfuerzo conjunto entre el personal de las empresas, líneas de negocio, y los planificadores de TI.
Las actividades recomendadas son:
• Determinar los factores de preparación que afectarán a la organización
• Presentar los factores de preparación para el uso de modelos de madurez
• Evaluar los riesgos para cada factor de preparación e identificar acciones de mejora para mitigar el riesgo
Documentar los hallazgos en la capacidad de evaluación (véase la Sección 3.13), y luego incorporar las acciones en la
aplicación y el Plan de Migración.
3.13 Evaluación de la capacidad
Antes de embarcarse en una arquitectura Definición detallada, es valioso para entender el nivel de capacidad de referencia y
objetivos de la empresa. Esta evaluación de la capacidad se lleva a cabo en la primera fase A, y se actualiza en la fase E. Se
puede examinarse en diversos niveles:
• ¿Cuál es el nivel de capacidad de la empresa en su conjunto? ¿De dónde viene la empresa desean aumentar u optimizar la
capacidad? ¿Cuáles son las áreas de enfoque de arquitectura que apoyarán el desarrollo deseado de la empresa?
• ¿Cuál es el nivel de capacidad o madurez de la función de TI dentro de la empresa? ¿Cuáles son las probables consecuencias de la
realización del proyecto de arquitectura en términos de diseño o de gobierno, gobernabilidad operativa, habilidades y estructura de
la organización? ¿Qué es un estilo apropiado, nivel de formalidad, y la cantidad de detalle para el proyecto de arquitectura para
encajar con la cultura y la capacidad de la organización de TI?
• ¿Cuál es la capacidad y la madurez de la función de la arquitectura dentro de la empresa? ¿Qué activos arquitectónicos se
encuentran actualmente en existencia? Son mantenidos y precisa? ¿Qué normas y modelos de referencia deben tenerse en
cuenta? ¿Es probable que haya oportunidades para crear activos reutilizables durante el proyecto de arquitectura?
• Donde existen vacíos de capacidad, en qué medida es el negocio listo para transformar el fin de alcanzar la capacidad objetivo?
¿Cuáles son los riesgos para la transformación, las barreras culturales, y otras consideraciones que deben abordarse más allá de la
brecha de capacidad básica?
El siguiente contenido son típicos dentro de un entregable evaluación de la capacidad:
• Evaluación de la capacidad del negocio, incluyendo:
• Capacidades de la empresa

• evaluación del estado de la línea de base el nivel de rendimiento de cada capacidad
• la aspiración estado futuro para el nivel de rendimiento de cada capacidad
• evaluación del estado basal de cómo se realiza cada capacidad
• la aspiración estado futuro de cómo cada capacidad debe tenerse en cuenta
• La evaluación de posibles impactos a la organización empresarial que resultan de la implementación exitosa de la

arquitectura destino
• Evaluación de la capacidad de TI, incluyendo:
• La línea de base y la madurez objetivo de nivel de proceso de cambio
• La línea de base y la madurez objetivo de nivel de los procesos operativos
• la capacidad de la línea de base y la evaluación de la capacidad
• La evaluación de posibles impactos a la organización de TI que resultan de la implementación exitosa de la

arquitectura destino
• Evaluación de Madurez arquitectura, incluyendo:
• Arquitectura procesos de gobierno, organización, roles y responsabilidades
• evaluación de habilidades Arquitectura
• Amplitud, profundidad y calidad de definición del paisaje dentro del Repositorio de Arquitectura
• Amplitud, profundidad y calidad de definición de normas dentro del Repositorio de Arquitectura
• Amplitud, profundidad y calidad del modelo de referencia dentro de la definición de repositorio Arquitectura
• Evaluación del potencial de reutilización
• Evaluación de la Preparación transformación del negocio, incluyendo:
• factores de preparación
• Visión para cada factor disposición
• clasificaciones de preparación actual y objetivo
• riesgos de preparación
3.14 Gestión de riesgos
Identificación de los riesgos de transformación de negocio y actividades de mitigación se determina por primera vez en la gestión de
riesgos Fase A., documentada en TOGAF, Parte III, Capítulo 31, es una técnica utilizada para mitigar el riesgo en la aplicación de un
proyecto de arquitectura. Incluye un proceso de gestión del riesgo que consiste en las siguientes actividades:

• clasificación de riesgo
• Identificación de riesgo
• evaluación inicial de riesgos
• mitigación de riesgos y evaluación de riesgos residuales
• seguimiento del riesgo
Se recomienda que las actividades de mitigación de riesgos se incluirán en el Estado de Arquitectura trabajo.
3.15 Arquitectura definición de documento
El documento de definición de la arquitectura es el contenedor para entregar los artefactos arquitectónicos básicos creados durante un
proyecto y para obtener información relacionada importante. El documento de la Arquitectura definición abarca todos los dominios de la
arquitectura (de negocios, datos, aplicaciones y tecnología) y también examina todos los estados relevantes de la arquitectura (línea de
base, de transición y de destino).
Se crea por primera vez en la fase A, donde se rellena con artefactos creados para apoyar la Architecture Vision. Se actualiza en
la Fase B, con materiales relacionados con la arquitectura de negocios y actualizado posteriormente con material de Sistemas de
Información de Arquitectura en la fase C, y luego con material de Arquitectura de la tecnología en la Fase D. Cuando el alcance
del cambio para implementar la arquitectura destino requiere un enfoque incremental , el Documento de definición de la
arquitectura se actualizará para incluir uno o más arquitecturas de transición en la fase E (véase la Sección 3.27).
El documento de definición de la arquitectura es un complemento de la especificación de requisitos de arquitectura, con un

objetivo complementario:
• El documento de definición de la arquitectura proporciona una visión cualitativa de la solución y tiene por objeto comunicar la
intención de los arquitectos.
• La especificación de requisitos de arquitectura ofrece una visión cuantitativa de la solución, indicando criterios
medibles que se deben cumplir durante la implementación de la arquitectura.
Los siguientes contenidos se encuentran típicamente dentro de un documento de la Arquitectura Definición:
• Alcance
• Metas, los objetivos y las limitaciones
• principios de la arquitectura
• Arquitectura línea de base
• modelos de arquitectura (por cada estado para ser modelado):
• Arquitectura modelos de negocio
• modelos de arquitectura de datos

• modelos de arquitectura de aplicaciones
• modelos Tecnología Arquitectura
• Fundamento y justificación de enfoque arquitectónico
• Mapeo de Arquitectura Repositorio:
• Mapeo de Arquitectura del Paisaje
• Mapeo de los modelos de referencia
• Mapeo de las normas
• La reutilización de evaluación
• Análisis de las deficiencias
• Evaluación de impacto
• Arquitectura de transición (véase la Sección 3.27)
En las siguientes secciones se ven en cada una de las arquitecturas más detalle.
3.15.1 Arquitectura de Negocios
La arquitectura de negocios se desarrolla en la Fase B. Los temas que deben ser abordados en el documento de definición de la
arquitectura de negocios relacionados con la arquitectura son los siguientes:
• Arquitectura línea base de negocios, en su caso - esta es una descripción de la arquitectura existente de negocios
• Objetivo Arquitectura de negocios, incluyendo:
• Estructura de la organización - la identificación de lugares de negocios y relacionándolos con las unidades

organizativas
• metas y objetivos de negocio - para la empresa y cada unidad organizativa
• funciones de negocios - A, etapa recursiva detallada que implica la descomposición sucesiva de las principales áreas
funcionales en subfunciones
• servicios de negocio - los servicios que la empresa y cada unidad de la empresa presta a sus clientes, tanto
interna como externamente
• Los procesos de negocio, incluyendo medidas y resultados
• Las funciones de negocio, incluyendo el desarrollo y la modificación de las necesidades de cualificación
• modelo de datos de negocios
• La correlación de la organización y funciones - relacionar las funciones de negocio a las unidades organizativas en la forma de un
informe de matriz
• Vistas correspondientes a los puntos de vista seleccionados frente a problemas clave de las partes interesadas

3.15.2 Arquitecturas de Sistemas de Información
La información arquitecturas de sistemas se desarrollan en la Fase C. Los temas que deben ser abordados en el documento de
definición de la arquitectura en relación con las arquitecturas de los sistemas de información son los siguientes:
• Arquitectura de datos de línea de base, en su caso
• Arquitectura de datos de destino, incluyendo:
• modelo de datos de negocios
• modelo de datos lógicos
• modelos de procesos de gestión de datos
• Datos Entidad / Empresa matriz de funciones
• Arquitectura de Datos vistas correspondientes a los puntos de vista seleccionados frente a problemas clave de las partes
interesadas
• Arquitectura de aplicaciones de línea de base, en su caso
• Objetivo Arquitectura de aplicaciones, incluyendo:
• Sistemas de proceso modelo
• modelo de sistemas lugar
• Tiempo modelo de sistemas
• modelo de sistemas de personas
• vistas arquitectura de aplicación correspondientes a los puntos de vista seleccionados frente a problemas clave de las partes
interesadas
3.15.3 Arquitectura tecnología
La Arquitectura de la tecnología se ha desarrollado como parte de la Fase D. Los temas que deben ser abordados en el documento de
definición de la arquitectura relacionados con la arquitectura de tecnología son los siguientes:
• Arquitectura Tecnología de línea de base, en su caso
• Arquitectura Tecnología de destino, incluyendo:
• componentes de la tecnología y su relación con los sistemas de información
• plataformas tecnológicas y su descomposición, que muestra las combinaciones de la tecnología necesarios para
hacer realidad una tecnología en particular “pila”
• Entornos y ubicaciones - una agrupación de la tecnología necesaria en entornos de computación (por

ejemplo, desarrollo, producción)
• carga de procesamiento esperado y distribución de la carga entre los componentes de tecnología

• (red) de comunicaciones físicas
• Las especificaciones de hardware y de red
• Vistas correspondientes a los puntos de vista seleccionados frente a problemas clave de las partes interesadas
3.16 Requisitos Arquitectura Especificación
La especificación de requisitos de arquitectura proporciona un conjunto de datos cuantitativos que describen lo que un proyecto
de implementación debe hacer con el fin de cumplir con la arquitectura. Una especificación de requisitos de arquitectura
típicamente formará un componente importante de un contrato de ejecución o contrato para la definición de la arquitectura más
detallada.
Como se mencionó anteriormente, la especificación de requisitos de arquitectura es un compañero con el Documento de definición de
la arquitectura, con un objetivo complementario para proporcionar la vista cuantitativo.
El siguiente contenido son típicos dentro de una especificación de requisitos de arquitectura:
• medidas de éxito
• requisitos de arquitectura
• contratos de servicios empresariales
• contratos de servicios de aplicaciones
• directrices de implementación
• Las especificaciones de implementación
• estándares de implementación
• requisitos de interoperabilidad (véase la Sección 3.16.4)
• requisitos de gestión de servicios de TI
• restricciones
• supuestos
3.16.1 Requisitos de la arquitectura de negocio
Arquitectura requisitos de negocio que pueblan la especificación de requisitos de arquitectura en la Fase B incluyen:
• Requerimientos técnicos
Un conjunto inicial de requisitos técnicos debe ser generada como la salida de la Fase B (Arquitectura de Negocios).
Estos son los controladores para el trabajo de la configuración tecnología que sigue, y deben identificar, categorizar y
priorizar las implicaciones para el trabajo en el

restante dominios de arquitectura; por ejemplo, por una matriz de dependencia / prioridad (por ejemplo, guiando de compromiso entre la
velocidad de procesamiento de transacciones y de seguridad); una lista de los modelos específicos que se espera a ser producido (por
ejemplo, expresado como primitivas del Marco Zachman).
• requisitos de negocio actualizados
La técnica de escenarios de negocio se utiliza para descubrir y requisitos de documentos de negocio.
3.16.2 Requisitos de Sistemas de Información Arquitecturas
requisitos de información de arquitecturas de sistemas que pueblan la especificación de requisitos de arquitectura en la Fase C
incluyen:
• requisitos de interoperabilidad de datos
• requisitos de interoperabilidad de aplicaciones
• Áreas donde la arquitectura de negocios puede tener que cambiar a fin de cumplir con los cambios en los datos y / o
Arquitectura de aplicaciones
• Las limitaciones de la Tecnología de la Arquitectura a punto de ser diseñados
• Actualizado requisitos de negocio, si es apropiado
• requisitos de las aplicaciones actualizadas, en su caso
• requisitos de datos actualizados, en su caso
3.16.3 Requisitos Arquitectura Tecnología
Arquitectura requisitos tecnológicos que pueblan la especificación de requisitos de arquitectura en la Fase D incluyen:
• requisitos tecnológicos actualizados
3.16.4 Requisitos de interoperabilidad
La determinación de la interoperabilidad está presente en todo el ciclo de ADM. Un conjunto de directrices se proporciona en
TOGAF, Parte III, Capítulo 29, para la definición y establecimiento de requisitos de interoperabilidad.
3.17 Arquitectura Hoja de Ruta
La Hoja de Ruta de Arquitectura enumera los paquetes de trabajo individuales que realizarán la arquitectura destino y las coloca en
una línea de tiempo para mostrar la progresión de la arquitectura de línea de base a la arquitectura destino. La Hoja de Ruta de
Arquitectura destaca paquetes de trabajo individuales "valor de negocio en cada etapa. Arquitecturas de transición necesarias para
realizar con eficacia la arquitectura destino se identifican como pasos intermedios. La hoja de ruta La arquitectura es de forma
incremental

desarrollado a lo largo Fases E y F, e informado por los componentes de la hoja de ruta desarrollados en las Fases B, C, y D.
Los siguientes contenidos se encuentran típicamente dentro de una hoja de ruta Arquitectura:
• cartera paquete de trabajo:
• Descripción del paquete de trabajo (nombre, descripción, objetivos, entregables)
• Requerimientos funcionales
• dependencias
• Relación a las oportunidades
• Relación con la arquitectura Definición de documentos y requisitos de arquitectura Especificación
• Valor de negocio
• Evaluación de la instrumentación Factor y la matriz Deducción, incluyendo:
• riesgos
• Cuestiones
• supuestos
• dependencias
• Comportamiento
• Impacto
• Las lagunas consolidados, soluciones y Dependencias de la matriz, incluyendo:
• dominio de la arquitectura
• Brecha
• Las soluciones potenciales
• dependencias
• Arquitecturas de transición, en su caso
• recomendaciones para la implementación:
• Criterios y / o medidas de eficacia de los proyectos
• Riesgos y problemas
• Solución Building Blocks (SBB)

3.18 Los escenarios de negocio
El ADM tiene su propio método (un “método dentro de otro método”) para identificar y articular los requerimientos del negocio implicados en la
nueva funcionalidad de negocio para hacer frente a los conductores clave del negocio, y los requisitos de arquitectura implícitas. Este proceso
se conoce como “escenarios de negocio”.
Un escenario de negocios es una descripción de un problema de negocio, lo que permite a los requisitos que deben
considerarse en relación unos con otros en el contexto del problema general. Sin tal descripción para servir como contexto, el
valor de negocio de la solución del problema no está clara, la relevancia de las posibles soluciones es clara, y existe el peligro
de la solución que se basa en un conjunto inadecuado de los requisitos.
Un factor clave en el éxito de cualquier otro proyecto importante es la medida en la que está vinculado a los requerimientos del
negocio, y demostrablemente apoya y permite a la empresa a alcanzar sus objetivos de negocio. escenarios de negocio son una
técnica importante para ayudar a identificar y entender las necesidades del negocio.
La técnica se puede utilizar de forma iterativa, en diferentes niveles de detalle en la descomposición jerárquica de la Arquitectura
de Negocios. El proceso de escenarios de negocio genérico es el siguiente:
• Identificar, documentar y clasificar el problema que está impulsando el proyecto
• Documento, como modelos de arquitectura de alto nivel, el negocio y los entornos técnicos donde está ocurriendo la
situación del problema
• Identificar y objetivos documento deseado; los resultados del manejo de los problemas con éxito
• Identificar los actores humanos y su lugar en el modelo de negocio, los participantes humanos, y sus roles
• Identificar los actores de ordenador y su lugar en el modelo de la tecnología, los elementos de computación, y sus roles
• Identificar y documentar los roles, responsabilidades y medidas de éxito por el actor, los scripts requeridos por el
actor, y los resultados deseados de manejar la situación adecuadamente
• Compruebe si la aptitud para el propósito de inspirar la posterior obra de arquitectura, y refinar sólo si es necesario
3.19 Análisis de las deficiencias
La técnica conocida como análisis de brecha es ampliamente utilizado en el ADM para validar una arquitectura que se está desarrollando.
Por lo general, es el paso final dentro de una fase. La premisa básica es poner de relieve un déficit entre la arquitectura de línea de base y
la arquitectura destino; es decir, los elementos que se han omitido deliberadamente, accidentalmente dejado fuera, o aún no definidos.
Los pasos son los siguientes:
• Elaborar una matriz con todos los bloques de construcción de la arquitectura (ABBS) de la arquitectura de línea de
base en el eje vertical, y todos los de ABB de la arquitectura de objetivo en el eje horizontal.

• Añadir al eje de la línea de base Arquitectura una última fila con la etiqueta “New de ABB”, y para la arquitectura destino eje A
última columna etiquetada “eliminada” de ABB.
• Cuando un ABB está disponible tanto en la línea de base y Target Arquitecturas, grabar esto con “Incluido” en la celda de
intersección.
• Cuando un ABB de la arquitectura de línea de base no se encuentra en la arquitectura destino, cada uno debe ser
revisado. Si se elimina correctamente, marcarlo como tal en la celda “Eliminado” apropiado. Si no fue así, usted ha
descubierto una omisión accidental en su Arquitectura objetivo que debe ser abordado por el restablecimiento de la ABB
en la siguiente iteración del diseño de la arquitectura - marcarlo como tal en la apropiada “Eliminado” célula.
• Cuando un ABB de la arquitectura destino no se puede encontrar en la arquitectura de línea de base, se marca en la intersección con la
línea “Nueva” como una brecha que hay que llenar, ya sea mediante el desarrollo o la adquisición del bloque de construcción.
Cuando el ejercicio se ha completado, cualquier cosa bajo “Servicios eliminados” o “nuevos servicios” es una brecha, que o bien debe ser
explicado como correctamente eliminado o marcado como ser abordado por el restablecimiento o el desarrollo / adquisición de la función.
La Tabla 9 muestra ejemplos de brechas entre la arquitectura de línea de base y la arquitectura destino; en este caso los elementos que
faltan son los “servicios de difusión” y “servicios compartidos” de pantalla.

Tabla 9: Análisis Gap Ejemplo
Arquitectura
de destino • Videoconferencia Servicios de
Lista de Servicios de Servicios
Arquitectura línea de telefonía
mensajería eliminadas •
Servicios mejoradas
base •
Servicios de Eliminado
radiodifusión intencionadamente
Videoconferencia
Incluido
Servicios
Servicios de
telefonía Partido potencial
mejoradas
Involuntariamente excluidos
pantalla compartida
- un vacío en la arquitectura
Servicios
de destino
Gap: Enhanced Gap: Enhanced

servicios a ser servicios a ser
desarrollados o desarrollados o
Nuevo •
producidos producidos
La técnica de análisis de la brecha se debe utilizar en las fases B, C, D, y E de la ADM.
3.20 Puntos de vista de arquitectura
El arquitecto utiliza puntos de vista y puntos de vista en el ciclo de ADM durante las Fases A a D para el desarrollo de arquitecturas
para cada dominio (de negocios, datos, aplicaciones y Tecnología). Una “vista” es lo que se ve. Un “punto de vista” es donde se busca
a partir; el punto de vista o perspectiva que determina lo que se ve (un punto de vista también puede ser pensado como un esquema).
Puntos de vista son genéricos, y pueden ser almacenados en las bibliotecas para su reutilización. Una vista es siempre específica a la
arquitectura para la que se creó. Cada punto de vista tiene un punto de vista asociada que describe, al menos implícitamente.

ISO / IEC 42010: 2007 anima a los arquitectos para definir los puntos de vista de manera explícita. Hacer esta distinción entre el contenido y el
esquema de una vista puede parecer en un principio a ser una sobrecarga innecesaria, sino que proporciona un mecanismo para la reutilización de
los puntos de vista a través de diferentes arquitecturas.
Para ilustrar los conceptos de opiniones y puntos de vista, considere el ejemplo 1. Se trata de un sistema aeroportuario muy simple
con dos partes diferentes: el piloto y el controlador de tráfico aéreo.
Ejemplo 1: Vistas y puntos de vista para un sistema simple Aeropuerto
Opiniones y puntos de vista para un sistema simple Aeropuerto
El piloto tiene un punto de vista del sistema, y el controlador de tráfico aéreo tiene otro. Ni vista representa todo el sistema, debido a
la perspectiva de cada actor limita (y reduce) cómo cada uno ve el sistema global.
La vista del piloto comprende algunos elementos no vistos por el controlador, tales como los pasajeros y de combustible, mientras que la vista
de la controlador comprende algunos elementos no vistos por el piloto, como otros planos. También hay elementos compartidos entre los
puntos de vista, tales como el modelo de comunicación entre el piloto y el controlador, y la información vital sobre el avión en sí.
Un punto de vista es un modelo (o descripción) de la información contenida en una vista. En este ejemplo, un punto de vista es la descripción
de cómo el piloto ve el sistema, y el otro punto de vista es cómo el controlador ve el sistema. Los pilotos describen el sistema desde su
perspectiva, utilizando un modelo de su posición y vector hacia o lejos de la pista de aterrizaje. Todos los pilotos utilizar este modelo, y el
modelo tiene un lenguaje específico que se utiliza para capturar información y poblar el modelo. Controladores describen el sistema de manera
diferente, utilizando un modelo del espacio aéreo y las ubicaciones y los vectores de la aeronave dentro del espacio aéreo. Una vez más,
todos los controladores utilizan un lenguaje común derivada del modelo común con el fin de capturar y comunicar la información pertinente a
su punto de vista.
Afortunadamente, cuando los controladores de hablar con los pilotos, que utilizan un lenguaje común de comunicación. (En otras palabras, los modelos que
representan sus puntos de vista individuales parcialmente cruzan.) Parte de este lenguaje común es acerca de la ubicación y los vectores de aviones, y es
esencial para la seguridad. Así que, en esencia, cada punto de vista es un modelo abstracto de cómo todas las partes interesadas de un tipo particular - todos los
pilotos, o todos los controladores - Ver el sistema aeroportuario. La interfaz con el usuario humano de una herramienta es típicamente cerca del modelo y el
idioma asociado con el punto de vista. Las herramientas únicas del piloto son indicadores de combustible, altitud, velocidad y ubicación. La herramienta principal
del controlador es radar. La herramienta común es una radio.
Para resumir del Ejemplo 1, podemos ver que un punto de vista puede subconjunto del sistema a través de la perspectiva de la
parte interesada, tal como el piloto versus el controlador. Este subconjunto puede ser descrito por un modelo abstracto llamado un
punto de vista, tal como un vuelo aéreo versus un modelo de espacio de aire. Esta descripción de la vista se documenta en un
idioma parcialmente especializados, tales como “piloto-hablar” versus “Controlador-hablar”. Las herramientas son usadas para
ayudar a las partes interesadas, y que la interfaz entre sí en términos del lenguaje derivado del punto de vista. Cuando los actores
usan herramientas comunes, como el contacto por radio entre el piloto y el controlador, un lenguaje común es esencial.
3.21 Arquitectura Vistas
Arquitectura vistas son representaciones de la arquitectura general que son significativos para una o más partes interesadas en
el sistema. El arquitecto elige y desarrolla un conjunto de puntos de vista en el ciclo de ADM durante las Fases A a D que
permiten a la arquitectura que debe ser comunicada a, y comprendido por, todas las partes interesadas, y que puedan verificar
que el sistema se ocupará de su

preocupaciones. Los conceptos en la sección 5.3 son fundamentales para el uso de puntos de vista dentro de la arquitectura TOGAF.
3.21.1 Vistas desarrollar en el ADM
La elección de qué puntos de vista particulares de arquitectura para desarrollar es una de las decisiones clave que el arquitecto tiene que hacer.
El arquitecto tiene la responsabilidad de asegurar la integridad (aptitud para el propósito) de la arquitectura, en términos de abordar
adecuadamente todas las preocupaciones pertinentes de sus grupos de interés; y la integridad de la arquitectura, en términos de
conexión de todas las diversas vistas de la otra, de manera satisfactoria conciliar las preocupaciones en conflicto de las diferentes partes
interesadas, y que muestra las compensaciones realizadas de este modo (como entre la seguridad y el rendimiento, por ejemplo).
3.22 Arquitectura Building Blocks
Arquitectura Building Blocks (Abs) son documentación de la arquitectura y los modelos de la empresa "s Arquitectura
Repositorio clasificado de acuerdo con el Continuum Arquitectura (véase el Capítulo 6). Se definen o se seleccionan durante
la aplicación de la ADM (principalmente en las Fases A, B,
C, y D). Las características de de ABB son los siguientes:
• Capturan requisitos de arquitectura; por ejemplo, requisitos de negocio, datos, aplicaciones y tecnología.
• Ellos dirigen y guían el desarrollo de la solución de bloques de construcción (SBB).
El contenido de las especificaciones ABB incluye lo siguiente como mínimo:
• funcionalidad fundamental y atributos: la semántica, sin ambigüedades, incluyendo la capacidad de seguridad y

manejabilidad
• Interfaces: conjunto elegido, suministrados (APIs, formatos de datos, protocolos, interfaces de hardware, estándares)
• La interoperabilidad y la relación con otros bloques de construcción
• bloques de construcción dependientes con funcionalidad requerida y las interfaces de usuario con nombre
• Mapa de las entidades de negocio / organizativos y políticas
Cada ABB debe incluir una declaración de cualquier documentación de la arquitectura y modelos de Arquitectura Repositorio de la
empresa que se pueden volver a utilizar en el desarrollo de la arquitectura. La especificación de bloques de construcción utilizando
el ADM es un proceso evolutivo e iterativo.
Vea la Sección 5.5 para más información.
3.23 Solución Building Blocks
Solución Building Blocks (SBB) se refieren a la serie continua de soluciones. Ellos son implementaciones de las
arquitecturas identificados en la empresa "s Arquitectura continuo y pueden ser tanto

adquiridos o desarrollados. SBB aparecen en la Fase E del ADM, donde se consideran bloques de construcción específicos
del producto por primera vez. SBB definir qué productos y componentes serán implementar la funcionalidad, definiendo de
este modo la aplicación. Cumplen los requisitos de negocio y son producto o proveedor-conscientes. El contenido de una
especificación SBB incluye los siguientes, como mínimo:
• funcionalidad y atributos específicos
• Interfaces; el conjunto implementado
• SBB exigidas utilizadas con la funcionalidad y los nombres de las interfaces necesarias usado
• Mapeo de los SBB a la topología de TI y las políticas operacionales
• Especificaciones de atributos compartidos tales como la seguridad, manejabilidad, capacidad de localización, escalabilidad
• Rendimiento, capacidad de configuración
• los conductores y las restricciones de diseño, incluyendo la arquitectura física
• Las relaciones entre los SBB y de ABB
3.24 Planificación basada en la capacidad
Fases E y F cuentan con un método detallado para la definición y planificación de transformación de la empresa basada en los principios de la
planificación basada en la capacidad, una técnica de planificación de negocios que se centra en los resultados de negocio. Es orientada a los
negocios y las empresas dirigidas por y combina los esfuerzos necesarios de todas las líneas de negocio para lograr la capacidad deseada. Se
adapta a la mayoría, si no todos, de los modelos de negocios corporativos y es especialmente útil en las organizaciones donde una capacidad
latente que den una respuesta (por ejemplo, una unidad de preparación para emergencias) y se requiere los mismos recursos están implicados en
múltiples capacidades. A menudo la necesidad de que estas capacidades se descubre y se refinó usando escenarios de negocio.
La Figura 5 ilustra la relación entre la planificación basada en la capacidad, la arquitectura de la empresa, y la gestión de la cartera
/ proyecto.
Figura 5: Relación entre las capacidades, la arquitectura empresarial, y Proyectos

3.25 Técnicas de planificación de la migración
Un número de técnicas se proporcionan para apoyar la planificación de migración en las Fases E y F. Estas se describen en las
siguientes secciones.
3.25.1 Evaluación de la instrumentación Factor y Matrix Deducción
La técnica de crear una evaluación de la instrumentación Factor y Matrix deducción se utiliza en la fase E a factores
que tienen un impacto en la implementación de la arquitectura y el Plan de Migración de documentos. La matriz
debe incluir una lista de los factores, sus descripciones, y las deducciones (conclusiones) que indican las acciones
o limitaciones que deben tenerse en cuenta al formular los planes.
Los factores típicos incluyen riesgos, problemas, supuestos, dependencias, las acciones y los impactos.
Una matriz de ejemplo se muestra en la Tabla 10.
Tabla 10: evaluación de la instrumentación Factor y Matrix Deducción
Factor de aplicación Matriz de evaluación y Deducción
Factor Descripción Deducción
<Nombre del Factor> <Descripción del Factor> <Impacto sobre el Plan de Migración>
Cambio en Tecnología Apagar los centros de mensajes, La necesidad de formación del personal, la
ahorro de 700 efectivos, y los han sustituido por correo reasignación
electrónico. El correo electrónico tiene importantes ahorros de personal y se
debe dar prioridad.
Consolidación de ... ...

Servicios
Introducción de un nuevo servicio ... ...

de atención al cliente
3.25.2 Las lagunas consolidados, soluciones y Matrix Dependencias
La técnica de crear una Gaps consolidados, soluciones y Dependencias Matrix permite al arquitecto grupo las lagunas identificadas en
los resultados de análisis de dominio de la arquitectura brecha y evaluar las posibles soluciones y dependencias a uno o más huecos.
Un ejemplo se muestra en la Tabla 11. Esta matriz se puede utilizar como una herramienta de planificación al crear paquetes de
trabajo. Las dependencias identificadas en coche a la creación de proyectos y planificación de la migración en las Fases E y F.
Tabla 11: Las lagunas consolidado, soluciones y Dependencias de la matriz
Las lagunas consolidados, soluciones y Depende ncies Matrix
# Arquitectura Brecha Soluciones posibles dependencias
1 Negocios Nuevo Proceso de procesamiento de Utilice la herramienta de software COTS proceso impulsa Aplicación
pedidos #2
Implementar solución personalizada

Las lagunas consolidados, soluciones y Depende ncies Matrix
# Arquitectura Brecha Soluciones posibles dependencias
2 Aplicación Aplicación de procesamiento de software comercial de herramienta X
New Order
se desarrollan en la casa
3 Información Cliente de base de información Utilice la base de clientes COTS Desarrollar
consolidada mercado de datos de clientes
3.25.3 Arquitectura de tabla de definición Incrementos
La técnica de crear una definición de la arquitectura Incrementos de la tabla permite al arquitecto para planificar una serie de Transición
Arquitecturas deberá describir la situación de la arquitectura de la empresa en momentos especificados. Una tabla debe elaborarse, como
se muestra en la Tabla 12, que enumera los proyectos y la asignación de sus entregas incrementales a través de las arquitecturas de
transición.
Tabla 12: Ejemplo de arquitectura Definición Incrementa la tabla
Arquitectura Defi norte Objetivos del Proyecto de Incremento: ition
abril 2009/2010 abril 2010/2011 abril 2011/2012
Arquitectura de Arquitectura de Arquitectura de
Transición 1: Transición 2: capacidad Transición 3:
Preparación operativa inicial Beneficios

Proyecto comentarios
La empresa de Formación y Procesos de e-licencias beneficios

correo Servicios Negocio capacidad Ciberempleo
de Capacidad
TI formularios electrónicos Diseño y construcción
TI e-Información para el Diseñar y construir de Common Client Data Datos Común de la

Medio Ambiente Información Ambiental Web Diseño de empresa de gestión de
contenidos y Construir documentos Diseño y

Construcción
... ... ... ... ...
3.25.4 Tabla Arquitectura de transición de estados Evolución
La técnica de crear el estado de la tabla evolución de la arquitectura de transición permite al arquitecto para mostrar el estado
propuesto de las arquitecturas en varios niveles utilizando el Modelo de Referencia Técnica (TRM).
Una tabla debe elaborarse, una lista de los servicios de la TRM utilizado en la empresa, las arquitecturas de transición, y
transformaciones propuestas, como se muestra en la Tabla 13.
Todos los bloques de construcción de la solución (SBB) debe ser descrito con respecto a su entrega y el impacto de estos servicios.
También deben estar marcados para mostrar la evolución de la arquitectura de la empresa. En el ejemplo, donde se ha alcanzado la
capacidad de destino, esto se muestra como “nuevas” o

"conservar"; donde la capacidad es la transición a una nueva solución, esta se marca como “transición”; y donde una capacidad va a ser
reemplazado, esto está marcado como “reemplazar”.
Tabla 13: Ejemplo de arquitectura de transición de estados Tabla Evolución
S arquitectónica t comió utilizando la referencia Mod Técnica EL
Transición Transición Transición

Subdominio Servicio Arquitectura 1 Arquitectura 2 Arquitectura 3
Las aplicaciones de Servicios de Sistema de Solución A La solución del sistema B-1 La solución del sistema B-2
infraestructura intercambio de (sustituir) (transición) (nuevo)
información
Servicios de Sistema de Solución D Sistema de Solución D Sistema de Solución D

gestión de datos (retener) (retener) (retener)
... ...
3.25.5 Técnica de Evaluación de negocios Valor
Una técnica para evaluar el valor de negocio es la elaboración de una matriz basada en una dimensión índice de valor y una
dimensión índice de riesgo. Un ejemplo se muestra en la Figura 6. El índice de valor deben incluir criterios tales como el
cumplimiento de los principios, la contribución financiera, la alineación estratégica, y la posición competitiva. El índice de riesgo debe
incluir criterios tales como el tamaño y la complejidad, la tecnología, la capacidad de organización, y el impacto de un fracaso. Cada
criterio se debe asignar un peso individual.
El índice y sus criterios y ponderación deben ser desarrollados y aprobados por la alta dirección. Es importante
establecer los criterios para la toma de decisiones antes de conocer las opciones.

Figura 6: Business Value Assessment Matrix
3.26 Plan de Implementación y Migración
La aplicación y el Plan de Migración se desarrolla en las Fases E y F, y proporciona un calendario de los proyectos para
la implementación de la arquitectura destino. La aplicación y el Plan de conversión incluye proyectos ejecutables
agrupados en carteras y programas administrados. La estrategia de implementación y migración identificar el enfoque
de cambio es un elemento clave de la aplicación y el Plan de Migración.
Los contenidos típicos son los siguientes:
• Implementación y Estrategia de migración:
• Dirección Estratégica de Implementación
• Enfoque secuencia de implementación
• Proyectos y carteras desglose de la ejecución:
• Asignación de los paquetes de trabajo de proyectos y carteras
• Capacidades entregadas por proyectos
• Hitos y temporización
• Estructura de desglose del trabajo

• Puede incluir impacto en la cartera, programas y proyectos existentes
Puede contener:
• las cartas de proyecto:
• paquetes de trabajo incluidos
• Valor de negocio
• De riesgo, problemas, supuestos, dependencias
• necesidades de recursos y costes
• Beneficios de la migración, determinada (incluyendo el mapeo de los requerimientos del negocio)
• Los costos estimados de las opciones de migración
3.27 Arquitectura transición
Si el ámbito del cambio para implementar la arquitectura destino requiere un enfoque gradual, uno o más arquitecturas de
transición se definen dentro de la salida de documentos definición de la arquitectura de la Fase E. Una arquitectura de
transición muestra la empresa en un estado de gran importancia arquitectónica entre la línea de base y Target arquitecturas.
Arquitecturas de transición se utilizan para describir las arquitecturas objetivo transitorias necesarias para la realización efectiva
de la arquitectura destino. Estos proporcionan la capacidad de identificar objetivos claros a lo largo de la hoja de ruta para la
realización de la arquitectura destino ..
El siguiente contenido son típicos dentro de una arquitectura de transición:
• Arquitectura de transición:
• Definición de estados de transición
• Arquitectura de negocios para cada estado de transición
• Arquitectura de datos para cada estado de transición
• Arquitectura de la aplicación para cada estado de transición
• Arquitectura tecnología para cada estado de transición
3.28 Implementación Modelo de Gobierno
Una vez que la arquitectura se ha definido, es necesario planificar cómo la arquitectura de transición que implementa la
arquitectura se regirá mediante la aplicación. Dentro de las organizaciones que han establecido funciones de arquitectura,
no es probable que sea un marco de gobierno ya

en su lugar, pero específicos procesos, organizaciones, roles, responsabilidades y medidas pueden necesitar ser definida sobre una base de
proyecto por proyecto.
El modelo de gobierno Implementación producido como una salida de la Fase F asegura que un proyecto de la transición a la
aplicación también transiciones sin problemas en la gobernabilidad arquitectura apropiada (para la Fase G).
Los contenidos típicos de un modelo de Gobierno de implementación son:
• los procesos de gobierno
• estructura de la organización gobernabilidad
• roles y responsabilidades de gobierno
• los puestos de control de gobierno y los criterios de éxito / fracaso
3.29 Los contratos Arquitectura
Los contratos de arquitectura se producen en la Fase G: Implementación de Gobierno. Los contratos de arquitectura son los
acuerdos conjuntos entre los socios de desarrollo y patrocinadores en la entregables, la calidad y la aptitud para el propósito
de una arquitectura. La implementación exitosa de estos acuerdos será entregado a través de la arquitectura eficaz. Mediante
la implementación de un enfoque gobernado a la gestión de los contratos, se asegurará la siguiente:
• Un sistema de monitorización continua para comprobar la integridad, los cambios, la toma de decisiones, y la auditoría de todas las
actividades relacionados con la arquitectura dentro de la organización
• La adhesión a los principios, las normas y los requisitos de las arquitecturas existentes o en desarrollo
• Identificación de riesgos en todos los aspectos del desarrollo y la implementación de la arquitectura (s) que cubre el
desarrollo interno con los estándares aceptados, políticas, tecnologías y productos, así como los aspectos operativos de
las arquitecturas de tal manera que la organización pueda continuar sus actividades dentro de una ambiente resiliente
• Un conjunto de procesos y prácticas que aseguren la rendición de cuentas, la responsabilidad y la disciplina en relación con el
desarrollo y el uso de todos los artefactos arquitectónicos
• Una comprensión formal de la organización de gobierno responsable del contrato, su nivel de autoridad, y el
alcance de la arquitectura bajo el gobierno de este órgano
TOGAF identifica dos contratos de ejemplo, como sigue:
• Arquitectura Diseño y Desarrollo de contrato
• Arquitectura contrato comercial Usuarios
Los contenidos típicos de un diseño Arquitectura y contrato de desarrollo son:
• Introducción y Antecedentes
• La naturaleza del acuerdo

• Alcance de la arquitectura
• Arquitectura y principios y requisitos estratégicos
• Los requisitos de conformidad
• el desarrollo de la arquitectura y el proceso de gestión y funciones
• medidas arquitectura objetivo
• fases definidas de entregables
• Priorizado plan de trabajo conjunto
• Ventana (s) Hora
• entrega de la arquitectura y las métricas de negocio
Los contenidos típicos de la arquitectura del contrato una empresa Usuarios producidos en la Fase G son:
• Introducción y Antecedentes
• La naturaleza del acuerdo
• Alcance
• requisitos estratégicos
• Los requisitos de conformidad
• adoptadores Arquitectura
• Ventana de tiempo
• Arquitectura métricas de negocio
• arquitectura de servicios (incluye Acuerdo de Nivel de Servicio (SLA))
Este contrato también se utiliza para gestionar los cambios en la arquitectura de la empresa en la Fase H.
3.30 Solicitud de cambio
Las solicitudes de cambio Arquitectura se consideran en la Fase H: Arquitectura de Gestión de Cambios.
Durante la implementación de una arquitectura, a medida que más a saberse, es posible que la definición de la arquitectura
original y requisitos no son adecuados o no son suficientes para completar la implementación de una solución. En estas
circunstancias, es necesario que los proyectos de implementación, ya sea a desviarse del enfoque arquitectónico sugerido o
para solicitar extensiones de alcance. Además, los factores externos - como los factores del mercado, los cambios en la
estrategia de negocio y nuevas oportunidades tecnológicas - puede abrir oportunidades para ampliar y refinar la arquitectura.
En estas circunstancias, una solicitud de cambio puede ser presentada con el fin de poner en marcha un nuevo ciclo de trabajo de arquitectura.

Los contenidos típicos de una solicitud de cambio son:
• Descripción del cambio propuesto
• Justificación de la propuesta de cambio
• La evaluación del impacto del cambio propuesto, incluyendo:
• Referencia a los requisitos específicos
• prioridad de los interesados de los requisitos hasta la fecha
• Fases para ser revisados
• Fase para dirigir en los requisitos de priorización
• Los resultados de las investigaciones de fase y las prioridades revisadas
• Recomendaciones sobre la gestión de los requisitos
• número de referencia Repositorio
3.31 Evaluación del cumplimiento
Una vez que la arquitectura se ha definido, es necesario para gobernar que la arquitectura a través de la aplicación para asegurarse
de que el original Visión Arquitectura se realiza de manera adecuada y que las lecciones de implementación se retroalimenta en el
proceso de la arquitectura. periódicas revisiones de cumplimiento de los proyectos de implementación en la Fase G proporcionan un
mecanismo para revisar el progreso del proyecto y asegurar que el diseño e implementación está avanzando en línea con los
objetivos estratégicos y arquitectónicos.
Los contenidos típicos de una Evaluación de cumplimiento son:
• Descripción general del progreso y el estado del proyecto
• Descripción general del proyecto de arquitectura / diseño
• Completadas las listas de comprobación de arquitectura:
• Hardware y sistema operativo lista de verificación
• servicios de software y middleware lista de verificación
• Aplicaciones listas de comprobación
• listas de control de gestión de la información
• listas de control de seguridad
• listas de control de gestión de sistemas
• listas de control de ingeniería de sistemas
• Métodos y herramientas de listas de comprobación

3.32 Evaluación de los requisitos de impacto
A lo largo de la ADM, la nueva información se hayan recogido durante una arquitectura. Como se recoge esta información, los
nuevos hechos pueden salir a la luz que invalida los aspectos existentes de la arquitectura. Una Evaluación de Impacto
Requisitos evalúa la arquitectura y los requisitos de especificación actual para identificar los cambios que se deben hacer y las
consecuencias de esos cambios.
En él se documenta una evaluación de los cambios y las recomendaciones para el cambio a la arquitectura. Los contenidos
recomendados son los siguientes:
• Referencia a los requisitos específicos
• prioridad de los interesados de los requisitos hasta la fecha
• Fases para ser revisados
• Fase para dirigir en los requisitos de priorización
• Los resultados de las investigaciones de fase y las prioridades revisadas
• Recomendaciones sobre la gestión de los requisitos
• número de referencia Repositorio
Estos se producen a menudo como una respuesta a una solicitud de cambio.

Capítulo 4 Directrices para la Adaptación

ADM
Este capítulo contiene las directrices para la adaptación de la ADM.
4.1 Introducción
El ADM es un método genérico para el desarrollo de la arquitectura, que está diseñado para hacer frente a la mayor parte del sistema y
los requisitos de organización. Sin embargo, a menudo será necesario modificar o ampliar el ADM para satisfacer necesidades
específicas. Una de las tareas antes de aplicar el ADM es revisar el proceso y sus resultados de aplicabilidad y, a continuación,
adaptarlos según corresponda a las circunstancias de la empresa individual. Esta actividad también puede producir un ADM “específica
de la empresa”.
Hay una serie de razones para querer adaptar el ADM a las circunstancias de una empresa individual. Algunas de las
razones se describen de la siguiente manera:
1. Una consideración importante es que el orden de las fases en el ADM es hasta cierto punto
depende de la madurez de la disciplina arquitectura dentro de la empresa en cuestión. Por ejemplo, si el caso empresarial
para hacer arquitectura no es bien reconocida, a continuación, crear una visión Arquitectura es esencial; y una arquitectura de
negocio detallado tiene que venir a continuación para definir el modelo de negocio para el trabajo de arquitectura restante, y
asegurar la participación activa de los actores clave en ese trabajo.
2. El orden de las fases también puede estar definida por los principios de negocio y la arquitectura de una
empresa. Por ejemplo, los principios de negocio pueden determinar que la empresa se prepara para ajustar sus procesos de negocio para
satisfacer las necesidades de una solución empaquetada, de modo que pueda ser implementado rápidamente para permitir una respuesta
rápida a los cambios del mercado. En tal caso, la configuración de asunto (o al menos la finalización de la misma) pueden así seguir a la
finalización de la Arquitectura de Sistemas de Información.
3. Una empresa puede desear usar o adaptar el ADM en conjunto con otra empresa
marco de arquitectura que tiene un conjunto definido de prestaciones específicas para un sector en particular verticales:
Gobierno, Defensa, e-business, telecomunicaciones, etc.
4. El ADM es uno de los muchos procesos empresariales que conforman el modelo de gobierno corporativo
para una empresa. El ADM es un complemento y apoyo de otros, los procesos de gestión del programa
estándar. La empresa adaptará el ADM para reflejar las relaciones con y dependencias de, los demás
procesos de gestión.
5. El ADM está siendo obligatorio para su uso por un contratista principal o el plomo en una externalización
situación, y debe adaptarse para lograr un compromiso adecuado entre las prácticas existentes del contratista y
los requisitos de la empresa contratante.

6. La empresa es una empresa de tamaño pequeño a mediano, y desea utilizar una versión de “corte hacia abajo” de
el ADM que está más orientado a la reducción del nivel de recursos y la complejidad del sistema típico de
dicho entorno.
7. La empresa es muy grande y complejo, que comprende muchos independientes, aunque interrelacionados
“empresas” en un marco de colaboración de negocios en general, y el método de la arquitectura tiene que adaptarse a
reconocer esta situación. Este tipo de empresas por lo general no pueden ser tratados con éxito como una sola entidad y
se requiere un enfoque más federados.
El proceso de ADM también se puede adaptar para hacer frente a un número de diferentes escenarios de uso, incluyendo diferentes estilos
de proceso (por ejemplo, el uso de iteración) y también arquitecturas especializadas específicos (tales como la seguridad). Estos son
discutidos en las siguientes secciones.
4.2 La aplicación de iteración a la ADM
El ADM es compatible con una serie de conceptos que podrían caracterizarse como iteración.
Iteración para desarrollar una arquitectura integral del paisaje:
• Los proyectos iterar a través de todo el ciclo de ADM, comenzando con la Fase A. Cada ciclo de la ADM, será atado
por una Solicitud de Trabajo Arquitectura. La salida de la arquitectura rellenará la arquitectura del paisaje, que se
extiende ya sea el paisaje descrito, o cambiando el paisaje cuando sea necesario.
• proyectos separados pueden operar sus propios ciclos de ADM al mismo tiempo, con las relaciones entre los diferentes
proyectos.
• Un proyecto puede desencadenar el inicio de otro proyecto. Por lo general, esto se utiliza cuando las iniciativas de arquitectura de
alto nivel a identificar oportunidades o soluciones que requieren una arquitectura más detallada, o cuando un proyecto identifica
impactos paisajísticos fuera del alcance de su solicitud de Arquitectura trabajo.
Iteración dentro de un ciclo de ADM:
• Los proyectos pueden operar múltiples fases ADM simultáneamente. Por lo general, esto se utiliza para gestionar la
inter-relación entre Arquitectura de Negocios, Sistemas de Información Arquitectura, Arquitectura y Tecnología.
• Los proyectos pueden ciclo entre las fases de ADM, en ciclos planificados que cubre múltiples fases. Típicamente, esto se utiliza
para converger en una arquitectura detallada de destino cuando la arquitectura de nivel superior no existe para proporcionar un
contexto y restricción.
• Los proyectos pueden volver a etapas anteriores con el fin de círculo hacia atrás y actualizar los productos de trabajo con la
nueva información. Por lo general, esto se utiliza para converger en un ejecutable Arquitectura Hoja de ruta o plan de ejecución y
Migración, cuando los detalles de implementación y el alcance del cambio provocan un cambio o re-priorización de las
necesidades de los interesados.
Iteración para gestionar la capacidad de Arquitectura:
• El resultado de hacer frente a una Solicitud de Arquitectura trabajo en la Fase A puede requerir una nueva iteración de la fase
preliminar para ajustar la capacidad de Arquitectura para la organización.

• Los cambios identificados en la Fase H pueden requerir una nueva iteración de la fase preliminar para ajustar la
capacidad de Arquitectura de la Organización.
Todas estas técnicas son aplicaciones válidas de la ADM y se puede utilizar para asegurar que el enfoque de desarrollo de
la arquitectura es suficientemente flexible para dar cabida a otros métodos y marcos.
TOGAF incluye la consideración de los factores de organización que influyen en el grado en que el ADM se debe utilizar
en una forma iterativa, diferentes estilos de iteración, y un mapeo de fases ADM a ciclos de iteración para la arquitectura
definición.
Un ciclo sugerido iteración para las iteraciones que abarcan múltiples fases ADM se muestra en la Figura 7.
Figura 7: ciclos de iteración
• Arquitectura Capacidad iteraciones apoyan la creación y la evolución de la capacidad de la arquitectura requerida. Este ciclo
incluye la movilización inicial de la actividad arquitectura para un propósito o compromiso arquitectura tipo determinado mediante
el establecimiento o ajuste el enfoque de la arquitectura, los principios, el alcance, la visión y la gobernabilidad.
• Desarrollo de la arquitectura iteraciones permiten la creación de contenidos por el ciclismo a través, o integrar, Negocios, Sistemas
de Información, y las fases de la arquitectura tecnológica. Estas iteraciones asegurar que la arquitectura es considerada como un
todo. En este tipo de comentarios de las partes interesadas de iteración son típicamente más amplio. A medida que las iteraciones
convergen en un objetivo, extensiones en las oportunidades y soluciones y fases de planeamiento de migración aseguran que se
considera aplicabilidad de la arquitectura como se finalice la arquitectura.

• Planificación de la transición iteraciones apoyan la creación de hojas de ruta de cambio formales para una arquitectura
definida.
• Arquitectura de Gobierno iteraciones apoyar la gestión de la actividad de cambio que progresa hacia una arquitectura
objetivo definido.
TOGAF define dos estilos de definición de la arquitectura:
• Primera línea de base: En este estilo, la arquitectura de línea de base se evalúa primero. Este procedimiento es adecuado cuando
una solución de destino no se entiende claramente.
• Objetivo Primero: En este estilo, la arquitectura destino se elabora en detalle y luego asigna de nuevo a la línea de base,
con el fin de definir la actividad de cambio. Este proceso es adecuado cuando un estado objetivo se acordó en un nivel alto y
la empresa desea evitar la proliferación de la práctica empresarial actual en el objetivo.
TOGAF mapas de ambos estilos a ciclos de iteración, como se ilustra en la Figura 8 y la Figura 9.
Figura 8: Actividad por iteración de Línea Base Primera definición de la arquitectura

Figura 9: Actividad por iteración para Target Primera definición de la arquitectura
TOGAF también describe una aplicación jerárquica de iteración donde se produce cada ciclo de ADM en un único nivel de
descripción de la arquitectura. Esta aproximación a la ADM utiliza la fase de planeamiento de migración de un ciclo ADM para iniciar
nuevos proyectos de arquitectura, más detalladas, que también van a desarrollar arquitecturas. Este tipo de iteración pone de relieve
la necesidad de una arquitectura de alto nivel para guiar y limitar la arquitectura más detallada. También destaca que la completa
arquitectura del paisaje es desarrollado por múltiples iteraciones ADM. Este enfoque se muestra en la Figura 10.

Figura 10: una jerarquía de ADM Procesos Ejemplo
4.3 La aplicación de la ADM a través de la arquitectura del paisaje
En una empresa típica, muchas arquitecturas serán descritos en la arquitectura del paisaje en cualquier punto en el tiempo. Algunas
arquitecturas abordarán necesidades muy específicas; otros serán más general. Algunos dirección del detalle; Algunos pueden ofrecer
una gran imagen. Para hacer frente a esta complejidad TOGAF utiliza los conceptos de niveles y el Continuum Enterprise para
proporcionar un marco conceptual para la organización de la arquitectura del paisaje.
Niveles proporcionan un marco para dividir la arquitectura del paisaje en tres niveles de granularidad:
1. Arquitectura estratégica proporciona un marco de organización para operacional y el cambio

la actividad y permite el ajuste de la dirección a un nivel ejecutivo.
2. segmento de Arquitectura proporciona un marco de organización para operacional y el cambio

la actividad y permite el ajuste de la dirección y el desarrollo de hojas de ruta arquitectura eficaz a nivel
programa o cartera.
3. capacidad de Arquitectura proporciona un marco de organización para la actividad de cambio y la

desarrollo de hojas de ruta arquitectura eficaz realizando incrementos de capacidad.
La Figura 11 muestra un resumen de la modelo de clasificación para la arquitectura paisajes.
Guía (2011) Copyright © 2009-2011 The Open Group. Todos los derechos reservados. sesenta y cinco

Figura 11: Resumen Clasificación Modelo de arquitectura del paisaje
TOGAF se describen los tipos de trabajo para que los arquitectos pueden ser obligados a realizar y cómo el ADM se pueden utilizar para
coordinar las actividades de los distintos equipos de arquitectos que trabajan en diferentes niveles. También ofrece dos estrategias para
utilizar el ADM como un proceso para apoyar las jerarquías de arquitecturas:
• Arquitecturas a diferentes niveles se pueden desarrollar a través de iteraciones dentro de un solo proceso de ADM.
• Arquitecturas a diferentes niveles se pueden desarrollar a través de una jerarquía de procesos ADM ejecutado simultáneamente.
En los extremos de la escala, cualquiera de estas dos opciones pueden ser totalmente aprobado. En la práctica, un arquitecto es probable que
tenga que mezclar elementos de cada uno para adaptarse a los requisitos exactos de su Solicitud de Arquitectura trabajo.
4.4 Arquitectura de Seguridad y el ADM
TOGAF proporciona una guía sobre las consideraciones de seguridad que deben abordarse durante la aplicación de la ADM .. Se
pretende ayudar tanto a los arquitectos empresariales y profesionales de seguridad para evitar la pérdida de los problemas de seguridad
críticos. Se informa al arquitecto de la empresa de lo que necesitará el arquitecto de seguridad para llevar a cabo durante el trabajo de
arquitectura de seguridad.
Todos los grupos de partes interesadas en la empresa tendrán problemas de seguridad y es deseable para traer un arquitecto de
seguridad en el proyecto lo antes posible. A lo largo de las fases de la ADM, se ofrece orientación sobre la información específica de
seguridad que deben ser reunidos, los pasos que se deben tomar, y artefactos que se deben crear. Arquitectura decisiones relacionadas
con la seguridad deben realizarse de conformidad con las decisiones empresariales y políticas y su gestión de riesgos. Las áreas
generalmente aceptadas de la preocupación por el arquitecto de seguridad son:

• Autenticación: La fundamentación de la identidad de una persona o entidad relacionada con la empresa o el sistema de
alguna manera.
• Autorización: La definición y aplicación de las capacidades permitidas para una persona o entidad cuya
identidad ha sido establecida.
• Auditoría: La capacidad de proporcionar datos forenses que conste que los sistemas han sido utilizados de conformidad con las
políticas de seguridad establecidas.
• Aseguramiento: La capacidad de probar y demostrar que la arquitectura de la empresa tiene los atributos de seguridad necesarias
para defender las políticas de seguridad establecidas.
• Disponibilidad: La capacidad de la empresa para funcionar sin interrupción del servicio o el agotamiento a pesar
eventos anormales o maliciosos.
• Protección de Activos: La protección de los activos de información de la pérdida o la divulgación no intencional, y los recursos de
usos no autorizados e involuntaria.
• Administración: La capacidad de añadir y cambiar las políticas de seguridad, añadir o cambiar la forma en políticas son implementadas
en la empresa, y añadir o cambiar las personas o entidades relacionadas con los sistemas.
• Gestión del Riesgo: La actitud de la organización y la tolerancia al riesgo.
artefactos arquitectura de seguridad típicas incluyen:
• Las reglas de negocio relacionados con el manejo de datos activos / información
• política de seguridad escrito y publicado
• datos codificados / información de la propiedad de activos y custodia
• documentación El análisis de riesgos
• documentación de la política de clasificación de datos
4.5 El uso de TOGAF para definir y Govern SOA
TOGAF describe arquitectura orientada a servicios (SOA) como un estilo arquitectónico, cómo la arquitectura de la empresa es compatible con
SOA, y proporciona orientación sobre el uso de TOGAF para desarrollar una SOA.
SOA, como un estilo arquitectónico, trata de simplificar el negocio, y la interoperación de sus partes, por la capacidad de estructuración
servicios granulares como bien definidos en contraposición a opaco, silo "unidades de negocio ed. Que permita la identificación de las
capacidades funcionales de una organización, y por lo tanto una oportunidad para reducir la duplicación. Al estandarizar el comportamiento
y la interoperabilidad de los servicios, es posible limitar los efectos del cambio y también para planificar el impacto de los cambios futuros.
arquitectura de la empresa ofrece marcos, herramientas y técnicas para ayudar a las organizaciones con el desarrollo y
mantenimiento de su SOA. Algunos de los beneficios clave que ofrece arquitectura de la empresa incluyen:

• abstracciones coherentes de las estrategias y los resultados de alto nivel para apoyar la planificación y análisis
• La unión de diferentes perspectivas a un sólo problema de negocio (por ejemplo, negocios, sistemas de información, la tecnología,
anchura, profundidad, nivel de detalle, etc.) que proporciona un modelo consistente para abordar diversos dominios y pruebas de
integridad
• Identificación de las hojas de ruta claras para alcanzar el estado futuro
• Trazabilidad que éste y otros activos vincula a los negocios que apoyan
• El apoyo a la evaluación del impacto, el riesgo / análisis de valor, y la gestión de la cartera
• principios identificados y documentados, restricciones, marcos, patrones y normas
• marcos de gobierno y procesos que aseguren la autoridad apropiada para la toma de decisiones
arquitectura de la empresa se convierte en una base para la implementación de un enfoque SOA dentro de una organización, porque:
• Se vincula las partes interesadas SOA juntos, asegurando que las necesidades de cada comunidad de partes interesadas se cumplen y
que cada comunidad de partes interesadas es consciente del contexto apropiado.
• Proporciona un enlace de negocio para TI que puede ser utilizado para justificar el costo de la misma reingeniería contra
el valor del negocio.
• Muestra qué servicios deben ser construidos y cómo deben ser reutilizadas.
• Se muestra cómo los servicios deben ser diseñados y cómo las plataformas deben interoperar.
• Se proporciona un depósito para conservar y mantener la información relacionada con el diseño de manera continua.
Sin arquitectura de la empresa, los efectos negativos pueden incluir uno o más de los siguientes:
• agilidad limitada
• Dificultad para identificar y orquestación de servicios SOA
• la expansión de servicios
• Exponencialmente crecientes desafíos de gobernabilidad
• Limitada interoperabilidad de los servicios SOA
• servicios SOA limitados reutilización
• Múltiples SOA silo'ed
• Dificultad evolucionando y cambiando las implementaciones de SOA

4.5.1 El uso de TOGAF para SOA
TOGAF proporciona una guía detallada para cada fase de la ADM en lo que debería tenerse en cuenta al aplicar el
principio de la voluntad de servicio. El resumen de alto nivel de este enfoque se da aquí. Los detalles están en TOGAF,
Parte III, Capítulo 22.
El uso de TOGAF para crear SOA requiere la adaptación de TOGAF para hacer frente a las exigencias de un estilo particular.
Dirigiéndose a un estilo requerirá:
• La identificación de las entradas principales del metamodelo
• La identificación de extensiones para el metamodelo contenido
• La identificación de los artefactos clave
• La identificación de los materiales de referencia de estilo específica y modelos de madurez
La adaptación de una capacidad para soportar Arquitectura SOA requiere una considerable actividad en la fase preliminar de
TOGAF. Estas actividades y herramientas SOA-específica Grupo Open SOA Grupo de trabajo incluyen:
• La adaptación del principio de la orientación a servicios
• Determinar la preparación para la organización SOA: OSIMM
• Gobernabilidad: The Open Group SGVM
• Particiones: Utilizar un centro especializado de excelencia para apoyar SOA
En el resto de las fases TOGAF ADM, lo que cambia es cómo se describe una arquitectura, analizado y documentado.
Durante una iteración de la ADM el practicante debe tener en cuenta las entidades metamodelo clave identificados, y los
artefactos identificados.
En diferentes niveles de granularidad el fin del ciclo de ADM variará. En el nivel estratégico funciona el propósito es
identificar si se necesita SOA, y en el que los segmentos. En Segmentlevel funciona el propósito es describir los requisitos
de estructura y la capacidad del SOA. Por último, en el trabajo a nivel de la Capacidad para identificar y describir los
requisitos de los servicios SOA que estarán disponibles.
Cuando la entrega de SOA con TOGAF, el practicante nunca debe perder de vista el objetivo final: soluciones SOA que
abordar la gestión de la complejidad de la empresa y proporcionar la agilidad del negocio.

Capítulo 5 Arquitectura contenido

Marco de referencia
En este capítulo se ofrece una introducción al marco de arquitectura de contenidos, un metamodelo estructurado para los artefactos
arquitectónicos.
5.1 Arquitectura de contenido del esquema general
Durante la ejecución de la ADM un número de salidas se producirá como resultado, tales como flujos de proceso, los requisitos
arquitectónicos, planes de proyectos, evaluaciones de cumplimiento de proyectos, etc. Con el fin de ser capaz de reunir y presentar
estos principales productos de trabajo en un consistente y de forma estructurada, es necesario contar con un marco de arquitectura de
contenidos dentro de los cuales colocarlos. Esto permite una fácil referencia y clasificación estándar, y también para ayudar a facilitar
la estructuración de las relaciones entre los diversos productos de trabajo constituyentes que componen lo que se refiere a menudo
como la “arquitectura de la empresa”.
El Marco de Arquitectura contenido proporcionado en TOGAF permite TOGAF para ser utilizado como un marco
independiente de la arquitectura dentro de una empresa. Sin embargo, existen otros marcos de contenido (tales como
ArchiMate y el Marco Zachman) y se espera que algunas empresas pueden optar por usar un marco externo en conjunción
con el ADM en su lugar. En estos casos, el Marco contenido TOGAF Arquitectura proporciona un punto de referencia y de
partida útil para el contenido TOGAF a ser mapeada a los metamodelos de otros marcos.
Con el fin de ayudar con la clasificación de los nuevos productos de trabajo y la posible necesidad de correlacionar con otros marcos de
contenido (incluyendo cualquier producto de trabajo de la configuración clasificada existentes), el Marco de Arquitectura de contenido usa
las siguientes tres categorías para describir el tipo de producto de trabajo de arquitectura dentro de su contexto de uso:
• UNA entregable es un producto de trabajo formal que se especifica contractualmente, y que normalmente se revisó, estuvo de
acuerdo y firmado por sus grupos de interés. Entregables a menudo representan la salida de los proyectos.
• Un artefacto es un producto de trabajo arquitectónico que describe un aspecto de la arquitectura. Los artefactos se clasifican
generalmente como catálogos (listas de cosas), matrices (que muestra las relaciones entre las cosas), y los diagramas (imágenes
de las cosas). Los ejemplos incluyen un catálogo requisitos, matriz de interacción de negocios, y un diagrama de casos de uso. Un
entregable arquitectónico puede contener muchos objetos y artefactos formarán el contenido del repositorio de Arquitectura.
• UNA bloque de construcción representa un componente (potencialmente reutilizable) de negocio, TI, o la capacidad de
arquitectura que se puede combinar con otros bloques de construcción para entregar arquitecturas y soluciones.

Los bloques de construcción pueden ser definidos en varios niveles de detalle y pueden relacionarse tanto a ““arquitecturas "" y
““soluciones "", con una arquitectura bloques de construcción (ABBS) típicamente que describen la capacidad requerida con el fin de
dar forma a la solución Building Blocks (SBB) lo que representaría los componentes que se utilizan para implementar la capacidad
requerida. Estos se discuten en la Sección 5.5.
Las relaciones entre entregables, artefactos y bloques de construcción se muestran en la Figura 12.
Figura 12: Las relaciones entre entregables, artefactos, y bloques de construcción
5.2 Metamodel contenido
El Marco de Arquitectura contenido se basa en un metamodelo contenido estándar que proporciona una definición para todos los
tipos de bloques de construcción que existen dentro de una arquitectura. Una visión general de alto nivel del metamodelo contenido
se muestra en la Figura 13. El metamodelo ilustra cómo se pueden describir estos bloques de construcción y cómo se relacionan
entre sí.
Al crear y gestionar arquitecturas, es necesario tener en cuenta varios aspectos tales como servicios empresariales, actores, las
aplicaciones, las entidades de datos y la tecnología. El metamodelo contenido pone de relieve estas preocupaciones, muestra sus
relaciones, e identifica los artefactos que pueden ser utilizados para representarlos de una manera coherente y estructurado.
Además, el metamodelo contenido puede ser utilizado para proporcionar orientación a todas las organizaciones que deseen implementar sus
arquitecturas usando una herramienta de arquitectura.

Figura 13: contenido Metamodel general
5.2.1 Núcleo y las extensiones
El modelo se ha estructurado a considerar núcleo y la extensión de contenido, donde el metamodelo núcleo proporciona un conjunto
mínimo de contenido arquitectónico que soporta la trazabilidad a través de artefactos, y las extensiones están enchufados a apoyar
cualquier modelado más específico o en profundidad que pueda ser requerida.
Las extensiones se agrupan lógicamente en catálogos, matrices y diagramas, lo que permite el enfoque en áreas de interés específico.
Todos los módulos de extensión son opcionales y deben ser seleccionados durante la fase preliminar de la iteración ADM para satisfacer
las necesidades de la organización. Las extensiones descritas en TOGAF son de carácter orientativo y se pueden añadir a, o adaptados en
consecuencia.
5.2.2 Catálogos, matrices y diagramas
Mientras que el metamodelo de contenido se utiliza para apoyar la estructuración de la información arquitectónica, la mayoría de las
partes interesadas no necesitan o desean saber los detalles contenidos en el Marco de Arquitectura contenido de esta manera. Por
lo tanto, se introdujo el uso de catálogos, matrices y diagramas para facilitar la presentación de información arquitectónica de modo
que pueda ser utilizado con fines de referencia y de gobierno más fácilmente.

Los catálogos son listas de bloques de construcción de un tipo o tipos específicos relacionados, las matrices son redes que muestran
relaciones entre dos o más entidades, y los diagramas son representaciones gráficas de contenido arquitectónico.
En resumen, los resultados de un ADM desarrollado la arquitectura se compone de una serie de de ABB definidos pobladas en los
catálogos de arquitectura, con las relaciones especificadas entre los bloques de construcción de las matrices de arquitectura, y luego se
presentan como diagramas de comunicación que muestran de una manera precisa y concisa lo que la arquitectura es.
5.3 Los artefactos arquitectónicos
TOGAF describe un conjunto de productos de trabajo atómicas que se crean durante el desarrollo de la arquitectura, siguiendo el ADM.
Estos productos de trabajo están etiquetados como artefactos y representan un modelo individual de un sistema, solución, o empresa
estatal, lo que podría potencialmente ser re-utilizado en una variedad de contextos.
Un artefacto es distinto de un entregable, que es una salida contraída de un proyecto. En la mayoría de los casos, los resultados
contendrán artefactos y cada artefacto pueden existir en muchas entregas. Los conceptos básicos y la terminología utilizadas en
esta sección se han adaptado de ISO / IEC 42010: 2007, que se describe en la Tabla 14 y se ilustra en la Figura 14. 6
Tabla 14: Conceptos relacionados con la arquitectura Vistas
Concepto Definición
Sistema Un sistema es una colección de componentes organizados para llevar a cabo una función específica o conjunto de funciones.
Arquitectura La arquitectura de un sistema es la organización fundamental del sistema, encarnado en su

componentes, sus relaciones entre sí y con el medio ambiente, y los principios que guían su diseño y
evolución.
Descripción Una descripción arquitectónica es una colección de objetos que documentan una arquitectura. En TOGAF, vistas
arquitectónica arquitectura son los artefactos clave en una descripción de la arquitectura.
Las partes interesadas Las partes interesadas son las personas que tienen un papel clave en, o preocupaciones sobre el sistema; por ejemplo,
como usuarios, desarrolladores o administradores. Diferentes actores con diferentes roles en el sistema tendrán diferentes
preocupaciones. Las partes interesadas pueden ser personas, equipos u organizaciones (o clases de los mismos).
preocupaciones Las preocupaciones son los intereses clave que son de vital importancia para los interesados en el sistema, y determinar la aceptabilidad
del sistema. Las preocupaciones pueden pertenecer a cualquier aspecto de del sistema de funcionamiento, el desarrollo, o la operación,
incluyendo consideraciones tales como el rendimiento, fiabilidad, seguridad, distribución y capacidad de evolución.
6 Reproducido con permiso del IEEE Std 1471-2000, Sistemas e Ingeniería de Software - Práctica de descripción arquitectónica de los sistemas intensivos en
software, derechos de autor © 2000 Recomendado, por IEEE. El IEEE se exime de cualquier responsabilidad resultante de la colocación y el uso de la manera
descrita.

Concepto Definición
Ver Una vista es una representación de un sistema de conjunto desde la perspectiva de un conjunto relacionado de preocupaciones. En la
captura o que representa el diseño de un sistema de "s arquitectura, el arquitecto se suelen crear uno o más modelos de arquitectura,
posiblemente utilizando diferentes herramientas. Una vista comprenderá partes seleccionadas de uno o más modelos, elegido con el
fin de demostrar a un grupo de interés particular o un grupo de partes interesadas que sus preocupaciones se abordan
adecuadamente en el diseño de la arquitectura del sistema.
Punto de vista Un punto de vista define la perspectiva desde la que se toma una vista. Más específicamente, un punto de vista
define: cómo construir y utilizar un punto de vista (por medio de un esquema o plantilla adecuada); la información que
debe aparecer en la vista; las técnicas de modelado para expresar y analizar la información; y una razón de estas
opciones (por ejemplo, describiendo el propósito y destinatario de la vista).
Figura 14: Conceptos básicos para la descripción arquitectónica

TOGAF proporciona un conjunto de artefactos recomendados, que se resumen en la Tabla 15.
Tabla 15: Recomendado por artefactos Fase ADM
Fase ADM Artefacto
Fase preliminar catálogo de principios
la fase A Mapa de los interesados valor de la matriz
diagrama de la cadena diagrama de solución
Concepto
La fase B Catálogo de organización / Actor conductor / Meta /

Catálogo de objetivo de servicio matriz de interacción
Catálogo Catálogo de servicios de rol de usuario / Función
Ubicación catálogo Proceso / Evento / Control / Catálogo
de productos contrato / Medida de negocios matriz Actor /
Papel diagrama de Huella de negocios / diagrama de
datos Descomposición Funcional diagrama de Producto
diagrama del ciclo de vida Meta / Objetivo / diagrama de
Servicios de Negocio de casos de uso diagrama de
descomposición Organización diagrama de diagrama de
proceso del diagrama de flujo de eventos
Fase C, Arquitectura de Datos Catálogo de entidad de datos / datos de componentes de datos
Entidad / matriz de funciones de negocios Aplicación de matriz /
datos Diagrama conceptual de datos diagrama de Diagrama
Lógico de Datos de Difusión de Datos de Seguridad de Datos
diagrama diagrama de migración de datos de diagrama de
datos del ciclo de vida
Fase C, arquitectura de aplicaciones Cartera de Aplicaciones Catálogo de interfaz catálogo de

aplicaciones / Organización Rol matriz / Aplicación matriz
de aplicación / Función matriz matriz de interacción
aplicación comunicaciones de la aplicación Esquema de
aplicación y el diagrama de la ubicación del usuario
aplicación diagrama de casos de uso Empresa
Manejabilidad diagrama de proceso / aplicación diagrama
Realización Ingeniería de Software Esquema de aplicación
diagrama de Migración diagrama de distribución de
software

Fase ADM Artefacto
fase D Catálogo de Normas de Tecnología Tecnología cartera

Catálogo Aplicación / Tecnología Entornos de matriz y
diagrama de las ubicaciones diagrama Procesamiento
diagrama Plataforma de descomposición diagrama /
Hardware Networked Computing diagrama de Ingeniería de
Comunicaciones
fase E Diagrama de Contexto del Proyecto
diagrama de Beneficios
Gestión de requerimientos catálogo de requisitos
5.4 Entregas Arquitectura
TOGAF, Parte IV, capítulo 36 proporciona una línea de base típica de entregables arquitectura con el fin de definir mejor las actividades
requeridas en el ADM y actuar como un punto de partida para la adaptación dentro de una organización. Para más detalles, véase el Capítulo 3.
5.5 Bloques de construcción
El Marco de Arquitectura contenido explica el concepto de bloques de construcción junto con un ejemplo ficticio que ilustra
bloques de construcción en la arquitectura. TOGAF incluye Arquitectura Building Blocks (Abs) y disolución de los bloques de
construcción (SBB).
“Bloques de construcción” es un término generalizado dentro de TOGAF y el ADM. Un bloque de construcción es simplemente un paquete de
funcionalidad definida para satisfacer las necesidades del negocio. La manera en la que la funcionalidad, productos y desarrollos a medida son
ensamblados en bloques de construcción pueden variar ampliamente entre las arquitecturas individuales. Cada organización debe decidir por sí
mismo qué tipo de régimen de bloques de construcción que funciona mejor. Una buena elección de bloques de construcción puede conducir a
mejoras en la integración de sistemas de legado, la interoperabilidad y la flexibilidad en la creación de nuevos sistemas y aplicaciones.
Los sistemas se construyen a partir de colecciones de bloques de construcción, por lo que la mayoría de los bloques de construcción tienen que
interoperar con otros bloques de construcción. Dondequiera que es cierto, es importante que las interfaces con un bloque de construcción se
publican y razonablemente estable.
bloques de construcción se pueden definir en varios niveles de detalle, dependiendo de en qué etapa del desarrollo de la
arquitectura se ha alcanzado.
Por ejemplo, en una etapa temprana, un bloque de construcción puede consistir simplemente en una agrupación de funcionalidad, tal como una
base de datos de cliente y algunas herramientas de recuperación. bloques de construcción en este nivel funcional de la definición se describen en
TOGAF como Arquitectura Building Blocks (de ABB); véase la Sección 3.22. Más tarde, los productos reales o desarrollos personalizados
reemplazar estas definiciones simples de funcionalidad, y los bloques de construcción se describen entonces como una solución de bloques de
construcción (SBB); véase la Sección 3.23.
Las fases clave y los pasos de la ADM en el que bloques de construcción se evolucionado y especificados se resumen como sigue,
y se ilustran en la Figura 15.

Figura 15: Arquitectura bloques de construcción y su uso en el ciclo de ADM
En la Fase A, las definiciones de los bloques de construcción más tempranas comienzan como entidades relativamente abstractos dentro de la
arquitectura de la visión.
En las fases bloques de construcción B, C y D dentro de las arquitecturas de negocio, datos, aplicaciones y la tecnología han
evolucionado a un patrón común de pasos.
Por último, en la fase E los bloques de construcción se vuelven más aplicación específica medida que se identifican SBB para subsanar las
deficiencias.

Capítulo 6 La empresa Continuum

En este capítulo se proporciona una introducción a la empresa Continuum. Los temas abordados en este capítulo incluyen:
• Una explicación de la Empresa de Medios Continuos y su propósito
• Se utilice la empresa Continuum en el desarrollo de una arquitectura empresarial
• Una visión general de las características de clasificar y arquitecturas de partición
• Una visión general de un marco estructural para un repositorio Arquitectura
6.1 Descripción general de la empresa Continuum
La Empresa Continuum, que se muestra en la Figura 16, proporciona un modelo para la estructuración de un repositorio “virtual” y
proporciona métodos para la clasificación de los artefactos de la arquitectura y de la solución, que muestra cómo las diferentes artefactos
evolucionan y cómo pueden ser reutilizados. Se rellena con los activos de la arquitectura y sus posibles soluciones (modelos, patrones, las
descripciones de la arquitectura, etc.). Estos activos y soluciones se pueden extraer de dentro de la empresa o de la industria en general y
se utilizan en la construcción de arquitecturas.
Figura 16: La Empresa Continuum

Se hace una distinción entre las arquitecturas y sus posibles soluciones, creando así un continuo Arquitectura y una
serie continua de soluciones. Como se muestra en la Figura 16, la relación entre ellos es uno de orientación y apoyo.
La Empresa Continuum soporta dos ideas generales: Reutilización cuando sea posible, sobre todo la prevención de re-invención,
y una ayuda a la comunicación. Los activos tanto en la Arquitectura y Soluciones Continuums se estructuran a partir genérico a lo
específico con el fin de proporcionar un lenguaje consistente para comunicarse de manera efectiva las diferencias entre las
arquitecturas. La comprensión de dónde usted está en el continuo ayuda a todos a comunicarse de manera efectiva. Uso del
Enterprise Continuum puede eliminar la ambigüedad cuando se habla de conceptos y artículos entre los diferentes departamentos
dentro de la misma organización o incluso diferentes organizaciones que construyen arquitecturas empresariales. La comprensión
de la arquitectura ayuda a comprender mejor la solución. Ser capaz de explicar el concepto general detrás de una solución hace
que sea más fácil de entender los posibles conflictos.
Dado que el uso del Enterprise Continuum suele ir acompañado de un aumento de los activos de arquitectura y soluciones asociadas, las
organizaciones pueden beneficiarse directamente de su reutilización.
6.1.1 El Continuum Empresa y Arquitectura Re-Uso
Ejemplos de activos “dentro de la empresa” son los entregables del trabajo previo de la arquitectura, que están
disponibles para su reutilización. Ejemplos de activos “de la industria de TI en general” son la gran variedad de
modelos de referencia de la industria y los patrones de arquitectura que existen, y están surgiendo
continuamente, incluidos los que son muy genérico (como el Modelo de Referencia Técnica TOGAF (TRM));
las específicas de ciertos aspectos de TI (como una arquitectura de servicios web); los específicos para ciertos
tipos de procesamiento de la información (tales como e-Commerce); y las específicas de ciertas industrias
verticales (tales como el modelo de datos ARTS de la industria al por menor).
6.1.2 Se utilice la empresa Continuum dentro del ADM
En el ADM se describe un proceso de pasar de la Fundación Arquitectura TOGAF a una arquitectura organizationspecific (o
conjunto de arquitecturas). Esta Fundación Arquitectura es una descripción muy general de los servicios genéricos y funciones
que proporcionan la base sobre la que las arquitecturas específicas y Arquitectura Building Blocks (Abs) pueden ser construidos
mediante la adición de activos relevantes de arquitectura, componentes y bloques de construcción de la empresa Continuum.
En los lugares relevantes a lo largo de la ADM, hay que considerar, que los recordatorios activos arquitectura del arquitecto
debe utilizar. Además de la Fundación Arquitectura TOGAF, TOGAF proporciona otro modelo de referencia para su
consideración para su inclusión en una organización de la empresa Continuum: la infraestructura de Referencia Modelo
Integrado de Información (III-RM).
6.2 Arquitectura Particiones
Las particiones se utilizan para simplificar el desarrollo y la gestión de la arquitectura de la empresa. Las particiones se encuentran
en la base de la arquitectura de la gobernanza y son distintos de los niveles y los conceptos organizadores de la Arquitectura
Continuum.

Arquitecturas se particionan porque:
• Organizacional conflicto arquitecturas de unidades entre sí.
• Los diferentes equipos necesitan para trabajar en diferentes elementos de la arquitectura al mismo tiempo y particiones permiten a
grupos específicos de los arquitectos a poseer y desarrollar segmentos específicos de la arquitectura.
• arquitectura de reutilización efectiva requiere segmentos arquitectura modular que se pueden tomar y se incorporan en las
arquitecturas y soluciones más amplias.
No es práctico para presentar un modelo de partición definitiva para la arquitectura. Cada empresa tiene que adoptar un modelo de
particiones que refleja su propio modelo de funcionamiento. TOGAF incluye criterios de clasificación que se pueden aplicar al
particionar arquitecturas y orientación para las actividades dentro de la fase preliminar para el establecimiento de una partición.
Pasos dentro de la fase preliminar para apoyar la arquitectura de partición son los siguientes:
• Determinar la estructura de la organización para la arquitectura dentro de la empresa
• Determinar las responsabilidades de cada equipo de arquitectura de pie
• Determinar las relaciones entre las arquitecturas
Una vez que la Fase Preliminar se ha completado, los equipos a cargo de la arquitectura deben ser entendidos. Cada
equipo debe tener un alcance definido y las relaciones entre los equipos y la arquitectura deben ser entendidos.
Asignación de equipos a alcance arquitectura se ilustra en la Figura 17.
Figura 17: Asignación de equipos para Arquitectura Alcance

6.3 Arquitectura Repositorio
Apoyando 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.By medios de la
organización Continuum y Arquitectura del repositorio, se anima a los arquitectos para aprovechar todas las demás recursos
arquitectónicos relevantes en el desarrollo de una arquitectura específicos de la organización.
En este contexto, el ADM puede considerarse como la descripción de un ciclo de vida proceso que opera en múltiples
niveles dentro de la organización, que opera dentro de un marco de gobierno integral y producir salidas alineadas que
residen en un repositorio Architecture. La empresa Continuum ofrece un contexto valioso para comprender los modelos
arquitectónicos: muestra bloques de construcción y sus relaciones entre sí, y las limitaciones y requisitos en un ciclo de
desarrollo de la arquitectura.
La estructura de la TOGAF Arquitectura repositorio se muestra en la Figura 18.
Figura 18: Estructura de TOGAF Arquitectura Repositorio

Los principales componentes dentro de un repositorio de Arquitectura son los siguientes:
• los Arquitectura Metamodel describe la aplicación organizativamente adaptado de un marco de arquitectura,

incluyendo un metamodelo para el contenido de la arquitectura.
• los Arquitectura Capacidad define los parámetros, estructuras y procesos que apoyan gobierno de la
Arquitectura de repositorio.
• los La arquitectura del paisaje muestra una vista de la arquitectura de los bloques de construcción que están en uso hoy en día dentro de
la organización (por ejemplo, una lista de las aplicaciones en vivo). es probable que exista en múltiples niveles de abstracción para
adaptarse a diferentes objetivos de arquitectura del paisaje.
• los Base de Información de Normas ( SIB) captura las normas que deben cumplir las nuevas arquitecturas, que pueden
incluir estándares de la industria, los productos seleccionados y servicios de proveedores o servicios compartidos ya
desplegados dentro de la organización.
• los Biblioteca de referencia proporciona directrices, plantillas, patrones y otras formas de material de referencia
que se pueden aprovechar con el fin de acelerar la creación de nuevas arquitecturas para la empresa.
• los Iniciar la gobernabilidad proporciona un registro de la actividad de gobierno en toda la empresa.
6.3.1 El Enterprise Repository
El Repositorio de Arquitectura es una parte del depósito de la empresa en general. Mientras que la arquitectura de repositorio
contiene información relativa a la arquitectura de la empresa y los artefactos asociados, hay un número considerable de
repositorios empresariales que apoyan la arquitectura. Estos incluyen el repositorio de almacenamiento Requisitos requisitos y las
soluciones Repositorio de almacenamiento de soluciones de Building Blocks (SBB).

Capítulo 7 Modelos de referencia TOGAF

En este capítulo se ofrece una breve introducción a los modelos de referencia TOGAF.
7.1 Fundación Arquitectura TOGAF
La Fundación Arquitectura TOGAF es una arquitectura que proporciona una base sobre la cual arquitecturas específicas y
componentes arquitectónicos se pueden construir. Esta arquitectura Fundación se materializa en el modelo de referencia técnica
(TRM). La TRM es de aplicación universal y por lo tanto se puede utilizar para construir cualquier arquitectura de sistema.
7.1.1 Modelo de Referencia Técnica (TRM)
El TRM, que se muestra en la Figura 19, es un modelo y la taxonomía de servicios de la plataforma genéricos. La taxonomía define la
terminología y proporciona una descripción coherente de sus componentes. Su propósito es dar una descripción conceptual de un
sistema de información. Y el modelo TRM es una representación gráfica de la taxonomía para actuar como una ayuda para la
comprensión.
Figura 19: Technical Reference Model (TRM)

7.2 Infraestructura de Información Integrado Modelo de Referencia (III-RM)
Mientras que la Fundación Arquitectura describe un entorno típico de la plataforma de aplicaciones, el segundo modelo de
referencia incluido en la empresa Continuum, la infraestructura de Referencia Modelo Integrado de Información (III-RM), se
centra en el espacio de software de aplicación. La III-RM es un “común de sistemas Arquitectura” en términos de Enterprise
Continuum.
El III-RM se muestra en la figura 20 y es un subconjunto de la TOGAF TRM en términos de su alcance general, pero también se
expande ciertas partes de la TRM, en particular en las aplicaciones de negocio y piezas aplicaciones de infraestructura. La III-RM
proporciona ayuda para hacer frente a uno de los principales retos que enfrenta el arquitecto de la empresa hoy en día: la necesidad de
diseñar una infraestructura de información integrada para permitir el flujo de información sin fronteras.
Figura 20: La III-RM en detalle

Capítulo 8 Capacidad de Arquitectura

Marco de referencia
En este capítulo se presenta el marco Arquitectura capacidad.
TOGAF, Parte VII: Marco de Capacidad Architecture proporciona un conjunto de materiales de referencia para la forma de establecer una
función de la arquitectura dentro de una empresa.
Un resumen de los contenidos de TOGAF, Parte VII se muestra en la Tabla 16.
Tabla 16: Parte VII TOGAF Contenido Resumen
Capítulo Descripción
Establecer una capacidad de Directrices para establecer una capacidad de Arquitectura dentro de una organización.
Arquitectura
Architecture Board Directrices para el establecimiento y funcionamiento de una empresa Arquitectura Junta.
Arquitectura cumplimiento Directrices para asegurar el cumplimiento del proyecto de arquitectura.
Los contratos Arquitectura Directrices para la definición y el uso de los contratos arquitectura.
Arquitectura de Gobierno Marco y las directrices para la gobernabilidad arquitectura.
Modelos de Madurez Arquitectura Las técnicas para evaluar y cuantificar la madurez de una organización en la arquitectura de la
empresa.
Arquitectura Marco de Habilidades Un juego de rol, habilidad, experiencia y normas para el personal que realizan trabajos de
arquitectura empresarial.
Una estructura general para un Marco de Arquitectura capacidad se muestra en la Figura 21.

Figura 21: Marco de Capacidad de Arquitectura
8.1 Establecer una capacidad de Arquitectura
La implementación de cualquier capacidad dentro de una organización requiere el diseño de las cuatro arquitecturas de dominio:
Negocios, datos, aplicaciones, y Tecnología. El establecimiento de la práctica de la arquitectura dentro de una organización, por tanto,
requiere el diseño de:
• La Arquitectura de Negocios de la práctica de la arquitectura, lo que pone de relieve la gobernabilidad arquitectura, procesos de
arquitectura, arquitectura de la estructura organizativa, los requerimientos de información de arquitectura, productos de
arquitectura, etc.
• La arquitectura de datos, que define la estructura de la empresa Continuum y Arquitectura Repositorio

de la organización
• La arquitectura de aplicaciones, que especifica los servicios de la funcionalidad y / o aplicaciones necesarias para permitir la
práctica de la arquitectura
• La Tecnología de la Arquitectura, que especifica los requisitos de infraestructura de la práctica de la arquitectura en

apoyo de las aplicaciones de arquitectura y Empresa Continuum.

8.2 Arquitectura de Gobierno
El Marco de Arquitectura Capacidad contiene un marco y directrices para la gobernabilidad arquitectura. gobernabilidad
arquitectura es la práctica por la cual las arquitecturas empresariales y otras arquitecturas son gestionados y controlados
a nivel de toda la empresa. Incluye lo siguiente:
• La implementación de un sistema de controles sobre la creación y el seguimiento de todos los componentes y actividades
de arquitectura, para asegurar la efectiva introducción, implementación y evolución de las arquitecturas dentro de la
organización
• La implementación de un sistema para garantizar el cumplimiento de las normas internas y externas y las obligaciones
reglamentarias
• procesos que apoyan la gestión eficaz de los procesos anteriores dentro de los parámetros acordados establecer
• Establecer y documentar las estructuras de decisión que influyen en la arquitectura de la empresa; esto incluye las partes interesadas que
proporcionan las entradas a las decisiones
• El desarrollo de prácticas que garanticen la rendición de cuentas a una comunidad de interesados claramente identificados,
tanto dentro como fuera de la organización
8.3 Architecture Board
Una arquitectura empresarial es algo más que los artefactos producidos por la aplicación del proceso de ADM.
Haciendo la ley orgánica de acuerdo con los principios establecidos en la arquitectura requiere un marco de toma de
decisiones. El Marco de Arquitectura capacidad proporciona un conjunto de directrices para el establecimiento y
funcionamiento de una empresa Arquitectura Junta. Un Consejo de Arquitectura es responsable de la línea operativa y
debe ser capaz de tomar decisiones en situaciones de posible conflicto y ser responsable de tomar esas decisiones. Por
lo tanto, debe ser una representación de todos los actores clave en la arquitectura, y por lo general comprenderá un
grupo de ejecutivos responsables de la revisión y el mantenimiento de la arquitectura general. Es importante que los
miembros de la Junta de Arquitectura cubren arquitectura, negocios,
Problemas para los que la Junta de Arquitectura se puede hacer responsable y rendir cuentas son:
• Proporcionando la base para todas las decisiones con respecto a los cambios en las arquitecturas
• La consistencia entre sub-arquitecturas
• Identificación de los componentes reutilizables
• La flexibilidad de la arquitectura de la empresa; para satisfacer las necesidades del negocio y utilizar las nuevas tecnologías
• Observancia del cumplimiento de la arquitectura
• La mejora del nivel de madurez de la disciplina de la arquitectura dentro de la organización
• Asegurar que la disciplina de desarrollo basado en la arquitectura se adopta
• El apoyo a una capacidad de escalamiento visibles para las decisiones fuera de los límites

El Consejo de Arquitectura también es responsable de los artículos operacionales, tales como el seguimiento y control de los contratos
Arquitectura (véase la Sección 3.29), y para los elementos de gobierno, tales como la producción de materiales de gobierno utilizables.
tareas importantes son:
• La asignación de tareas arquitectónicas
• aprobar formalmente los productos arquitectónicos
• Resolución de conflictos de arquitectura
8.4 Arquitectura cumplimiento
Utilizando la arquitectura de estructurar el desarrollo de TI en una organización implica que los proyectos deben cumplir con la hoja de ruta
de la arquitectura. Si eso "no es el caso, entonces debe haber una buena razón para ello.
Para determinar si este es el caso, una estrategia de Cumplimiento La arquitectura debe ser adoptada con medidas específicas
para garantizar el cumplimiento de la arquitectura. El Marco de Arquitectura capacidad incluye un conjunto de procesos,
directrices, y una lista de control para garantizar el cumplimiento del proyecto a la arquitectura, incluyendo:
• Evaluaciones de Impacto de proyectos que ilustran cómo los impactos de arquitectura empresarial en los grandes proyectos dentro de
una organización
• El proceso de revisión de cumplimiento Arquitectura (ver Figura 22), que es un proceso formal para revisar el cumplimiento
de los proyectos a la arquitectura de la empresa
Figura 22: Arquitectura de Procesos de revisión de cumplimiento

8.5 Arquitectura Marco de Habilidades
El Marco de Arquitectura capacidad proporciona un juego de rol, habilidad, experiencia y normas para el personal que realizan trabajos de
arquitectura empresarial.
“Arquitectura Empresarial” y “EA” se utilizan ampliamente, pero en términos de la industria de TI mal definido hoy. Se utilizan para
denotar una variedad de prácticas y habilidades aplicadas en una amplia variedad de dominios de arquitectura. Hay una necesidad de
una mejor clasificación para permitir una comprensión más implícita de qué tipo de arquitecto / Arquitectura que se está describiendo.
Esta falta de uniformidad conduce a dificultades para organizaciones que buscan reclutar o asignar / promoción de personal para
cubrir puestos en el campo de la arquitectura. Debido a los diferentes usos de términos, a menudo hay malentendidos y falta de
comunicación entre los que tratan de reclutar a, y aquellos que buscan para llenar, las diversas funciones del arquitecto.
El Marco de arquitectura TOGAF Habilidades intenta abordar esta necesidad proporcionando definiciones de las
habilidades de la arquitectura de los niveles de competencia requeridos y de personal, internos o externos, que vaya a
realizar las diversas funciones Architecting definidas en el marco TOGAF.
categorías de habilidades incluyen:
• Habilidades genéricas, que comprende típicamente el liderazgo, el trabajo en equipo, habilidades interpersonales, etc.
• Habilidades y métodos comerciales, que comprenden típicamente casos de negocio, procesos de negocio, la planificación estratégica, etc.
• Arquitectura Empresarial Habilidades, típicamente comprende el modelado, el diseño de edificios de bloques, aplicaciones y
diseño papel, integración de sistemas, etc.
• Programa o gestión de proyectos, por lo general comprende la gestión del cambio de negocio, los métodos de gestión de
proyectos y herramientas, etc.
• El conocimiento general de TI Habilidades, que típicamente comprenden aplicaciones de corretaje, gestión de activos,
planificación de la migración, SLAs, etc.
• Habilidades de TI técnicos, que típicamente comprenden la ingeniería de software, la seguridad, el intercambio de datos, gestión de
datos, etc.
• Entorno legal, por lo general comprende las leyes de protección de datos, derecho contractual, la ley de contratación, fraude, etc.

Apéndice A migración Resumen

Este apéndice contiene información sobre la migración de alto nivel - una breve descripción de lo que se cambia de
TOGAF 8.1.1 y también un resumen de los cambios entre TOGAF 9 y TOGAF
9.1. Los lectores se supone que esté familiarizado con el contenido de TOGAF 8.1.1.
A.1 Los cambios entre TOGAF 8.1.1 y 9.1 TOGAF
El capítulo actual Derivación de TOGAF 8.1.1
Parte I: Introducción
1. Introducción Material revisado; basado en el Capítulo 1 En este capítulo se describe la estructura revisada y
proporciona una visión general ejecutivo de arquitectura de la empresa y los beneficios del uso
de TOGAF. Algunos de los contenidos anteriores han sido trasladados a los nuevos capítulos 2
y 4.
2 Conceptos básicos Nuevo capitulo
Este nuevo capítulo introduce los conceptos básicos de TOGAF; lo que es; lo que es la
arquitectura en el contexto de TOGAF; ¿Qué tipos de arquitectura TOGAF hace mucho
con; el ADM. Se introduce conceptos clave como entregables, artefactos y bloques de
construcción. Se introduce el Continuum Empresa y de la arquitectura de repositorio. Se
introduce el establecimiento y funcionamiento de una capacidad de Arquitectura
Empresarial. Se describen las consideraciones para el uso de TOGAF con otros marcos.
3 Definiciones Derivado del Capítulo 36, reelaborado en las definiciones formales y abreviaturas
Este capítulo revisado contiene los términos y definiciones clave. Otras definiciones
y abreviaturas suplementarios se han movido a apéndices separados.
4 Notas de la versión Nuevo capitulo
Este es un nuevo capítulo contiene información sobre esta versión del documento.
Contiene una visión general de lo que "s nuevo, los beneficios de los cambios y las
asignaciones de resumen de la estructura del documento de TOGAF 8.1.1 a TOGAF 9
y viceversa. También incluye información sobre los términos y condiciones de uso
TOGAF y dónde descargarlo.

Parte II: Arquitectura Desarrollar Método ción
5 Introducción Material revisado; basado en el Capítulo 3 Los cambios realizados en este capítulo
son para posicionar el ADM con respecto a la arquitectura de repositorio, y la Parte III:
Directrices y técnicas de ADM. El concepto de versiones de documentos se introduce
con un ejemplo.
6 Fase Preliminar Material revisado; basado en el Capítulo 4 El enfoque se ha ampliado

considerablemente para abordar además la definición de la empresa, los conductores
y elementos para la organización clave, los requisitos para el trabajo de la arquitectura,
los marcos de gestión y su relación, así como la madurez de la empresa.
En la actualidad hay pasos concretos definidos, mientras que antes no había ninguno.
7 Fase A: Architecture Vision material revisado; basado en el Capítulo 5
Los escenarios de negocio ahora se denominan como una sección separada en el enfoque;
previamente fueron incluidos como una subsección de Pasos. Los pasos se han revisado para
incluir, además, una evaluación de las capacidades comerciales, Preparación para la
transformación del negocio, definición de propuestas de valor objetivo Arquitectura y KPI, e
identificación de riesgos de las transformaciones de negocios y actividades de mitigación.
Las entradas y salidas se reorganizan para que coincida con los resultados finales.
8 Fase B: Arquitectura de Negocios material revisado; basado en el capítulo 6
El enfoque se revisa para discutir el Repositorio de Arquitectura en lugar de la

empresa Continuum. La descripción de la técnica de análisis de carencias se
mueve a la parte III: Directrices y técnicas de ADM.
Se introduce una secuencia revisada de pasos. Esta misma secuencia de pasos también se
utiliza en las Fases C y D.
Las entradas y salidas se reorganizan para que coincida con los resultados finales. Una
diferencia clave es la introducción de dos documentos de contenedores: la definición del
documento Arquitectura y la especificación de requisitos Arquitectura.
9 Fase C: Sistemas de Información Material revisado; basado en el Capítulo 7

arquitecturas Las entradas y salidas se reorganizan para que coincida con las entregas de TOGAF 9.

10 Fase C: Arquitectura de Datos Material revisado; basado en el capítulo 8 en el enfoque: la referencia a Enterprise
Continuum se reemplaza con el Repositorio de Arquitectura. Se elimina la sección sobre
el análisis Gap. Se añade un apartado de Consideraciones clave para Arquitectura de
Datos.
Se introduce una secuencia revisada de pasos. Esta misma secuencia también se usa en las
Fases B, C (Arquitectura de la aplicación), y D. Las entradas y salidas se reorganizan para
que coincida con los entregables para TOGAF 9.
11 Fase C: Aplicación Material revisado; basado en el capítulo 9 en el enfoque: la referencia a Enterprise

Arquitectura Continuum se reemplaza con el Repositorio de Arquitectura. Se elimina la sección
sobre el análisis Gap.
Se introduce una secuencia revisada de pasos. Esta misma secuencia también se usa en las
Fases B, C (Arquitectura de Datos), y D. Las entradas y salidas se reorganizan para que coincida
con los resultados finales.
12 Fase D: Tecnología Material revisado; basado en el capítulo 10 en el enfoque: la referencia a Enterprise

Arquitectura Continuum se reemplaza con el Repositorio de Arquitectura.
Los pasos han sido objeto de una importante reorganización, y ahora utilizar la misma secuencia
también se utiliza en las fases B y C. Las entradas y salidas se reorganizan para que coincida con los
resultados finales.
13 Fase E: Oportunidades y Material revisado; basado en el Capítulo 11 Esta fase ha tenido una importante revisión para
soluciones agregar una descripción más detallada para un enfoque y pasos para pasar de destino
Arquitecturas identificados en las fases anteriores a la puesta en práctica y crear un proyecto de
plan de ejecución y migración.
14 Fase F: La migración de materiales de planificación revisada; basado en el capítulo 12
Esta fase ha tenido una importante revisión para agregar una descripción más detallada para un
enfoque y pasos para finalizar la aplicación y el Plan de Migración identificados en la Fase E.
15 Fase G: Implementación Material revisado; basado en el capítulo 13

Gobernancia Los objetivos incluyen nueva formulación y adiciones a destacar el aspecto de
gobierno de la fase.
El enfoque ha sido actualizado para incluir el valor de negocio Realización.
Los pasos han tenido una importante revisión para incluir la confirmación de posibilidades de
despliegue con la gestión del desarrollo, la identificación de las habilidades y recursos de
implementación, el desarrollo de una guía para la implementación de soluciones, las revisiones de
cumplimiento, ejecución de las operaciones, y una revisión posterior a la implementación.

16 Fase H: Arquitectura Cambio Material revisado; basado en el capítulo 14 de los objetivos se han vuelto a trabajar y
administración que incluye maximizar el valor del negocio.
El enfoque se amplía para incluir adicionalmente el seguimiento de la gestión empresarial y la

capacidad. Los pasos han tenido una importante revisión, y, además, incluir el establecimiento
del proceso de realización del valor, el despliegue de herramientas de monitoreo, gestión de
riesgos, el análisis para el cambio y el desarrollo de los requisitos de cambio para cumplir con
los objetivos de rendimiento.
17 ADM Arquitectura Ningún cambio sustancial; mapas del Capítulo 15 Las entradas y salidas se reorganizan para que
Gestión de requerimientos coincida con los resultados finales.
Parte III: Directrices y ADM técnicas
18 Introducción Nuevo capitulo
Esta nueva parte se proporciona para apoyar la aplicación de la ADM.
19 La aplicación de iteración a la ADM Nuevo capítulo
En este capítulo se describe el concepto de iteración y muestra las posibles estrategias para la
aplicación de los conceptos iterativos a la ADM.
20 La aplicación de la ADM a través de la Nuevo capitulo

La arquitectura del paisaje En este capítulo se describe la aplicación de la ADM a través de la arquitectura
del paisaje.
21 Arquitectura de Seguridad y la Nuevo capitulo; derivado de Libro Blanco de Seguridad (W055) Este capítulo proporciona
ADM consideraciones de seguridad específicas para cada fase de la ADM.
22 Uso de TOGAF para definir y Nuevo capitulo

Govern SOA En este capítulo se describe cómo el estilo SOA de la arquitectura puede ser apoyado por
TOGAF.
23 Principios de Arquitectura Ningún cambio sustancial; mapas del Capítulo 29 Un nuevo principio ejemplo de servicio de
orientación a los Principios de Actuación.
24 Administración de los grupos de interés Nuevo capitulo
En este capítulo se describe la técnica de la gestión de los interesados, una disciplina

importante para los profesionales de la arquitectura.
25 patrones de arquitectura Ningún cambio sustancial; mapas del Capítulo 28
26 Escenarios empresariales Ningún cambio sustancial; mapas del Capítulo 34
Análisis Gap 27 Nuevo capitulo; derivados del análisis de Gap Este capítulo se introduce para permitir la
técnica para hacer referencia a partir de las fases de ADM, y por lo tanto reducir la
duplicación de texto.
28 Técnicas de planeamiento de migración capítulo de Nueva
En este capítulo se describe una serie de técnicas para apoyar las Fases E y F.

29 requisitos de interoperabilidad capítulo de Nueva
Este capítulo sirve de guía para el desarrollo de los requisitos de interoperabilidad.
Transformación de Negocios 30 Nuevo capitulo

Evaluación de la Preparación
En este capítulo se describe una técnica para la identificación de problemas de transformación de
negocio.
Gestión de Riesgos 31 Nuevo capitulo
En este capítulo se describe una técnica para la gestión de riesgo durante un proyecto de
arquitectura o negocio transformación.
32 Planificación Capability-Basado Nuevo capitulo
En este capítulo se describe la técnica de planificación basada en la capacidad.
Parte IV: Arquitectura contenido Marco de referencia
Esta nueva parte de TOGAF se dirige a la producción de contenidos, proporcionando un marco en el
que colocar los principales productos de trabajo.
34 Metamodel contenido Nuevo capitulo
En este capítulo se proporciona una definición metamodelo de todos los tipos de bloques de
construcción dentro de una arquitectura, mostrando cómo pueden ser descritos y cómo se
relacionan entre sí.
35 Architectural Artifacts Derivado del capítulo 31, además de los nuevos materiales En este capítulo se revisa para hacer
frente a un conjunto de productos de trabajo atómicas creadas cuando se sigue el ADM. Un
diagrama para ilustrar los conceptos de la norma ISO / IEC 42010: 2007 es introducido. Las
clases de puntos de vista se definen: catálogos, matrices y diagramas. se añaden puntos de vista
de arquitectura adicionales.
36 Arquitectura entregables Revisada del capítulo 16
Una revisión significativa de las prestaciones se ha llevado a cabo. Una tabla se

proporciona que muestra donde entregables se producen y consumen en el ciclo de
ADM. Una diferencia clave es la introducción de dos documentos de contenedores: la
definición del documento Arquitectura y la especificación de requisitos Arquitectura.
37 Bloques de Construcción Revisada del capítulo 32
La descripción del proceso de especificación de bloques de construcción en el ADM se ha
actualizado para que coincida con los cambios en los pasos de ADM. La sección sobre los Grados
de modelado se ha eliminado.
Parte V: Enterprise Continuum y Herramientas

39 Empresa Continuum Derivado de los capítulos 17 y 18
La explicación de la Empresa Continuum ha sido reescrito para explicar mejor su

propósito y el contexto, incluyendo su relación con repositorios empresariales.
Organización Arquitecturas ha sido actualizado para OrganizationSpecific

Arquitecturas en el diagrama de la arquitectura Continuum.
Soluciones organización ha sido actualizado para Soluciones específicos de la organización

en el diagrama de la serie continua de soluciones. En la descripción de la Arquitectura
Continuum, Enterprise Architectures se actualiza para Arquitecturas específicos de la
organización. En la descripción del Continuum Solutions, Soluciones para empresas se
actualiza a soluciones específicos de la organización.
40 Arquitectura de particionamiento Nuevo capitulo
En este capítulo se describen las diversas características que se pueden aplicar para
clasificar y luego arquitecturas de partición.
41 Arquitectura Repositorio Nuevo capitulo
En este capítulo se describe cómo las clasificaciones abstractas de la arquitectura se

pueden aplicar a una estructura del repositorio.
42 Herramientas para la Arquitectura En este capítulo se toma del Capítulo 38, pero reduce sustancialmente mediante la eliminación
Desarrollo de los criterios de evaluación y directrices.
Parte VI: TOGAF Referencia M odelos
43 Fundación Arquitectura: Ningún cambio sustancial; mapas de los capítulos 19 y 20 el detalle de Plataforma
Técnica Modelo de Referencia taxonomía es ahora una sección de este capítulo en lugar de ser un capítulo aparte.
44 Integrado de Información Ningún cambio sustancial; mapas del capítulo 22

Infraestructura modelo de referencia
Parte VII: Arquitectura Capabil Marco dad
46 El establecimiento de una Arquitectura Nuevo capitulo

Capacidad En este capítulo se describe cómo utilizar el ADM para establecer un estudio de
arquitectura dentro de una organización.
47 Architecture Board cambio mínimo; mapas del capítulo 23 Los cambios se han limitado a
cambios editoriales menores.
48 Arquitectura de Cumplimiento cambio mínimo; mapas del Capítulo 24
La sección de Proyectos Estudios de Impacto (Proyecto rebanadas) se ha eliminado.
49 Los contratos Arquitectura cambio mínimo; mapas del Capítulo 25
se añade redacción para atar este capítulo más de cerca a la Arquitectura de Gobierno.
En lugar de listar el contenido de la Declaración de Arquitectura de trabajo, una
referencia a la definición en la Parte IV: Se añade arquitectura marco de contenido.

50 Arquitectura de Gobierno cambio mínimo, se asigna a Capítulo 26 Una referencia al papel de mapeo TOGAF /
COBIT de ITGI se añade. Algunos cambios de redacción editorial se ha aplicado a la
sección de Arquitectura de Gobierno en la práctica.
51 Arquitectura Modelos de Madurez de cambio mínimo; mapas del capítulo 27
Los cambios menores se han aplicado para referirse a la última versión de ACMM.
52 Arquitectura Habilidades Marco de algunos cambios cosméticos; mapas del Capítulo 30
Las referencias a Arquitecto de TI han sido reemplazados con EA.
Apéndices
Glosario de suplementario Derivado del Capítulo 36

definiciones Los términos y definiciones que aquí se han dividido desde el glosario original, ya
que no son específicos de TOGAF.
b Las abreviaturas Derivado del Capítulo 36
Esta sección ha sido separado del glosario originales.
A.2 Resumen de los cambios entre TOGAF 9 y TOGAF 9.1
1. La categorización del modelo de documento se ha eliminado (Capítulo 2).
2. Las definiciones de los términos en que el uso por parte de TOGAF tampoco es distintivo de la común
la definición del diccionario se han eliminado (Capítulo 3).
3. Las secciones Objetivos de las fases de ADM se han revisado a fin de centrarse en real
objetivos en lugar de las técnicas utilizadas en la fase o una lista de pasos (capítulos 6-17).
4. Las posibles artefactos (puntos de vista) para cada fase ahora se muestran en la descripción de la
fase, no sólo en la Parte IV, los artefactos arquitectónicos (capítulos 6-14).
5. Duplicar texto en varios lugares ha sido reemplazada con una referencia adecuada:
• Análisis Gap en las Fases B, C, y D ahora referencias Parte III, Análisis Gap (capítulos 8-
12).
• Gestión de requisitos en varias fases hace referencia ahora a la Parte II, Desarrollo requisitos en
la fase de gestión de requisitos.
6. La fase descripciones E y F se han modificado para que coincida con el nivel de detalle en otra
fases de la ADM (Capítulos 13 y 14).
7. Los usos de la terminología de Estrategia / Implementación Transición Arquitectura / Plan de trabajo tienen
han aclarado y hecho consistentes (Capítulos 13, 14, y 36).
8. texto introductorio adicional sobre estilos arquitectónicos se ha añadido en la parte III, Introducción
(Capítulo 18).

9. Los conceptos de niveles, iteraciones, y tabiques se han aclarado y hecho consistente.

Esto incluye una reorganización de material en la parte III, Aplicar iteración a la ADM y aplicando la ADM a través de la
arquitectura del paisaje y la quinta parte, Arquitectura de particiones (Capítulos 19, 20, y 40).
10. Los cambios menores se han hecho al capítulo Arquitectura de seguridad (parte III, Seguridad
Arquitectura y el ADM) para mantener la coherencia con el ADM (Capítulo 21).
11. El capítulo SOA (Parte III, El uso de TOGAF para definir y Govern SOA) ha sido actualizado a la
describir última salida Grupo de Trabajo de SOA (Capítulo 22).
12. Se han realizado correcciones a los diagramas metamodelo y aspectos del metamodelo
(Capítulo 34).
13. El uso de la aplicación términos versus Sistema de haber sido revisado y hecho consistente.
14. El artefacto términos y puntos de vista se han aclarado y hecho consistente. Esto incluye una
la reestructuración de la Parte IV, Architectural Artifacts (Capítulo 35).
15. El ejemplo bloques de construcción se ha eliminado (Capítulo 37).
dieciséis. Algunos de los artefactos han sido renombrados para reflejar mejor su uso (Capítulo 35 y
Los capítulos 6-14):
• Sistema de matriz / Organización se convierte en Aplicación de matriz / Organización
• matriz de papel / Sistema convierte en papel de matriz / Aplicación
• matriz del sistema / función se convierte en la matriz de aplicación / Función
• Realización diagrama de proceso / sistema se convierte en diagrama de proceso de Realización / Aplicación
• Esquema de la instalación de casos de uso se convierte en Aplicación diagrama de casos de uso
• matriz del sistema / tecnología se convierte en la matriz de aplicación / Tecnología
• matriz de Aplicación / Sistema convierte en papel de matriz / Aplicación
17. La descripción de los principios de la arquitectura ahora los divide en dos únicos tipos - Empresa
y Arquitectura - mientras que antes llamó Principios de TI por separado. Principios de TI ahora son vistos como sólo una parte de
los principios de la empresa (capítulo 23).
18. El mapa de públicos incluidos en el capítulo Gestión de los grupos de interés (Parte III,
Gestión de los interesados) ahora se refiere explícitamente a modo de ejemplo, la tabla se ha puesto de manifiesto para
referirse a preocupaciones de los interesados, y la lista de artefactos de cada actor actualizado (Capítulo 24).
19. El capítulo escenarios empresariales (Parte III, escenarios y objetivos de negocio) ha sido
renombrado a escenarios y objetivos de negocio para reflejar mejor el contenido del capítulo (Capítulo 26).
20. La relación de la Enterprise Repository al Repositorio Arquitectura se aclara en

Parte V, Arquitectura repositorio (Capítulo 41).

21. El capítulo sobre Arquitectura Modelos de Madurez (Parte VII, modelos de arquitectura de madurez) tiene
sido revisado editorialmente por consistencia y claridad (Capítulo 51).

Glosario
Arquitectura de la aplicación
Una descripción de la estructura y la interacción de las aplicaciones como los grupos de capacidades que proporcionan funciones clave del
negocio y gestionar los activos de datos.
Arquitectura
La arquitectura tiene dos significados, dependiendo de su uso contextual:
1. Una descripción formal de un sistema o un plan detallado del sistema a nivel de componente a
orientar su aplicación
2. La estructura de los componentes, sus interrelaciones, así como los principios y directrices
que regulan su diseño y evolución en el tiempo
Arquitectura Bloque de construcción (ABB)
Un constituyente del modelo de arquitectura que describe un único aspecto del modelo general.
Arquitectura Continuum
Una parte de la empresa Continuum. Un repositorio de elementos arquitectónicos con el aumento de detalle y la especialización. Este
continuo comienza con las definiciones fundamentales como modelos de referencia, estrategias básicas y bloques de construcción
básicos. A partir de ahí se extiende a las arquitecturas y todo el camino a la arquitectura específica de una organización.
Método de Desarrollo de la arquitectura (ADM)
El núcleo de TOGAF. Un enfoque paso a paso para desarrollar y utilizar una arquitectura empresarial.
Marco de la arquitectura
Una estructura conceptual utilizado para desarrollar, implementar y mantener una arquitectura.
Arquitectura línea de base
La arquitectura del sistema se define existente antes de entrar en un ciclo de revisión de la arquitectura y rediseño.
Arquitectura de Negocios
Una descripción de la estructura y la interacción entre las necesidades estrategia de negocios, organización, funciones, procesos
de negocio, y de información.

Capacidad
Una habilidad que una organización, persona o sistema posee. Capacidades se expresan normalmente en términos de alto
nivel general y y por lo general requieren una combinación de organización, personas, procesos y tecnología para lograr. Por
ejemplo, la comercialización, contacto con el cliente o telemarketing.
capacidad de Arquitectura
Una descripción muy detallada del enfoque arquitectónico para darse cuenta de una solución o solución aspecto particular.
Incremento de 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 se ha realizado.
Arquitectura de datos
Una descripción de la estructura y la interacción de la empresa "s principales tipos y fuentes de datos, los activos de datos lógicas,
activos físicos de datos y recursos de gestión de datos.
Empresa
El nivel más alto (típicamente) de la descripción de una organización y normalmente cubre todas las misiones y funciones. Una
empresa a menudo abarcar varias organizaciones.
Continuum empresa
Un mecanismo de categorización útil para la clasificación de la arquitectura y la solución artefactos, tanto internos como externos a la
arquitectura Repository, a medida que evolucionan desde genéricos Arquitecturas Fundación a las arquitecturas de
Organización-específicos.
Fundación Arquitectura
bloques genéricos de construcción, sus interrelaciones con otros bloques de construcción, combinados con los principios y directrices que
proporcionan una base sobre la cual se pueden construir arquitecturas más específicas.
Brecha
Una declaración de la diferencia entre los dos estados. Se utiliza en el contexto del análisis de las lagunas, donde se identifica la
diferencia entre la línea de base y Arquitectura de destino.
Gobernancia
La disciplina de controlar, gestionar y dirigir un negocio (o IS / IT horizontal) para entregar el resultado de negocio
requerido.

metamodelo
Un modelo que describe cómo y con qué la arquitectura se describirá de forma estructurada.
Repositorio
Un sistema que gestiona todos los datos de una empresa, incluidos otra información de la empresa modelos de proceso de datos y e.
Por lo tanto, los datos en un repositorio es mucho más extensa que la de un diccionario de datos, que define por lo general sólo los datos
que componen una base de datos.
Requisito
Una declaración de necesidad que debe ser cumplida por una arquitectura o el trabajo paquete en particular.
Gestión de riesgos
La gestión de los riesgos y problemas que puedan poner en peligro el éxito de la práctica de la arquitectura de la empresa y su
capacidad para cumplir es la visión, metas y objetivos, y, sobre todo, su prestación de servicios.
segmento de Arquitectura
Una descripción formal detallado de las áreas dentro de una empresa, que se utiliza a nivel de programa o cartera para organizar y alinear la
actividad de cambio.
servicio de Orientación
Una forma de pensar en términos de servicios y el desarrollo basado en el servicio y los resultados de los servicios.
Arquitectura orientada a servicios (SOA)
Un estilo arquitectónico que es compatible con la orientación al servicio. Tiene las siguientes características distintivas:
• Se basa en el diseño de los servicios - que reflejan las actividades del mundo real de negocio que comprenden la
empresa (o inter-empresarial) los procesos de negocio.
• representación servicio utiliza descripciones de negocio para proporcionar el contexto (es decir, procesos de negocio, meta,
regla, la política, la interfaz de servicio, y el componente de servicio) y los servicios que utilizan implementos orquestación de
servicios.
• Se coloca 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 entorno específico - se ven limitados o habilitadas por el contexto y deben ser descritas dentro
de ese contexto.
• Se requiere un sólido gobierno de la representación e implementación del servicio.
• Se requiere una "prueba de fuego", que determina un "buen servicio".

Arquitectura de soluciones
Una descripción de un discreto y se centró operación o actividad comercial y cómo IS / IT es compatible con esa operación. Una
Arquitectura de la solución típicamente se aplica a un solo lanzamiento o proyecto, con la asistencia en la traducción de los requisitos en
una visión solución, negocios de alto nivel y / o especificaciones de los sistemas de TI, y una cartera de competencias de ejecución.
Solución Bloque de construcción (SBB)
Una solución candidata que se ajusta a la especificación de un Bloque de construcción Arquitectura (ABB).
soluciones Continuum
Una parte de la empresa Continuum. Un repositorio de soluciones reutilizables para futuros esfuerzos de
implementación. Contiene implementaciones de las definiciones correspondientes en la Arquitectura Continuum.
Tenedor de apuestas
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 tendrán diferentes preocupaciones.
Arquitectura de destino
La descripción de un estado futuro de la arquitectura 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.
Modelo de Referencia Técnica (TRM)
Una estructura que permite que los componentes de un sistema de información que se describirá de una manera consistente.
Arquitectura tecnología
Una descripción de la estructura y la interacción de los servicios de la plataforma, y los componentes de tecnología lógicos y físicos.
Arquitectura transición
Una descripción formal de un estado de la arquitectura en un punto de gran importancia arquitectónica en el tiempo. Uno o más
arquitecturas de transición pueden ser usados para describir la evolución en el tiempo de la línea de base a la arquitectura destino.
Ver
La representación de un conjunto relacionado de preocupaciones. Una vista es lo que se ve desde un punto de vista. Una vista de la
arquitectura puede estar representado por un modelo para demostrar a los interesados sus áreas de interés en la arquitectura. Una visión
no tiene que ser visual o gráfica en la naturaleza.

Punto de vista
Una definición de la perspectiva desde la que se toma una vista. Es una especificación de las convenciones para
construir y usar una vista (a menudo por medio de un esquema o plantilla adecuada). Una vista es lo que se ve; Es un
punto de vista en el que está buscando desde - el punto de vista o perspectiva que determina lo que se ve.
Paquete de trabajo
Un conjunto de acciones identificadas para lograr uno o más objetivos para el negocio. Un paquete de trabajo puede ser parte de un
proyecto, un proyecto completo, o un programa.

Índice
ABB ........................................ 50, 101 Adaptación Los escenarios de negocio ......................... 46
de la ADM ... ...................... 61 Preparación para la transformación del negocio
ADM ............................................. 4, 7 ADM Evaluación ................................ 38
fase 9 ...................................... Evaluación del valor de negocio
Gestión de requisitos ADM .. 24 de ANSI / Técnica .................................. 55
IEEE Std 1471-2000 .............. 2 Capacidad ..................................... 102
Aplicación Arquitectura .... 3, 17, 101 Aplicación Capacidad de Arquitectura .......... 66, 102 capacidad
de iteración a la ADM ...... 62 de evaluación ................... 38
Los artefactos arquitectónicos .................... 74 Capacidad Incremento .................... 102
Arquitectura .................................. 101 Capacidad de planificación basada ............. 51
Arquitectura Junta ......................... 89 Catálogos, matrices y diagramas. 73 Solicitud de
Arquitectura Bloque de construcción .. 50, 101 Marco de cambio .............................. 59
Capacidad de la arquitectura Plan de comunicaciones .................... 37
............................................ ....... . 87 Evaluación del cumplimiento ................. 59
Arquitectura Cumplimiento ................ 90 Las lagunas consolidados, soluciones y
Marco contenido Arquitectura Arquitectura ... Dependencias Matrix ................. 53
71 Continuum ............... 101 Metamodel contenido ........................ 72
Los contratos Arquitectura .................... 57 Arquitectura de Datos ............... 3, 15, 102
Arquitectura Definición de documento. 40 Incrementos Empresa ........................... .......... 102
de definición de la arquitectura Arquitectura Empresarial del Estado
Tabla .......................................... 53 Evolución Tabla ......................... 54
Método de desarrollo de la arquitectura Continuum empresa ............ 79, 102
............................................ ..... . 101 Architecture Foundation ............... 102
Marco de la arquitectura ............... 101 Gap ............................................... 102
Arquitectura de Gobierno ................ 89 Análisis Gap .................................. 46
Arquitectura Partición ................ 81 Gobierno .................................. 102
Principios de Arquitectura ................... 29 Plan de Implementación y Migración
Arquitectura Repositorio ........... 32, 82 .......................................... . ........ 55
requisitos de arquitectura Evaluación del Factor de aplicación
Especificación .............................. 43 y Matrix Deducción ................ 52
Arquitectura Hoja de Ruta .................... 45 Implementación Modelo de Gobierno
Arquitectura Marco Habilidades ....... 91 .......................................... . ........ 57
Arquitectura Herramientas .......................... 33 Arquitectura de la información Sistemas.
Arquitectura Puntos de vista ................. 48 Infraestructura 42 Integrado de Información
Arquitectura Vistas ......................... 49 Modelo de Referencia ........................ 86
Architecture Vision ........................ 34 Requisitos interoperabilidad ........ 44
Arquitectura línea de base ................... 101 Iteration .......................................... 62
Bloques de Construcción .............................. 77 Metamodel ................................... 103
Arquitectura de Negocios ......... 3, 41, 101 Principios Técnicas de planificación de migración ..... 52
de Actuación, objetivos, y Migración Resumen ....................... 92
Los conductores ........................................ 32 Modelo de Organización de Empresa
Requisitos de negocios ................... 44 Arquitectura ............................... 29

Fase A: Architecture Vision ......... 12 Arquitectura segmento ............. 66, 103 Servicio de
Fase B: Arquitectura de Negocios ...... 14 Orientación ....................... 103
Fase C: Sistemas de Información Arquitectura Orientada a Servicios 68, 103 SOA
Arquitectura ................................ 15 ........................................... ... 103
Fase D: Tecnología de la Arquitectura. 18 Fase E: Arquitectura de la solución ................... 104
Oportunidades y Soluciones Solución Bloque de construcción ......... 51, 104
............................................ ....... . 20 Soluciones Continuum .................... 104
Fase F: planeamiento de migración .......... 21 Las partes interesadas ................................... 104
Fase G: Implementación gestión de los interesados ............... 35
Gobernabilidad ................................ 22 Declaración de Arquitectura de trabajo .... 34
Fase H: Cambio Arquitectura Arquitectura estratégica ..................... 66
Gestión ............................... 23 TAFIM ............................................. 1
Fase Preliminar ........................... 10 A medida arquitectura marco .. 28 Arquitectura
Cualidades de Principios .................... 31 de destino ...................... 104
Repositorio .................................... 103 Modelo Técnico de Referencia ... 85, 104
Solicitud de Arquitectura trabajo ...... 33 Arquitectura Tecnología .... 3, 42, 104
Requisito ................................. 103 Enterprise Continuum ............. 79
Requisitos de Evaluación de Impacto .. 60 base de TOGAF Modelos de referencia ............ 85
recursos .................................. 6 Arquitectura transición ................ 104
Gestión de Riesgos ........................... 39 Ver ............................................. 104
SBB ........................................ 51, 104 Arquitectura Punto de vista ..................................... 105
de seguridad .... .................. 67 Paquete de Trabajo .............................. 105

1 - TOGAF Version 9.1 A Pocket Guide (PDFDrive - Com) .En - Es

Cargado por

Copyright:

Formatos disponibles

1 - TOGAF Version 9.1 A Pocket Guide (PDFDrive - Com) .En - 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

1 - TOGAF Version 9.1 A Pocket Guide (PDFDrive - Com) .En - Es

Cargado por

Copyright:

Formatos disponibles

Edición PDF personales

TOGAF ® versión 9.1

Edición PDF personal. No para su redistribución

TOGAF ® Versión 9.1 - Una Guía de bolsillo

Copyright © 2009-2011, The Open Group

Todos los derechos reservados.

TOGAF ® versión 9.1

Una guía de bolsillo

Número de documento: G117

Publicado por The Open Group, diciembre de 2011.

Berkshire, RG1 1AX

o por correo electrónico a:

Edición PDF personal. No para su redistribución

TOGAF ® Versión 9.1 - Una Guía de bolsillo

Capitulo 2 El método de desarrollo Arquitectura .............................................. ............................... 7

Edición PDF personal. No para su redistribución

TOGAF ® Versión 9.1 - Una Guía de bolsillo

3.13 Evaluación de la capacidad ................................................ ........................................... 37

Capítulo 4 Directrices para la adaptación de la ADM ............................................. ...................................... 60

4.1 Introducción ................................................. .................................................. ........ 60

Capítulo 5 Marco contenido Arquitectura ............................................... ...................................... 70

Capítulo 6 La empresa Continuum ............................................... ................................................ 78

Edición PDF personal. No para su redistribución

TOGAF ® Versión 9.1 - Una Guía de bolsillo

6.2 Arquitectura Partición ................................................ ....................................... 79

Capítulo 7 Modelos de referencia TOGAF ............................................... ............................................... 83

Capítulo 8 Marco de Capacidad de la arquitectura ............................................... .................................. 85

Apéndice A Resumen de migración ................................................ .................................................. ....... 90

Edición PDF personal. No para su redistribución

TOGAF ® Versión 9.1 - Una Guía de bolsillo

La audiencia de este documento es:

Edición PDF personal. No para su redistribución

TOGAF ® Versión 9.1 - Una Guía de bolsillo

Sobre TOGAF Versión 9.1

• adopción incremental de la especificación TOGAF

• Los vínculos entre el TOGAF ADM y arquitectura orientada a servicios (SOA)

Edición PDF personal. No para su redistribución

TOGAF ® Versión 9.1 - Una Guía de bolsillo

Convenciones utilizadas en este documento

• Los puntos suspensivos (...)

Se utiliza para resaltar los términos específicos.

Acerca de The Open Group

• Operar la industria "s de servicios de certificación Premier

Un catálogo está disponible en www.opengroup.org/bookstore .

Edición PDF personal. No para su redistribución

TOGAF ® Versión 9.1 - Una Guía de bolsillo

Edición PDF personal. No para su redistribución

TOGAF ® Versión 9.1 - Una Guía de bolsillo

Sobre los autores

Profesor Rachel Harrison, Universidad de Oxford Brookes

Rachel Harrison es un profesor de informática en el Departamento de Informática y Tecnologías de la Comunicación en la

Paul Homan, IBM

Edición PDF personal. No para su redistribución

TOGAF ® Versión 9.1 - Una Guía de bolsillo

Matthew F. Rouse, Hewlett-Packard

Tom van Sante, KPN / Getronics

Mike Turner, Nokia

Paul van der Merwe, Connexion de negocios

Edición PDF personal. No para su redistribución